저는 일반적인 조언들을 단순히 반복하는 대신 직접 테스트해보고 싶어서 합성 클리닉 데이터베이스를 기반으로 작은 RAG 벤치마크를 구축했습니다.

벤치마크
데이터베이스에는 가상의 환자, 의사, 부서, 예약, 의료 기록, 처방전 및 청구 항목이 포함되어 있습니다. 평가 세트(eval set)는 규모가 작습니다: 직접적인 사실, 관계, 시간적 질문, 수치 질문, 범위 질문, 그리고 전체적인 집계 질문을 포함하여 쉬움/중간/어려움 단계로 나뉜 30개의 질문으로 구성됩니다.
저는 일반적인 벡터 검색 (vector-search) 베이스라인을 다음과 같은 방식들과 비교했습니다:

• 쿼리 재작성 (query rewriting)
• 원본 쿼리 + 재작성된 쿼리를 사용한 이중 검색 (dual retrieval)
• BGE 리랭킹 (BGE reranking)
• 생성된 문서 보강 (generated document enrichment)
• Small-to-Big 검색 (Small-to-Big retrieval)
• 집계 사실을 위한 롤업 문서 (rollup documents for aggregate facts)
• 최종 Jina 리랭커 절제 실험 (final Jina reranker ablation)

유용한 교훈은 전통적인 RAG 업그레이드 방식들도 도움이 되었지만, 가장 큰 성능 향상은 시스템이 검색할 수 있는 대상 자체를 변경했을 때 나타났다는 점입니다.

최적의 기본 실행 결과:

• 검색 MRR: 0.406
• 답변 종합 점수: 2.856 / 5

쿼리 재작성 + BGE 리랭킹:

• 검색 MRR: 0.425
• 답변 종합 점수: 3.056 / 5

이는 도움이 되었지만 핵심적인 문제를 해결하지는 못했습니다. 리랭킹 (Reranking)은 후보군을 재정렬할 수는 있지만, 누락된 증거를 나타나게 할 수는 없습니다.
첫 번째 실질적인 도약은 Small-to-Big 검색에서 나왔습니다. 저는 더 작은 방문 단위의 자식 청크 (child chunks)를 검색한 다음, 매칭된 자식 항목을 답변하기 전에 전체 환자 기록으로 확장했습니다. 이를 통해 답변에 문맥(context)이 부족해지는 현상 없이 정밀한 매칭을 구현할 수 있었습니다.

실행 6:

• 검색 MRR: 0.614
• 답변 종합 점수: 4.044 / 5

하지만 집계 질문은 여전히 실패했습니다. "어떤 의사가 가장 많은 예약 부하를 가지고 있는가?"와 같은 질문은 일반적인 조회 방식이 아닙니다. 만약 어떤 문서에도 해당 수치나 순위가 포함되어 있지 않다면, 벡터 검색은 검색할 적절한 대상을 찾을 수 없습니다.
따라서 저는 롤업 문서 (rollup documents)를 추가했습니다: 미리 계산된 수치, 순위, 합계 및 요약본입니다. 도시별 환자, 결제 상태별 청구서, 예약 부하별 의사, 총 청구 금액별 환자 등이 이에 해당합니다.

Run 7:

retrieval MRR: 0.779
context keyword coverage: 0.818
answer overall: 4.622 / 5
hard-question answer overall: 4.500 / 5

최종 Jina reranker 실행은 0.792라는 가장 높은 retrieval MRR을 기록했지만, 가장 우수한 answer overall 결과는 여전히 rollup 설정에서 나왔습니다.
저의 결론은 매우 간단합니다: RAG의 품질은 모델의 문제이기 이전에 데이터 표현 (data representation)의 문제인 경우가 많습니다.
만약 답변에 엔티티 수준 (entity-level)의 문맥이 필요하다면, 작게 검색하고 크게 확장(retrieve small and expand big)하십시오. 만약 답변에 집계 (aggregate) 정보가 필요하다면, 집계 내용을 문서로 작성하십시오. 만약 청크 (chunk)가 유용성을 만드는 정체성이나 관계를 잃어버렸다면, reranker가 이를 구원하지 못할 수도 있습니다.

주의사항: 합성 데이터 (synthetic data), 30개 질문 평가 세트, 각 설정당 1회 실행, 소규모 로컬 LLM 판정기 (judge), 방향성 결과만 제공. 이 수치들을 일반적인 벤치마크로 취급하지는 마십시오. 다만 실패 패턴은 유용하다고 생각합니다.

다른 분들은 이에 대해 어떻게 생각하시는지 궁금합니다:

RAG 결과에 무엇이 더 큰 영향을 미쳤습니까: 임베딩 (embeddings), 리랭킹 (reranking), 청킹 (chunking), 아니면 소스 문서 (source documents)의 변경입니까?
집계/rollup 문서를 생성하십니까, 아니면 모델이 원시 기록 (raw records)으로부터 추론하게 둡니까?
Small-to-Big 검색의 경우, 어떤 부모/자식 (parent/child) 분할 방식이 가장 효과적이었습니까?
검색 지표 (retrieval metrics) 외에 답변 품질을 어떻게 평가하고 계십니까?

Benchmark: https://ragnosis.samarthmn.com/
GitHub: https://github.com/samarthmn/RAGnosis
submitted by /u/KoalaOk1265
[link] [comments]