RAG 기본 구조
3줄 요약
- RAG는 Retrieval-Augmented Generation으로, 외부 문서를 검색해 모델 답변의 근거로 넣는 구조다.
- 핵심은 vector DB가 아니라 질문 변환, 검색, reranking, context 조립, 답변 생성, source 추적의 전체 파이프라인이다.
- 백엔드에서는 RAG를 데이터 접근, 권한, 검색 인프라, 모델 호출이 결합된 기능으로 봐야 한다.
핵심 정리
- RAG는 모델의 사전 지식에만 의존하지 않고 최신/사내/도메인 문서를 근거로 답하게 한다.
- 검색 결과가 틀리면 좋은 모델도 틀린 답을 할 수 있다.
- 검색 결과가 맞아도 context 조립과 prompt가 나쁘면 답변이 틀릴 수 있다.
- source id, document version, prompt version, retrieval profile을 trace로 연결해야 한다.
- RAG는 hallucination을 줄이지만 완전히 없애지는 못한다.
헷갈리는 지점
- RAG는 vector DB를 붙이면 끝이라고 생각하기 쉽다.
- 핵심은 검색 전후 파이프라인과 권한, 평가가 더 중요할 때가 많다는 점이다.
- vector DB는 구성 요소 중 하나다.
- RAG는 fine-tuning의 대체재라고 단순화하기 쉽다.
- 핵심은 둘의 목적이 다르다는 점이다.
- RAG는 외부 지식 주입, fine-tuning은 행동 패턴이나 특정 작업 적응에 가깝다.
확인 질문
- RAG의 핵심 구성 단계는 무엇인가?
- 문서 색인, query 생성, retrieval, filtering, reranking, context 조립, generation, source 추적이다.
- RAG를 써도 답변이 틀리는 이유는 무엇인가?
- 검색 실패, 오래된 문서, 권한 오류, context 조립 문제, 모델 해석 오류가 남기 때문이다.
RAG 권한과 최신성
3줄 요약
- RAG에서 가장 위험한 문제는 권한 없는 문서나 삭제된 문서가 context에 들어가는 것이다.
- 권한 필터는 모델에게 맡기지 말고 검색 전후 서버에서 강제해야 한다.
- 최신성은 유사도 점수만으로 보장되지 않으므로 document version과 updated_at을 ranking과 trace에 반영한다.
핵심 정리
- tenant, role, document ACL, deleted flag는 retrieval 전에 적용되어야 한다.
- 검색 후 source id로 DB 권한을 재확인하는 방어도 유용하다.
- 문서 삭제와 권한 변경 이벤트가 vector index에 반영되어야 한다.
- 오래된 문서가 더 높은 vector score를 가질 수 있으므로 freshness signal이 필요하다.
- 답변에는 source와 문서 버전을 남기는 편이 디버깅에 좋다.
헷갈리는 지점
- 프롬프트에 권한 없는 문서는 답하지 말라고 적으면 충분하다고 생각하기 쉽다.
- 핵심은 권한 없는 데이터가 이미 모델 입력에 들어가면 늦다는 점이다.
- 권한은 서버에서 강제해야 한다.
- 최신 문서가 자동으로 검색 상위에 온다고 생각하기 쉽다.
- 핵심은 vector similarity는 최신성을 알지 못한다는 점이다.
확인 질문
- RAG 권한 필터는 어디서 강제해야 하는가?
- retrieval 전후 서버와 vector filter에서 강제하고, 모델 프롬프트는 보조로만 사용한다.
- 최신성 문제를 줄이려면 어떤 metadata가 필요한가?
- updated_at, document version, deleted flag, source id가 필요하다.
RAG 평가와 운영
3줄 요약
- RAG 평가는 retrieval eval과 answer eval을 분리해야 한다.
- 운영에서는 retrieval empty rate, source precision, answer groundedness, validation failure, latency, 비용을 본다.
- RAG 장애는 검색 인프라와 모델 호출, context 조립이 모두 관련되므로 trace가 필수다.
핵심 정리
- retrieval eval은 적절한 문서를 찾았는지 본다.
- answer eval은 찾은 문서를 바탕으로 올바르게 답했는지 본다.
- source 표시와 trace가 없으면 사용자 신고를 재현하기 어렵다.
- RAG 품질 개선은 chunking, query rewrite, reranking, prompt, model 모두에 영향을 받는다.
- 운영 RAG는 문서 업데이트 lag와 색인 실패도 품질 지표로 봐야 한다.
헷갈리는 지점
- 최종 답변만 평가하면 충분하다고 생각하기 쉽다.
- 핵심은 검색이 틀린 것인지 생성이 틀린 것인지 구분해야 개선할 수 있다는 점이다.
- RAG 평가는 한 번 만들면 끝이라고 생각하기 쉽다.
- 핵심은 문서와 사용자 질문이 계속 변하므로 eval도 계속 보강해야 한다는 점이다.
확인 질문
- retrieval eval과 answer eval을 분리해야 하는 이유는 무엇인가?
- 검색 단계 문제와 생성 단계 문제를 구분해야 개선 방향을 정할 수 있기 때문이다.
- RAG 운영에서 trace에 남기면 좋은 것은 무엇인가?
- query, retrieval profile, source id, document version, prompt version, model, token usage다.