RAG란 무엇인가: 문서를 검색한 뒤 답변하는 LLM의 구조 > 블로그

블로그

RAG는 검색 증강 생성의 약자로, 질문과 관련된 외부 자료를 찾은 뒤 그 내용을 참고해 언어 모델이 답변하도록 구성하는 방식입니다. 사내 규정이나 제품 설명서처럼 별도로 관리되는 자료를 질문에 활용할 때 등장하는 개념입니다.

핵심은 모델이 이미 학습한 내용만으로 답하도록 두는 대신, 답변에 필요한 자료를 질문과 함께 제공한다는 점입니다.

핵심 정리
RAG는 관련 자료를 검색해 모델의 답변 문맥에 추가하는 구조입니다. 검색 품질과 답변의 근거 일치를 나누어 확인합니다.

1. 검색과 답변 생성을 나누어 봅니다

일반적인 흐름은 질문 입력, 관련 자료 검색, 참고 문맥 구성, 답변 생성 순서로 이해할 수 있습니다. 검색기는 질문과 맞는 문서 일부를 찾아오고, 언어 모델은 전달받은 내용을 바탕으로 문장을 만듭니다.

두 과정의 역할이 다르므로 답변이 틀렸을 때도 어디에서 문제가 생겼는지 나누어 살펴야 합니다. 자료를 못 찾은 것인지, 찾은 자료를 잘못 해석한 것인지는 다른 문제입니다.

긴 문서를 그대로 한 덩어리로 다루기보다 적절한 구간으로 나누는 구성이 흔하며, 나눈 단위를 청크라고 부릅니다. 청크가 너무 짧으면 설명의 앞뒤가 끊길 수 있고 너무 길면 질문과 관계없는 내용이 함께 들어갈 수 있습니다.

문서 제목, 작성일, 항목 이름 같은 정보도 검색 결과를 해석하는 데 도움이 됩니다. 표나 목록은 문장을 나누는 과정에서 관계가 사라지지 않는지 확인해야 합니다.

임베딩은 텍스트 등을 숫자 벡터로 표현하는 방법입니다. 벡터를 사용하는 검색에서는 질문과 문서의 표현을 비교해 관련성이 높은 후보를 찾습니다.

다만 RAG가 반드시 벡터 검색만 사용해야 하는 것은 아닙니다. 단어 기반 검색을 활용하거나 서로 다른 검색 방식을 함께 사용할 수도 있습니다. 어떤 검색 구성이 적합한지는 문서 성격과 실제 질문으로 확인할 문제입니다.

검색 결과에는 중복된 내용이나 질문과 관련성이 낮은 구간이 섞일 수 있습니다. 필요한 결과를 추리고 순서를 조정하는 단계가 그래서 중요합니다.

모델이 한 번에 처리할 수 있는 문맥의 범위도 고려해야 합니다. 자료를 많이 넣었다는 사실만으로 답변이 좋아지는 것은 아닙니다. 질문의 답이 담긴 부분을 충분한 맥락과 함께 전달했는지가 핵심입니다.

예를 들어 직원이 교육비 신청 절차를 묻는 상황을 생각해 볼 수 있습니다. 시스템은 관련 규정을 찾고, 신청 대상과 제출 항목이 담긴 부분을 모델에 전달합니다.

모델은 그 자료를 읽고 절차를 정리합니다. 이때 검색 대상에 예전 규정만 들어 있다면 답변도 오래된 내용을 따를 수 있습니다. 문서를 준비할 때 버전과 적용 시점을 함께 관리해야 한다는 뜻입니다.

답변에 문서 링크를 붙일 수 있다는 점은 검토에 유용하지만, 링크가 있다는 이유만으로 내용 전체를 믿을 수는 없습니다. 실제 인용 구간이 질문에 답하는지, 생성된 문장이 자료에 없는 내용을 덧붙이지 않았는지 확인해야 합니다.

관련 자료를 찾지 못했을 때는 근거가 부족하다고 알리는 처리도 필요합니다. RAG는 근거를 제공하는 구조이며 오류 가능성을 없애는 이름은 아닙니다.

파인튜닝은 추가 학습으로 모델의 가중치를 조정하는 접근입니다. RAG는 일반적으로 질문을 처리할 때 가져오는 외부 문맥을 구성하는 접근입니다.

답변 형식이나 과업 수행 방식을 학습시키려는 요구와, 관리 중인 문서를 답변에 참고시키려는 요구는 구분해서 볼 수 있습니다. 둘은 반드시 하나만 골라야 하는 관계가 아니며, 필요한 경우 함께 사용할 수도 있습니다.

처음에는 실제로 받을 만한 질문과 답의 근거 문서를 한 쌍씩 준비해 봅니다. 검색 결과에 필요한 문서가 들어오는지, 답변이 그 근거와 맞는지를 따로 기록합니다.

정답이 문서에 없는 질문도 넣어 무리하게 답을 만드는지 확인합니다. 질문·검색·생성을 나누어 관찰하면 모델을 바꿔야 할 문제와 문서 정리부터 고쳐야 할 문제를 구별하는 데 도움이 됩니다.