질의 중심(Query-Centric) 데이터 설계를 통한 Q&A 기반 VOC 챗봇의 검색 실패 개선 사례
본문의 질문·답변과 데이터 구조 예시는 원리를 설명하기 위한 가상 사례입니다. 아키텍처 그림은 기술적 역할을 단순화한 개념도입니다.
1. 정답이 있는데도 검색되지 않는 문제
검색 증강 생성(RAG, Retrieval-Augmented Generation) 기반 챗봇에서 답변이 틀리면 대규모 언어 모델(LLM, Large Language Model)의 생성 품질부터 의심하기 쉽습니다.
그러나 정답에 해당하는 질문·답변(Q&A, Question and Answer) 데이터가 이미 존재하는데도 다른 문서가 먼저 검색된다면 문제는 답변 생성보다 앞선 검색(Retrieval) 단계에서 시작됩니다.
Q&A 기반 고객의 소리(VOC, Voice of Customer) 챗봇을 구축하는 과정에서 이와 같은 검색 실패(Retrieval Failure)를 분석했습니다. 초기 구조에서는 질문과 상세 답변을 함께 검색 인덱스에 저장했습니다.
검색에는 키워드 검색 알고리즘인 BM25(Best Matching 25), 임베딩 기반 최근접 이웃 검색(KNN, K-Nearest Neighbors), 역순위 융합(RRF, Reciprocal Rank Fusion)을 결합한 하이브리드 검색(Hybrid Retrieval)을 사용했습니다.
문제는 사용자의 짧은 질문과 직접 대응하는 Q&A가 있는데도, 다른 Q&A의 상세 답변에 포함된 단어와 부가 문맥이 검색 순위에 영향을 줄 수 있다는 점이었습니다. 정답보다 설명이 많은 항목이 더 관련성 높은 후보로 평가되는 현상이 나타났습니다.
기존 검색 엔진과 검색 로직은 그대로 유지해야 했습니다. 따라서 모델 교체나 검색 알고리즘 수정 대신, 제어할 수 있는 요소인 검색 대상 데이터의 구성 방식을 변경했습니다. 검색용 텍스트를 사용자 질의 중심으로 다시 설계하고 상세 답변을 별도의 답변 데이터베이스(DB, Database)에서 관리하도록 분리한 것입니다.
이 글에서는 문제를 BM25·KNN·RRF의 관점에서 살펴보고, 변경한 데이터 구조와 그 의미, 그리고 적용 시 주의할 점을 정리합니다.
2. 기존 구조: 질문과 상세 답변 전체를 인덱싱
초기 구조에서는 하나의 Q&A를 하나의 검색 단위로 다루었습니다. 사용자의 질문과 이에 대한 상세 답변을 함께 인덱싱하고, 검색된 문서를 LLM의 응답 근거로 전달했습니다.
그림 1. 개선 전 개념도. 질문과 상세 답변이 모두 검색 대상이며, 동일한 검색 데이터가 BM25와 KNN 경로에 사용됩니다.
검색 과정은 다음과 같습니다.
- 사용자 질의를 입력받습니다.
- BM25는 키워드 기반으로, KNN은 임베딩 벡터 유사도 기반으로 검색합니다.
- RRF는 두 검색 결과의 순위를 결합합니다.
- 상위 K개(Top-K) 후보 문서를 LLM에 제공해 응답을 생성합니다.
이 방식은 반드시 잘못된 설계가 아닙니다. 상세 답변에 질문에는 없는 용어나 문맥이 포함돼 있어 검색에 도움이 될 수도 있습니다. 문서에서 관련 근거를 폭넓게 찾아야 하는 서비스에서는 장점이 될 수 있습니다.
하지만 여기서 요구한 것은 짧은 사용자 질문을 사전에 정의된 적절한 Q&A 항목에 매칭하는 작업이었습니다. 검색의 목표가 ‘풍부한 문맥 검색’보다 ‘질문 의도와 답변 항목의 연결’에 가까웠기 때문에 데이터 구성 방식이 중요해졌습니다.
3. 문제 사례: 검색어와 직접 관련이 없는 답변이 상위 후보로 등장
다음은 원리를 설명하기 위한 가상 사례입니다.
사용자 질문: 비밀번호 변경 방법
| 검색 후보 | 등록된 질문 | 답변에 포함된 내용 | 질의 의도와의 관계 |
|---|---|---|---|
| 문서 A | 로그인 오류 해결 방법 | 비밀번호 확인, 본인인증, 비밀번호 변경·재설정 안내, 계정 잠금, 고객센터 안내 | 관련 단어는 많지만 직접적인 답은 아님 |
| 문서 B | 비밀번호 변경 방법 | 로그인 후 설정 메뉴에서 비밀번호를 변경하는 절차 | 직접적인 정답 |
사용자는 비밀번호를 변경하는 방법을 묻고 있으므로 의도에 맞는 문서는 B입니다.
그러나 A의 긴 답변에는 비밀번호, 변경, 재설정, 인증 등 다양한 관련 표현이 포함될 수 있습니다. 전체 답변이 검색 대상일 때는 이러한 표현이 키워드 매칭이나 의미 검색에 영향을 줍니다.
핵심은 긴 문서가 무조건 높은 점수를 받는다는 뜻이 아니라 질문의 핵심 의도와 다른 문제의 해결 절차까지 검색 신호로 사용된다는 점입니다.
부적절한 문서가 상위 후보를 차지하고 정답 문서가 Top-K에서 누락되면, 그 뒤의 LLM이 정답 근거를 활용하기 어려워집니다. 따라서 최종 응답을 보기 전에 검색 단계의 후보와 순위를 따로 확인해야 합니다.
그림 2. BM25와 KNN 모두에서 잘못된 후보가 상위에 배치될 경우, RRF 결합 결과에도 영향을 줄 수 있음을 보여주는 개념도(예시 순위).
4. 원인 분석: 세 검색 단계에서 어떤 일이 일어났을까?
4.1. BM25 — 상세 답변의 부가 키워드가 매칭 신호가 되다
BM25는 질의 단어의 출현, 단어의 희소성, 단어 빈도, 문서 길이 등을 반영합니다. 단어가 많이 등장한다고 점수가 무제한 상승하는 것은 아니며, 문서 길이 정규화도 적용합니다.
그럼에도 검색하고자 하는 질문과 직접 관계없는 Answer 내용까지 인덱싱하면 부가 키워드가 관련성 계산에 참여합니다. 로그인 오류 안내문에 ‘비밀번호 변경’이 등장한다는 이유로, 비밀번호 변경 방법을 묻는 질의와 매칭되는 상황이 생길 수 있습니다.
따라서 이 사례에서의 문제는 ‘BM25가 긴 답변을 선호한다’는 일반화보다 답변에 포함된 부가 키워드가 검색 목적과 어긋난 매칭 신호를 만들었다고 설명하는 편이 정확합니다.
4.2. KNN — 질문의 의도와 답변의 부가 의미가 한 벡터에 반영되다
임베딩 기반 검색은 텍스트를 벡터로 표현해 사용자 질문과 검색 문서 간 유사도를 계산합니다.
질문과 답변을 결합해 임베딩하면 질문의 의도뿐 아니라 답변에 포함된 예외 상황, 관련 절차, 후속 조치 등의 문맥도 벡터 표현에 영향을 줄 수 있습니다.
예를 들어 ‘로그인 오류 해결 방법’이라는 질문의 임베딩에 비밀번호 변경·인증·계정 잠금 등의 안내 내용이 함께 반영되면, ‘비밀번호 변경 방법’이라는 짧은 질의와 예상보다 가까운 벡터 관계가 만들어질 가능성이 있습니다.
이 역시 긴 답변은 임베딩에 불리하다는 일반 법칙이 아닙니다. 임베딩이 담는 정보의 범위가 특정 Q&A를 정밀하게 매칭하려는 검색 목표와 어긋날 수 있다는 의미입니다.
4.3. RRF — 두 검색 경로의 순위가 결합되다
RRF는 BM25의 원점수와 KNN의 유사도 값을 직접 합산하지 않고, 각 검색 경로에서의 순위를 이용해 결과를 결합합니다. 일반적인 식은 다음과 같습니다.
RRF(d) = Σ [1 / (k + rank_i(d))], i ∈ R
여기서 rankᵢ(d)는 검색 경로 i에서 문서 d의 순위이며, k는 순위 영향도를 조절하는 상수입니다. 이 k는 최종 검색 결과 개수를 의미하는 Top-K와는 다른 값입니다.
또한 문서가 어떤 경로의 결과에 존재하지 않으면 해당 경로의 항은 합산하지 않습니다. 이는 일반적인 알고리즘 설명이며 특정 시스템의 설정값을 나타내지 않습니다.
잘못된 문서가 BM25와 KNN 모두에서 상위에 위치하면 RRF에서도 높은 순위를 받을 수 있습니다. RRF가 오류를 생성한다기보다는, 검색 입력 데이터에서 비롯된 편향이 양쪽 경로에 공통으로 나타날 때 이를 자동으로 교정하지 못하는 것입니다.
세 단계를 종합하면, 검색 알고리즘을 개선하기 전에 무엇을 검색 대상으로 삼는지부터 검토해야 한다는 결론에 도달했습니다.
5. 설계 전환: 답변 중심(Answer-Centric)에서 질의 중심(Query-Centric)으로
기존 검색 엔진과 BM25·KNN·RRF 구조를 변경할 수 없는 조건에서, 검색 인덱스에 저장할 데이터의 역할을 다시 정의했습니다. 검색 결과는 답변 식별자(ID, Identifier)를 통해 상세 답변과 연결하도록 설계했습니다.
핵심 전략은 다음과 같습니다.
검색 단계에서는 사용자 질문과 잘 매칭되는 표현을 사용하고, 응답 단계에서는 상세 답변를 조회한다.
| 구분 | 기존 방식 | 개선 방식 |
|---|---|---|
| 검색 대상 | 질문 + 상세 답변 | Query-Centric 검색용 텍스트 |
| 검색 인덱스의 역할 | 질문 탐색 및 답변 문맥 제공 | 적절한 Q&A 항목 식별 |
| 상세 답변 | 검색 문서에 포함 | 별도 답변 DB에서 보관 |
| 검색 결과 처리 | Top-K 문서를 응답에 활용 | Answer ID를 통해 상세 답변 조회 |
| BM25·KNN·RRF | 사용 | 변경 없이 유지 |
5.1. 단순 요약이 아닌 ‘질의 관점의 재표현’
기존 방식에서는 다음과 같은 텍스트가 검색 대상에 포함될 수 있었습니다.
‘비밀번호는 설정 메뉴에서 변경할 수 있습니다. 인증에 실패한 경우 재설정하거나 고객센터에 문의하십시오.‘
이를 단순히 짧게 줄이는 것이 아니라, 사용자가 실제로 질문하는 방식으로 재구성합니다.
계정 비밀번호 변경 방법 · 비번 바꾸기 · 패스워드 변경
여기서 보존할 정보는 대상(계정 비밀번호)과 행동(변경)이라는 질문의 핵심 의도입니다. 반면 인증 실패·고객센터 안내처럼 답변에는 필요하지만 검색 의도를 혼동시킬 수 있는 부가 문맥은 상세 답변에 남깁니다.
검색용 텍스트를 만들 때 고려할 기준은 다음과 같습니다.
- 대표 질의: 사용자가 가장 자연스럽게 입력할 질문 형태
- 표현 다양성: 동의어, 약어, 사용자가 자주 쓰는 용어
- 의도 보존: 서로 다른 작업을 하나로 합치지 않도록 구분 (예: 비밀번호 변경과 비밀번호 찾기)
- 잡음 최소화: 예외 처리, 후속 절차, 연관되지만 다른 업무의 단어는 검색용 표현에서 신중하게 제외
이것은 특정한 자동 생성 파이프라인을 구현했다는 의미가 아니라 검색용 텍스트를 설계할 때의 원칙입니다. 관련 표현을 무조건 많이 나열하는 것도 답이 아닙니다. 키워드의 양과 문장의 길이보다 질문의 의도를 얼마나 분명하게 표현하는지가 중요합니다.
대표 질의·유사 질의·다른 의도를 어떻게 구분할까?
Query-Centric 설계에서 중요한 것은 표현이 비슷한 질의를 모으되, 해결하려는 문제가 다르면 구분하는 것입니다. 다음은 설명을 위한 가상 예시로, 실제 데이터나 운영 중인 의도 분류 기능을 나타내지 않습니다.
| 구분 | 사용자 질의 예시 | 질문의 핵심 의도 | 검색용 데이터 설계 관점 |
|---|---|---|---|
| 대표 질의 | 비밀번호 변경 방법 | 알고 있는 비밀번호를 다른 비밀번호로 변경 | 비밀번호 변경 항목의 대표 표현 |
| 유사 질의 | 비번 바꾸려면 어디로 가나요? | 비밀번호 변경 | 같은 항목의 구어체·약어 표현 |
| 유사 질의 | 계정 패스워드를 수정하고 싶어요 | 비밀번호 변경 | 같은 항목의 동의어 표현 |
| 다른 의도 | 비밀번호를 잊어버렸어요 | 비밀번호 찾기 또는 재설정 | 별도의 Q&A 항목으로 구분할 대상 |
| 다른 의도 | 로그인하면 비밀번호 오류가 나요 | 로그인 오류 원인 확인 | 별도의 Q&A 항목으로 구분할 대상 |
예를 들어 비번 바꾸기와 패스워드 수정은 표현이 달라도 같은 변경 절차를 찾는 질문일 수 있습니다.
반면 비밀번호를 잊어버렸어요는 단어가 겹치더라도 기존 비밀번호를 알고 있는 사용자의 변경 절차와는 필요한 안내가 다를 수 있습니다. 이 둘을 하나의 검색용 텍스트에 무조건 합치면 처음에 해결하려던 의도가 다른 Q&A의 혼입 문제가 다시 생길 수 있습니다.
따라서 검색 표현을 추가할 때는 단어 유사성만 확인하지 않고, 동일한 상세 답변로 안내해도 되는 질문인지 함께 판단해야 합니다.
이 예시는 검색 데이터 작성 기준을 설명하는 것으로, 실제 프로젝트에서 위 표현을 모두 수집하거나 자동으로 분류했다고 의미하지 않습니다.
그림 3. 같은 답변으로 해결할 수 있는 표현은 묶고, 의도가 다르면 별도 항목으로 구분합니다(가상 예시).
5.2. Answer는 제거하지 않고 별도 저장소에서 관리
검색 결과를 상세 답변와 연결하기 위해 검색용 데이터에는 답변을 찾을 수 있는 식별자를 함께 둡니다.
다음 자바스크립트 객체 표기법(JSON, JavaScript Object Notation) 예시는 실제 테이블이나 응용 프로그래밍 인터페이스(API, Application Programming Interface) 명세가 아닌 개념적 예시입니다.
Search Index의 논리적 데이터
{
“answer_id”: “EX-001”,
“search_text”: “계정 비밀번호 변경 방법, 비번 바꾸기, 패스워드 변경”
}
Answer DB의 논리적 데이터
{
“answer_id”: “EX-001”,
“question”: “비밀번호는 어떻게 변경하나요?”,
“answer”: “로그인 후 설정 메뉴에서 비밀번호를 변경할 수 있습니다.”
}
중요한 것은 answer_id가 두 저장 영역을 연결한다는 점입니다. 개념적으로 search_text는 BM25 검색과 문서 임베딩에 사용하는 텍스트이고, answer_id는 검색된 항목을 Answer DB와 연결하기 위한 메타데이터입니다.
ID 문자열 자체를 질의와의 관련성 계산에 넣는 것이 목적은 아닙니다. 어떤 필드가 검색·임베딩 대상인지 지정하는 방법은 엔진마다 다릅니다. 따라서 검색 인덱스는 적절한 항목을 찾고, Answer DB는 그 항목의 상세 답변을 제공합니다.
실제 저장 엔진, 컬럼명, 인덱스 구성, 답변 조회 API 등은 이 개념적 설명에 포함하지 않았습니다.
6. 개선 아키텍처: 검색과 응답 데이터의 역할 분리
그림 4. 개선된 검색·응답 역할 분리 구조. 사용자 질의가 BM25와 KNN으로 분기된 뒤 RRF에서 결합되고, Answer ID를 통해 상세 답변를 조회합니다.
처리 흐름은 다음과 같습니다.
- 사용자 질의 입력: 질문을 받아 BM25와 KNN 검색 경로로 전달합니다.
- Query-Centric 인덱스 검색: 검색용 표현을 기반으로 두 경로가 후보를 찾습니다.
- RRF 순위 결합: 각 검색 경로의 순위를 결합해 Top-K 후보를 구성합니다.
- Answer ID 확보: 검색 결과에서 답변을 식별할 ID를 얻습니다.
- 상세 답변 조회: 해당 ID로 Answer DB의 상세 답변를 조회합니다.
- 최종 응답: 조회된 답변을 근거로 LLM이 사용자에게 응답합니다.
이 그림은 검색 후보의 ID 확보와 상세 답변 조회를 나타내는 논리적 처리 흐름입니다. 검색된 Top-K 가운데 몇 개의 ID를 조회하거나 LLM에 전달할지는 별도의 선택 정책에 해당하며, 여기서는 특정 개수나 선정 방식을 단정하지 않습니다.
이로써 검색 인덱스는 Search Index, 상세 답변 DB는 Answer Storage라는 별도의 목적을 갖습니다.
검색 문서에 상세 답변를 넣지 않았다고 해서 LLM이 참조할 정보까지 사라지는 것은 아닙니다. 필요한 시점에 Answer DB에서 가져오기 때문입니다.
7. 개선 효과: 정성적 관찰과 검증 방법을 구분하기
이번 사례에서 정리한 개선 효과는 검색 노이즈 감소, 검색 관련성 개선, 응답 안정성 향상입니다. 다음은 성능 수치가 아닌 적용 과정에서 확인한 정성적 변화입니다.
검색 노이즈 감소. 답변의 부가 설명과 예외 처리 문맥을 검색 대상에서 제외해, 질문 의도와 직접 관계없는 매칭 신호를 줄였습니다.
검색 관련성 개선. 사용자 질의 중심으로 재구성한 텍스트를 검색하면서, 다른 Q&A의 부가 설명 때문에 의도와 다른 문서가 상위에 노출되던 문제를 완화했습니다.
응답 안정성 측면의 효과. 검색 후보의 관련성이 개선되면서 LLM이 적절한 상세 답변을 참조하는 데 도움이 되었고, 부적절한 답변이 선택되는 문제를 줄이는 방향으로 작용했습니다.
이는 Retrieval 단계의 개선에 따른 정성적 관찰이며, 생성 모델 자체의 성능 개선을 의미하지는 않습니다.
여기서 주의할 점은 검색 품질과 최종 답변 품질이 같은 지표가 아니라는 것입니다. Retrieval의 오류가 줄어도 LLM의 생성 오류, 원본 답변의 부정확성 등은 별도로 관리해야 합니다.
앞서 설명한 개선은 정성적 관찰에 관한 것으로, 별도의 통제된 평가 없이 최종 응답 정확도나 Hallucination 감소율의 정량적 개선을 주장하지 않습니다.
7.1. 정량 검증이 필요할 때의 평가 지표
유사한 개선을 평가한다면 아래 지표들을 사용할 수 있습니다. 이 표는 본 사례의 측정 결과가 아니라 일반적인 평가 설계 예시입니다.
| 평가 지표 | 확인하려는 문제 | 평가 방식 |
|---|---|---|
| Top-1 Accuracy | 가장 높은 순위의 Q&A가 정답인가? | 정답 Answer ID가 1위인 질의의 비율 |
| Hit@K | 정답 Answer ID가 검색 Top-K에 포함되는가? | 정답 Answer ID가 상위 K개 검색 결과에 존재하는 비율 |
| Retrieval Failure Rate@K | 정답이 검색 후보에서 빠지는가? | 정답 Answer ID가 상위 K개에 없는 비율 |
| 표현 변형 강건성 | 같은 의도의 다른 표현을 처리하는가? | 대표 질의와 유사 질의 묶음의 검색 결과 비교 |
| 최종 응답 정합성 | 정답 후보가 있어도 응답 오류가 발생하는가? | 답변의 정확성·근거 적합성 별도 검토 |
정답 ID가 하나인 질의 집합에서는 Failure Rate@K = 1 − Hit@K로 표현할 수 있습니다. 정답이 여러 개인 경우에는 정답 집합 기준의 Recall@K와 구분해 정의해야 합니다.
데이터 구조 변경의 효과를 비교할 때는 동일한 평가 질의, 정답 레이블, 검색 설정, Top-K 조건을 사용하고 검색 대상 텍스트 변경의 영향을 따로 관찰하는 것이 유용합니다.
ID 조회 실패나 End-to-End 지연시간도 별도의 운영 지표로 확인할 수 있습니다.
8. 적용 범위와 운영 시 고려사항
이 장에서 다루는 내용은 유사한 구조를 설계하거나 확장할 때 검토할 과제입니다. 본 사례에서 모두 구현했다고 주장하는 항목은 아닙니다.
8.1. 어떤 RAG에 적합한가?
질문을 사전에 정의된 Q&A 항목에 연결하는 고객의 소리·자주 묻는 질문(FAQ, Frequently Asked Questions)·업무 안내 시스템에서는 질의 중심 설계가 유효한 선택지가 될 수 있습니다.
반면 긴 기술 문서, 논문, 약관 등의 근거 문단 자체를 찾는 RAG에서는 상세 문맥을 인덱싱하는 편이 더 적합할 수 있습니다.
따라서 ‘RAG는 언제나 검색용 요약만 저장해야 한다’는 결론으로 일반화해서는 안 됩니다. 먼저 검색 대상이 답변 항목인지, 원문 근거인지를 구분해야 합니다.
8.2. 검색 표현이 지나치게 좁거나 넓어지지 않도록 관리
검색용 텍스트가 짧다는 이유만으로 정확한 것은 아닙니다. 예를 들어 비밀번호 변경, 비밀번호 찾기, 로그인 오류는 관련 단어가 겹치더라도 서로 다른 의도입니다.
동의어를 추가할 때는 실제 사용자 표현을 포괄하면서도 다른 의도까지 섞지 않도록 검토해야 합니다.
특히 한국어 질의에서는 띄어쓰기, 복합어, 약어, 형태소 분석·토큰화 방식 등에 따라 BM25 매칭이 달라질 수 있습니다.
따라서 실제 검색 엔진의 분석 설정과 대표 질의의 검색 결과를 함께 점검하는 편이 좋습니다. 여기서 특정 분석기나 동의어 확장 기능을 사용했다고 가정하지는 않습니다.
여러 표현을 별도 레코드로 관리하는 구조라면 같은 Answer ID로 모이는 중복 결과의 처리도 확인할 필요가 있습니다.
8.3. 검색 ID와 답변의 정합성 보장
Search Index와 Answer DB를 분리하면 검색된 ID가 올바른 답변을 가리키는지 검증해야 합니다. 운영 설계 시에는 다음을 고려할 수 있습니다.
- 답변이 수정·삭제될 때 검색용 데이터와 매핑을 동기화하는 방법
- 검색 결과가 존재해도 답변 조회에 실패하는 경우의 처리
- 하나의 질문 의도를 여러 검색 표현으로 표현할 때의 중복 후보 처리
- 접근 권한이 있는 사용자에게만 해당 답변을 제공하도록 확인하는 절차
이들은 두 저장 영역을 분리했을 때 발생할 수 있는 일반적인 관리 과제입니다.
8.4. 검색 실패와 생성 실패를 분리해서 진단
최종 응답이 틀렸을 때는 다음 세 가지를 나누어 확인하는 것이 좋습니다.
- Retrieval: 정답 Answer ID가 검색 결과에 있었는가?
- 답변 조회: 검색된 ID로 올바른 상세 답변를 가져왔는가?
- Generation: 올바른 답변을 받았는데도 LLM이 잘못 응답했는가?
오류 지점을 구분하면 검색 인덱스를 고쳐야 할지, 데이터 정합성을 확인해야 할지, 응답 생성 방식을 개선해야 할지 판단하기 쉬워집니다.
그림 5. 검색·상세 답변 조회·최종 응답 생성 단계별 장애 원인 점검 관점.
9. 마치며: 잘 설명하는 데이터와 잘 검색되는 데이터는 다를 수 있다
이번 사례의 핵심은 새로운 임베딩 모델이나 검색 알고리즘을 도입하지 않았다는 점입니다. BM25·KNN·RRF는 유지하면서, 검색 대상 텍스트를 사용자 질의 중심으로 재설계하고 상세 답변를 별도 DB로 분리했습니다.
Question과 답변을 함께 인덱싱하는 방식이 항상 나쁜 것은 아닙니다.
다만 특정 Q&A를 정확히 찾아야 하는 서비스에서는 상세 답변의 부가 설명이 검색 신호를 흐릴 수 있습니다. 이때 검색용 데이터와 응답용 데이터의 역할을 나누는 접근을 검토할 수 있습니다.
RAG의 검색 품질은 모델뿐 아니라 검색할 데이터를 어떻게 표현하고 구성하는지에도 달려 있습니다. 검색해야 하는 것은 무엇이고, 답변할 때 필요한 정보는 무엇인지부터 분리해 보는 것이 개선의 출발점이 될 수 있습니다.
참고 자료
- Elastic — Similarity settings: BM25 (https://www.elastic.co/docs/reference/elasticsearch/index-settings/similarity): BM25의 단어 빈도·문서 길이 처리에 대한 일반 설명
- Elastic — Reciprocal rank fusion (https://www.elastic.co/docs/reference/elasticsearch/rest-apis/reciprocal-rank-fusion): RRF의 순위 기반 결합 방식에 대한 일반 설명
위 자료는 알고리즘의 일반 원리를 설명하기 위한 참고 링크이며, 특정 운영 환경의 검색 제품이나 설정을 의미하지 않습니다.