RAG (검색 증강 생성)

검색과 생성을 연결한다

모델이 학습 과정에서 얻은 지식만으로 답하는 대신, 질문에 맞는 근거를 찾아 함께 제공합니다. RAG 원 논문은 검색 가능한 외부 자료와 생성 모델을 결합하는 접근을 제시했습니다.

질문 → 관련 자료 검색 → 필요한 근거 구성 → 답변 생성 → 출처와 내용 확인

자료를 준비하는 과정도 필요합니다. 문서를 검색 가능한 단위로 나누고, 원문 위치·작성일·시행일·접근 권한 같은 정보를 보존합니다. 벡터 검색을 쓴다면 임베딩과 인덱스를 만들지만, 이것이 모든 RAG의 필수 구성은 아닙니다.

청킹과 임베딩은 검색을 구성하는 선택이다

긴 문서를 검색 단위로 나누는 청킹과, 텍스트를 벡터로 표현하는 임베딩은 RAG의 검색을 구성하는 데 쓰일 수 있습니다. 모든 RAG가 같은 크기로 문서를 나누거나 벡터 검색만 사용하는 것은 아닙니다.

규정의 본문과 예외 조항을 떨어뜨려 저장했다면 관련 문장을 찾아도 적용 조건을 놓칠 수 있습니다. 비슷한 표현의 문서가 검색됐다는 것과 이번 질문에 유효한 근거를 찾았다는 것을 나누어 확인합니다. 원문 구조, 검색 방식, 답변 검증을 함께 살펴야 수정할 지점을 찾을 수 있습니다.

어디서 실패했는지 나누어 본다

문서 정리가 중요한 이유는 분명합니다. 그러나 ‘RAG의 성패는 검색 기술과 무관하고 문서 상태만이 결정한다’고 설명하면 다른 실패 원인을 놓칩니다. 같은 원문도 검색과 문맥 구성에 따라 다른 답을 만들 수 있습니다.

BOAZ의 위키 경험에서 확인한 구분

교안·제안·실제 진행 기록은 같은 프로그램 이름을 쓸 수 있습니다. 이를 함께 검색할 때 ‘계획한 일’과 ‘실제로 한 일’을 나누지 않으면 잘못된 답이 나옵니다. BOAZ는 위키에서 원문 위치와 확인 상태를 남기고 새 결정이 기존 설명을 바꾸는지 검토합니다.

이것은 RAG가 반드시 기억을 잃는다는 뜻이 아닙니다. 검색 시스템에도 이력·메타데이터·기억·갱신 기능을 설계할 수 있습니다. 핵심은 어떤 지식을 어떤 상태로 답변에 넣는지입니다.

비슷해 보이는 개념과의 차이

MCP가 있어야만 RAG를 만들 수 있는 것도, RAG가 있어야만 에이전트가 파일을 읽을 수 있는 것도 아닙니다.

많이 넣는 것보다 필요한 근거를 평가한다

자료를 더 넣으면 빠진 배경을 보완할 수 있지만 무관한 내용이나 서로 다른 기준도 늘어날 수 있습니다. 몇 개를 검색할지, 어떤 자료를 우선할지, 근거가 없을 때 어떻게 답할지는 실제 업무 질문으로 평가합니다. Attention의 가중치 합만으로 적절한 문서 수를 정할 수는 없습니다.

처음에는 반복 질문과 기대 근거를 함께 정리합니다. 검색이 그 근거를 찾았는지, 답변이 근거보다 강한 주장을 하지 않는지, 근거를 찾지 못하면 확인 필요라고 표시하는지 확인합니다.

도입 전에 정할 운영 조건

읽을 수 있는 자료와 권한, 현행 문서의 판단 기준, 출처 추적, 지식 갱신 담당과 절차를 정합니다. 연결이 작동하는 것과 최신·정확한 답을 유지하는 것은 다른 확인 항목입니다.