언어 모델(Language models)은 유창하지만, 학습 과정에서 본 내용만 알고 있습니다. 자신의 보고서에 대해 질문하면 접근할 수 없다고 인정하거나, 더 나쁜 경우 추측하게 됩니다. Valentius Kryptix에서의 인턴십 기간 동안 저는 작은 검색 증강 생성 (Retrieval-Augmented Generation, RAG) 시스템을 구축하여 모델이 사용자의 문서를 먼저 읽을 수 있게 되었을 때 얼마나 향상되는지 확인했습니다.
1분 만에 이해하는 아이디어
RAG는 두 단계로 이루어져 있습니다. 첫 번째 검색(Retrieval)은 질문과 가장 관련성이 높은 문서의 구절들을 찾아냅니다. 다음으로 생성(Generation) 단계에서는 이 구절들을 질문과 함께 모델에게 전달하고, 오직 그 문맥(context)만을 기반으로 답변하도록 지시합니다. 이때 모델 자체는 재학습되지 않습니다. 단지 적절한 순간에 올바른 텍스트를 받게 되는 것입니다.
제가 구축한 것
Python, Chroma, 그리고 Gemini를 사용하여 총 약 9,000단어 분량의 두 개의 실제 문서(제 프롬프트 엔지니어링 보고서와 농업 비즈니스 예측에 대한 긴 노트 세트)를 입력했습니다. 이 텍스트는 대략 2,000자 크기의 40개 중첩된 청크(chunk)로 변환되었습니다. 각 청크는 임베딩되어 로컬 Chroma 데이터베이스에 저장되었습니다. 질문이 들어올 때마다 시스템은 상위 4개 청크를 검색하여 프롬프트에 배치합니다.
간단한 테스트
저는 “제 프롬프트 엔지니어링 보고서에서 V1의 스키마 일치율(schema match rate)은 얼마였나요?”라고 질문했습니다.
일반 모델(plain model)은 파일 접근 권한이 없다고 답했습니다. 반면 RAG 버전은 제 보고서에서 세 개의 청크를 검색했고, 그중 하나가 정확한 결과를 포함하고 있어 1/6이라고 답변했으며, 이는 보고서 내용과 일치합니다. 이것은 단 하나의 테스트일 뿐이지만, 파이프라인이 작동한다는 것을 보여줄 뿐 완벽하다는 것을 증명하는 것은 아닙니다.
세 가지 교훈
1. 청킹(Chunking)은 설계 결정입니다. 너무 큰 청크는 노이즈를 포함하고, 너무 작은 청크는 문맥을 잃게 합니다. 오버랩(Overlap)과 단락 또는 문장 경계에서 자르는 것이 각 조각들을 읽기 쉽게 유지했습니다.
2. 모델을 비난하기 전에 검색 단계부터 살펴보세요. 저는 생성 단계에 연결하기 전에 검색된 청크들을 출력해 보았습니다. 한 테스트에서는 네 번째 청크가 관련 없는 노트 부분에서 온 것입니다. 답변은 여전히 정확했지만, 상위-k 검색(top-k search)이 완벽하지 않다는 것을 보여주었습니다.
3. 지침(Instructions)이 중요하다. 모델에게 주어진 컨텍스트만을 사용하여 답변하도록 하고, 답변을 찾을 수 없을 때는 그 사실을 명시하도록 지시하면, 모델의 동작을 신뢰하고 테스트하기가 더 쉬워진다.
한계점(Limits)
내 시스템은 작다: 문서 2개, 질문당 실행 1회, 고정된 top-4 검색을 사용한다. 다음으로는 재순위화(re-ranking)를 시도하고, 다양한 청크 크기를 비교하며, 더 큰 규모의 질문 세트에서 검색 품질을 측정해보고 싶다.
전체 기사 읽기
이것은 축소된 버전이다. 스크린샷과 RAG 사용 여부 비교가 포함된 완전한 상세 가이드(walkthrough)를 보려면, Valentius Kryptix 블로그의 원본 게시물을 읽어보라:
전체 기사 읽기
https://valentiuskryptix.com/powerful-rag-chatbot-reliable-answers-from-your-own-documents/
코드: https://github.com/samruddhishirgave-droid/rag-chatbot