서로 다른 세 문제를 한 기술로 해결할 수 없다
RAG는 질문에 답하기 전에 관련 문서를 검색하여 근거를 추가하는 구조다. 긴 컨텍스트는 그때 필요한 문서 내용을 모델 입력에 직접 넣는 방식이다. 파인튜닝은 학습 예시를 이용해 작업 스타일이나 특정 패턴의 수행을 조정하려는 접근이다. 최신 규정을 찾는 문제와 일관된 분류 결과를 만드는 문제는 서로 다른 목표를 갖는다.
OpenAI의 파일 검색 공식 문서에서는 벡터 저장소에 올린 문서를 의미 기반과 키워드 기반으로 검색해 응답에 참고하는 방법을 설명한다.[1] Retrieval 문서에는 검색 가능한 파일을 청크로 나누고 인덱싱하는 절차가 소개되어 있다.[2] 그러나 검색 결과가 나온다는 사실만으로 문서가 정확하거나 최신이라는 보장은 없다.
200개 문서를 대상으로 한 사례 설계
사내 문서 200개, 월 10개 개정, 하루 100번 질문을 받는다고 가정하자. 긴 컨텍스트 방식은 질문할 때마다 필요한 문서를 직접 입력해야 할 수 있다. RAG는 관련 문서 일부를 검색해 맥락으로 전달하는 방식을 택할 수 있다. 여기의 수치는 이해를 돕는 가상 업무 환경이며 기술 간 실측 우위를 나타내는 벤치마크가 아니다.
문서의 최신성은 모델보다 인덱스와 버전 관리 문제일 수 있다. 검색 대상에 폐기된 2024년 업무 규정이 그대로 남으면 언어 모델이 오래된 규정을 자신 있게 인용할 수 있다. 파일별 유효일과 폐기 시점을 기록하고 답변에 어느 버전의 어떤 단락을 사용했는지 표시해야 한다.
파인튜닝의 적합한 용도와 오해
많은 문서를 모델에 학습시키면 질문에 항상 정확하게 답할 것이라고 기대하기 쉽지만, 매주 바뀌는 요금표를 파인튜닝만으로 최신화하는 접근은 운용 부담이 크다. 답변 문체를 일정하게 하거나 정형 분류를 개선하려는 목적이라면 별도 실험 가치가 있다.
OpenAI 파인튜닝 API는 지원 모델과 훈련 데이터를 지정하는 절차를 제공한다.[3] 이는 모든 모델이 동일한 파인튜닝 기능을 지원한다는 뜻은 아니다. 실제 지원 여부와 가격은 모델 버전별로 다를 수 있으므로 구성 전에 현재 문서를 확인해야 한다.
진짜 비용은 토큰 가격 외에도 존재한다
긴 컨텍스트는 초기 검색 파이프라인이 단순할 수 있지만 반복해서 긴 문서를 입력하는 비용이 생길 수 있다. RAG에는 색인 생성과 업데이트, 저장소 관리, 검색 품질 평가가 더해진다. 파인튜닝에는 데이터 정리, 성능 테스트와 모델 갱신 문제가 발생한다. 서비스 요금표만으로 일괄적인 우열을 계산하면 안 된다.
평가할 때는 질문 100개를 직접 만들고 정답 여부, 적절한 출처 인용률, 오래된 문서 사용률, 응답 시간, 질문당 비용, 접근권한 위반 건수를 비교한다. 숫자는 평가 계획을 위한 예시이며 서로 다른 모델과 서비스의 실제 성능을 대표하지 않는다.
검증 가능한 설계부터 시작한다
처음에는 권한이 구분된 문서 저장소, 오래된 자료의 만료 처리, 검색 근거 표시를 갖춘 단순한 시스템부터 시작한다. 답을 찾지 못했을 때 억지로 생성하지 않고 확인할 문서를 제시하게 하는 실패 처리도 중요하다.
RAG와 긴 컨텍스트, 파인튜닝은 상호 배타적이지 않다. 최신 문서를 검색하고 짧은 규칙은 직접 전달하며 특정 출력 오류가 반복될 때만 추가 학습을 실험할 수 있다. 다만 구성 요소가 늘면 원인 분석이 어려워지므로 기초 버전을 먼저 측정해야 한다.
비교 실험에서 자주 빠지는 검증 항목
최신 정책과 구버전 정책이 동시에 저장된 환경을 가정하면, 시스템이 정답 문장을 찾아도 실제 적용 날짜가 틀릴 수 있다. 그래서 질문마다 유효 날짜와 문서 버전을 맞추는 항목을 독립 채점해야 한다. 단순 검색 성공률과 올바른 근거를 사용한 답변 비율은 서로 다른 지표이며, 결과에 표시된 링크가 정말 해당 근거로 연결되는지도 확인해야 한다.
또한 시스템의 응답이 불확실할 때 정답을 만들어 내지 않고 확인 요청으로 넘어가는 비율을 측정할 수 있다. 모델을 바꿔 성능이 좋아 보일 때도 검색 인덱스의 갱신 시간과 문서 접근 범위가 동일했는지 기록해야 공정한 비교가 된다. 자료 확보와 보안 정책이 준비되지 않았다면 복잡한 모델 변경보다 원본 관리부터 정리하는 편이 우선이다.