RAG

LLM이 답하기 전에 외부 문서나 DB에서 관련 내용을 찾아 프롬프트에 넣어 주는 기술로, 모델에게 오픈북 시험을 보게 하는 방식이다. 바뀐 사내 규정이나 회사 DB에만 있는 정보처럼 모델이 배우지 못한 내용을 근거와 함께 답하게 하고, 지어내는 답(환각)을 줄이고 싶을 때 쓴다.

준비는 쪼개고, 질문은 찾아서 넘긴다

만드는 과정은 두 단계다. 미리 문서를 작은 조각으로 쪼개(청킹) 의미를 담은 숫자 벡터로 바꾼 뒤(임베딩) 벡터 DB에 저장해 둔다. 질문이 오면 질문도 벡터로 바꾸고, 의미가 가까운 조각을 찾아 LLM에 넘긴다.

LangChain, LlamaIndex 같은 프레임워크를 쓰면 시제품은 하루면 만든다. 벡터 DB를 새로 들이기 어렵다면 쓰고 있는 PostgreSQL에 pgvector 확장을 얹는 방법도 있다. 진짜 일은 그다음, 검색이 엉뚱한 조각을 가져오는 문제를 줄이는 데서 시작한다.

답의 품질은 검색이 정한다

벡터 검색은 "환불 정책"과 "반품 규정"이 비슷한 말이라는 건 알지만, 에러 코드나 제품명을 정확히 찾는 데는 약하다. 그래서 실제로는 아래 장치를 겹쳐 쓴다.

고치기 전에 먼저 재야 한다. 대표 질문 수십 개마다 정답 문서를 짝지어 두고, 검색이 그 문서를 찾아오는지와 답이 찾은 근거를 잘 따르는지를 따로 잰다. 이렇게 나눠 봐야 검색과 생성 중 어디를 고칠지 보인다. RAGAS 같은 도구가 이 측정을 도와준다.

긴 컨텍스트와는 섞어 쓴다

컨텍스트가 100만 토큰까지 늘었지만 RAG가 필요 없어진 건 아니다. 규모와 조건에 따라 고르면 된다.

컨텍스트가 길수록 중간 내용을 놓치기도 한다. 그래서 검색으로 후보를 추린 뒤 넉넉해진 컨텍스트에 여유 있게 담는 조합이 실무 방식이다.

이제는 에이전트가 직접 찾는다

요즘은 한 번 검색하고 끝나는 고정된 흐름 대신, 에이전트가 검색을 도구로 쥐고 필요할 때마다 부르는 Agentic RAG로 가고 있다. 결과가 부실하면 검색어를 바꿔 다시 찾고, 두 제품을 비교하는 질문이면 각각 따로 찾아 합친다. 개체 사이 관계를 따라 찾는 Graph RAG도 같은 흐름이다.

Claude Code가 grep과 파일 읽기를 반복하며 필요한 코드를 스스로 모으는 것도 같은 원리다. 미리 만들어 둔 색인 없이 검색을 반복하는 것만으로 RAG가 하던 일을 해낸다.

가장 흔한 건 사내 문서 챗봇이다

가장 많이 쓰는 방식은 사내 문서에 묻고 답하는 챗봇이다. 규정·매뉴얼·위키를 색인해 두고, 답마다 근거 문서 링크를 달아 직접 확인할 수 있게 한다.