RAG 검색 단계 구현 가이드: Top-K 설정과 벡터 검색으로 문서 기반 챗봇 만들기

핵심 메시지

• Top-K는 벡터 데이터베이스에서 몇 개의 조각을 꺼내 LLM에 넘길지를 정하는 값으로, 검색 품질과 비용을 동시에 좌우한다.
• K가 너무 작으면 필요한 정보를 놓치고, 너무 크면 토큰 비용과 지연이 늘며 관련 없는 내용이 섞여 환각을 부를 수 있다.
• 질문은 저장 단계와 같은 방식으로 임베딩한 뒤 코사인 유사도로 검색하고, 점수가 붙은 상위 결과를 문맥으로 묶어 프롬프트에 넣는다.
• 프롬프트에 "모르면 모른다고 답하라"는 지시를 넣으면 문서 밖 질문에 대해 실제로 모른다고 답하는 것을 시연으로 확인했다.
• 로컬 LLM 응답을 하나의 JSON으로 받으려면 스트리밍 옵션을 꺼야 한다는 실전 함정도 그대로 보여준다.

쉽게 이해하기

이 영상은 RAG 시리즈의 여섯 번째 편으로, 문서를 잘라 임베딩해 벡터 데이터베이스에 넣는 앞 단계가 끝난 뒤의 검색 단계를 다룬다. 사용자의 질문을 받아 답을 만들어 내는 부분, 즉 실제 챗봇이 동작하는 구간이다. 설명은 Top-K 개념에서 시작해 질문 임베딩, 벡터 검색, 프롬프트 구성, 로컬 LLM 호출까지 코드로 이어진다.

Top-K는 데이터베이스에서 질문과 가장 관련 있는 조각을 몇 개나 꺼내 LLM에 문맥으로 넘길지를 정하는 숫자다. 질문이 벡터로 변환되면 저장된 전체 조각과 비교해 순위가 매겨지고, 상위 K개가 각각의 점수와 함께 반환된다. 발표자는 이 값을 설정 가능한 값으로 두고, 문서가 작으면 3에서 5, 문서가 크면 5에서 10 정도를 기준으로 제시한다.

K를 어떻게 잡느냐에 따라 얻는 것과 잃는 것이 갈린다. 값이 작으면 검색이 빠르고 토큰 사용이 줄지만 다른 조각에 있던 중요한 정보를 놓칠 수 있다. 값이 크면 더 많은 문맥을 넘길 수 있는 대신 토큰 비용이 늘고 검색과 응답에 시간이 더 걸리며, 관련 없는 내용까지 들어가 모델이 엉뚱한 답을 만들어 낼 위험이 생긴다.

구현은 단순한 흐름을 따른다. 사용자에게 질문을 입력받고, 저장 단계에서 쓰던 임베딩 함수를 그대로 호출해 질문을 벡터로 바꾼다. 그다음 벡터 데이터베이스의 검색 메서드에 컬렉션 이름과 질문 벡터, 그리고 Top-K에 해당하는 limit 값을 넘겨 상위 결과를 받는다. 반환된 각 결과의 페이로드에서 본문 텍스트를 꺼내 하나로 이어 붙이면 프롬프트에 넣을 문맥이 완성된다.

프롬프트는 모델의 역할을 지정하는 시스템 지시, 검색으로 얻은 문맥, 사용자의 질문, 그리고 모르면 모른다고 답하라는 단서로 구성된다. 이렇게 만든 프롬프트를 로컬에서 돌아가는 Ollama의 생성 엔드포인트로 보내 답을 받는다. 시연에서는 사내 정책 문서를 대상으로 휴가 관련 질문을 던지자 문서에서 근거를 찾아 답했고, 문서에 없는 질문에는 정보가 없다고 답했다.

주요 인사이트

• RAG의 성능 문제를 모델 탓으로 돌리기 전에 Top-K부터 점검할 필요가 있다. 몇 개를 넘기느냐가 정확도, 비용, 지연을 한꺼번에 움직이는 손잡이이기 때문이다.
• 문맥을 많이 넣을수록 좋다는 직관은 틀리기 쉽다. 관련 없는 조각이 섞이면 오히려 모델이 잘못된 답을 만들어 낼 수 있다는 점을 발표자가 분명히 짚는다.
• 질문 임베딩은 반드시 문서를 저장할 때 쓴 방식과 같아야 한다. 영상에서도 저장 단계에서 만든 함수를 그대로 재사용하고 모델 이름은 설정 파일에서 가져온다.
• 검색 결과에는 점수가 함께 오므로, 답이 이상할 때 어떤 조각이 어떤 점수로 뽑혔는지 출력해 보는 것이 가장 빠른 진단 방법이다.
• "모르면 모른다고 답하라"는 한 줄의 지시가 실제로 문서 밖 질문을 걸러내는 데 작동했다. 프롬프트 설계가 검색만큼이나 답변 신뢰도에 영향을 준다.

자주 묻는 질문

관련 AI 소식