Retrieval-Augmented Generation
RAG는 질문 시점에 외부 지식을 검색해 그 결과를 모델 컨텍스트에 넣고 답변을 생성하는 패턴입니다. 모델 내부에 이미 기억된 내용만 믿지 않고, 현재 질문에 맞는 근거를 바깥에서 끌어와 답변을 grounding하는 데 목적이 있습니다.
▶아키텍처 다이어그램
🔄 프로세스 다이어그램점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
모델 파라미터에만 기대면 최신 정보나 사내 비공개 문서, 자주 바뀌는 운영 정책을 반영하기 어렵습니다. 그 결과 답은 그럴듯하지만 오래됐거나, 근거가 약하거나, 아예 문서에 없는 이야기를 지어낼 수 있습니다. 이런 상황에서 문제는 모델이 '똑똑하지 않다'가 아니라 필요한 근거가 호출 시점에 연결되지 않는다는 데 있습니다.
많은 팀이 문서가 바뀔 때마다 모델을 다시 학습시키는 것은 현실적이지 않다는 점을 빠르게 깨달았습니다. 검색은 문서 변경에 더 잘 적응하고, 비공개 지식도 모델 안에 집어넣지 않고 다룰 수 있기 때문에, RAG가 많은 업무형 LLM 앱의 기본 패턴으로 자리 잡았습니다.
흐름은 보통 질문 정규화, 검색, 상위 chunk 선택, 컨텍스트 패킹, 답변 생성 순서로 이어집니다. 어떤 시스템은 검색 전에 질문을 다시 써서 recall, 즉 관련 근거를 놓치지 않고 데려오는 비율을 높이고, 어떤 시스템은 재순위화를 거쳐 상위 chunk를 더 엄격히 고릅니다. 결국 답변 품질은 생성 모델 하나가 아니라 retrieval과 context packaging까지 묶인 파이프라인 전체에서 결정됩니다.
RAG, memory, tool use는 모두 모델 밖의 정보를 현재 답변에 연결하지만 목적이 다릅니다. 질문마다 외부 문서를 근거로 붙여야 하면 RAG를 보고, 사용자 선호나 진행 상태를 이어야 하면 memory를 보고, 검색만으로 부족하고 계산이나 상태 변경이 필요하면 tool use를 봐야 합니다. 문서 근거가 있다고 해서 여러 출처 조정이나 실제 행동까지 자동으로 해결되지는 않는다는 점이 한계입니다.
실무에서는 제품 문서, 사내 위키, 정책 검색, 고객 지원에서 가장 많이 쓰입니다. 다만 질문이 단순 문서 검색이 아니라 계산, 상태 변경, 여러 출처 합성까지 요구할 때는 RAG만으로는 한계가 드러납니다. 그 시점부터는 도구 호출, 메모리, 평가 체계가 함께 필요해집니다.