“질문은 한 줄인데, 왜 검색 결과는 수백 개일까?”
사내 지식베이스에 다음과 같은 질문을 던졌다고 가정해 보겠습니다.
“고객 A의 계약 해지 위약금 기준은 무엇인가요?”
일반적인 RAG 시스템은 이 질문을 임베딩으로 변환한 뒤, 전체 문서 저장소에서 의미가 비슷한 문서를 찾습니다. 문제는 여기서 시작됩니다. 계약서, 영업 제안서, 고객 상담 기록, 법무 가이드, 오래된 정책 문서까지 모두 비슷한 단어를 포함하고 있다면, 검색기는 관련 있어 보이는 문서를 대량으로 반환합니다.
하지만 많이 찾는 것과 제대로 찾는 것은 다릅니다.
평면 검색이 만드는 RAG의 잡음
기본적인 RAG는 수십만~수백만 개 문서를 하나의 넓은 벡터 공간에 넣고 검색하는 경우가 많습니다. 구현은 간단하지만, 조직의 데이터가 커지고 복잡해질수록 검색 범위도 함께 넓어집니다.
그 결과 다음과 같은 문제가 발생합니다.
- 인사 규정 질문에 법무 문서나 공지 문서가 함께 섞입니다.
- 오류 코드 검색에서 의미는 비슷하지만 제품 버전이 다른 매뉴얼이 상위에 노출됩니다.
- 최신 정책보다 과거 정책이 더 높은 순위에 오를 수 있습니다.
- 고객명, 계약 번호, 제품명처럼 정확한 문자열이 중요한 질문에서 의미 기반 검색만으로는 부족합니다.
- 검색 문서가 많아질수록 생성 모델의 입력 문맥이 불필요하게 길어집니다.
생성 모델은 전달받은 문서를 바탕으로 답변합니다. 따라서 검색 단계에서 잡음이 많이 섞이면, 아무리 성능이 뛰어난 LLM이라도 정확한 답을 만들기 어려워집니다. 엉뚱한 답변의 원인이 모델의 추론 능력이 아니라, 처음부터 잘못 들어간 근거 문서일 수 있는 이유입니다.
RAG의 진짜 병목은 “무엇을 찾을지”보다 “어디를 찾을지”
대규모 지식베이스에서는 질문의 의도를 먼저 파악하는 과정이 중요합니다. 예를 들어 “위약금 기준”이라는 질문은 단순히 계약이라는 단어와 가까운 문서를 찾는 일이 아닙니다.
먼저 다음을 판단해야 합니다.
- 이 질문은 법무·계약 영역에 속하는가?
- 특정 고객 또는 특정 상품의 계약 조건을 찾아야 하는가?
- 최신 표준 계약서가 필요한가, 예외 조항이 필요한가?
- 재무 수치나 고객 상담 이력도 함께 확인해야 하는가?
기존의 평면적인 검색 방식은 이 판단 없이 전체 코퍼스를 탐색합니다. 반면 계층형 접근은 질문의 의도를 기반으로 검색할 데이터 영역부터 좁힌 뒤, 그 안에서 세부 문서를 찾습니다.
이는 도서관에서 책 제목만 보고 모든 서가를 뒤지는 대신, 먼저 법률·기술·재무·인사 중 어느 서가로 갈지 결정하는 방식과 비슷합니다. 검색 대상이 줄어들면 속도는 빨라지고, 관련 없는 문서가 끼어들 가능성도 낮아집니다.
검색 결과가 많을수록 답변 품질이 떨어질 수 있는 이유
검색 결과를 많이 넣으면 생성 모델이 더 정확해질 것이라고 생각하기 쉽습니다. 그러나 실제 RAG 운영에서는 반대 상황도 자주 발생합니다.
관련 문서 3개와 애매한 문서 20개가 함께 제공되면 모델은 다음 문제를 겪을 수 있습니다.
핵심 근거가 묻힙니다.
정답이 담긴 문서가 있어도, 주변 문서가 많으면 모델이 중요한 문장을 놓칠 수 있습니다.서로 충돌하는 정보를 혼합합니다.
개정 전 정책과 최신 정책이 함께 들어오면, 모델이 두 내용을 섞어 존재하지 않는 답을 만들 가능성이 있습니다.문맥 비용이 늘어납니다.
불필요한 문서까지 모델에 전달하면 토큰 사용량과 응답 시간이 증가합니다.그럴듯한 오류가 발생합니다.
모델은 문서 속 일부 표현을 연결해 자연스러운 문장으로 답하지만, 실제 질문의 조건에는 맞지 않을 수 있습니다.
따라서 좋은 RAG는 단순히 문서를 많이 가져오는 시스템이 아닙니다. 질문과 무관한 후보를 초기에 줄이고, 남은 결과 중에서도 가장 신뢰할 수 있는 근거를 선별하는 시스템이어야 합니다.
RAG의 품질은 생성 모델의 크기만으로 결정되지 않습니다. 어떤 문서를 검색에서 제외했는가도 답변 품질을 좌우합니다.
이 지점에서 HiRAG처럼 검색 전에는 의도로 영역을 제한하고, 검색 후에는 결과를 다시 정제하는 계층형 접근이 주목받습니다. 다음 단계에서는 이 방식이 어떻게 전체 검색 공간을 줄이면서도 정답 근거를 더 잘 찾는지 살펴보겠습니다.
HiRAG RAG의 첫 번째 판단: 어디를 검색할 것인가
계약 조항을 묻는 질문을 기술지원 문서에서 찾지 않는다면 어떨까요?
기존의 단순한 RAG 시스템은 질문이 들어오면 방대한 문서 저장소 전체를 대상으로 유사한 내용을 검색합니다. 구현은 간단하지만, 계약서·장애 보고서·인사 규정·제품 매뉴얼이 한곳에 섞여 있다면 문제가 생깁니다. 질문과 무관한 문서까지 후보에 올라오고, 검색 시간과 생성 모델의 컨텍스트 비용도 함께 커집니다.
HiRAG는 문서를 검색하기 전에 먼저 한 가지를 판단합니다.
이 질문은 어느 지식 영역에서 답을 찾아야 하는가?
이 첫 판단을 담당하는 것이 경량 BERT 기반의 Intent Router입니다. 라우터는 사용자의 질의를 분석해 적절한 문서 영역으로 연결합니다.
| 사용자 질문 예시 | 우선 탐색 영역 |
|---|---|
| “계약 해지 시 위약금 조건은 무엇인가요?” | 법무·계약 문서 |
| “오류 코드 504가 발생하는 원인이 뭔가요?” | 기술지원·장애 대응 문서 |
| “올해 3분기 매출 목표는 얼마인가요?” | 재무·영업 데이터 |
| “재택근무 신청 기준을 알려주세요.” | 인사·내부 규정 |
이 방식은 단순히 문서에 라벨을 붙이는 기능이 아닙니다. 검색 대상 자체를 미리 줄이는 검색 공간 가지치기(pruning) 전략입니다. 예를 들어 수백만 건의 사내 문서가 있어도, 계약 관련 질문이라면 법무·계약으로 분류된 하위 코퍼스를 중심으로 검색할 수 있습니다.
그 결과 RAG 파이프라인은 전체 문서를 무작정 훑는 대신, 다음과 같이 더 효율적인 순서로 동작합니다.
사용자 질문
↓
의도 분류(Intent Routing)
↓
관련 문서 영역 선택
↓
선택된 영역에서 상세 검색
이 첫 단계가 중요한 이유는 이후의 검색 품질을 좌우하기 때문입니다. 아무리 좋은 임베딩 모델이나 reranker를 사용하더라도, 처음부터 잘못된 문서 영역만 검색한다면 정답 근거를 찾기 어렵습니다. 반대로 질문의 목적에 맞는 영역을 정확히 선택하면, 검색 후보의 잡음은 줄고 관련 문서가 상위 결과에 포함될 가능성은 높아집니다.
다만 라우팅에는 분명한 위험도 있습니다. “계약 조건과 시스템 장애 책임 범위를 함께 알려주세요”처럼 여러 영역에 걸친 질문은 단일 분류만으로 처리하기 어렵습니다. 따라서 실무에서는 라우터의 신뢰도가 낮을 때 상위 2~3개 영역을 함께 검색하거나, 전체 코퍼스 검색으로 전환하는 fallback 전략이 필요합니다.
HiRAG의 출발점은 결국 단순합니다. 모든 문서를 검색하는 대신, 질문이 향해야 할 곳부터 결정한다는 것입니다. 이 작은 순서 변화가 대규모 RAG 환경에서 검색 지연시간과 불필요한 결과를 줄이는 핵심이 됩니다.
RAG: 키워드와 의미를 함께 잡고, 작은 모델로 골라내다
오류 코드 E1042를 찾는 질문과 “로그인 오류가 반복돼요”라는 질문은 전혀 다른 검색 능력을 요구합니다. 전자는 문자열이 정확히 일치해야 하고, 후자는 문서에 “인증 실패”, “세션 만료”, “접속 불가”처럼 다른 표현으로 적혀 있어도 의미를 이해해 찾아야 합니다.
그렇다면 하나의 검색 방식만으로 두 요구를 모두 만족시킬 수 있을까요? HiRAG는 이 문제를 Hybrid Retrieval과 Small-LLM Reranking의 조합으로 해결합니다.
정확한 단어는 Sparse Retrieval로 찾는다
키워드 기반의 sparse retrieval은 BM25처럼 문서와 질의에 공통으로 등장하는 단어를 중심으로 점수를 계산합니다. 제품명, 계약 조항 번호, 사내 시스템명, 오류 코드처럼 특정 문자열 자체가 중요한 환경에서 특히 강력합니다.
예를 들어 사용자가 다음과 같이 질문한다고 가정해 보겠습니다.
오류 코드 E1042의 원인과 해결 방법은 무엇인가요?
이 경우 임베딩 기반 의미 검색만 사용하면 E1042라는 코드가 드물게 등장하거나 학습 데이터에 충분히 반영되지 않았을 때 정확한 문서를 놓칠 수 있습니다. 반면 BM25는 해당 코드가 포함된 기술 문서, 장애 이력, FAQ를 빠르게 상위 후보로 끌어올릴 수 있습니다.
다른 표현의 같은 뜻은 Dense Retrieval로 찾는다
반대로 사용자는 항상 문서에 쓰인 공식 용어로 질문하지 않습니다.
- 문서 표현: “인증 토큰 만료”
- 사용자 질문: “로그인이 자꾸 풀립니다”
- 문서 표현: “계약 해지 조항”
- 사용자 질문: “중도 해약하면 어떤 조건이 있나요?”
이런 경우 dense retrieval, 즉 임베딩 기반 의미 검색이 효과적입니다. 질의와 문서의 단어가 완전히 같지 않아도 문맥상 의미가 유사하다면 가까운 벡터로 판단해 관련 문서를 찾습니다.
HiRAG의 RAG 파이프라인은 sparse retrieval과 dense retrieval을 함께 사용합니다. 따라서 고유명사·숫자·코드가 많은 기업 문서에서는 정확한 키워드를 놓치지 않고, 표현이 다양한 자연어 질문에서는 의미적으로 연결된 문서를 확보할 수 있습니다.
| 검색 방식 | 강한 상황 | 예시 |
|---|---|---|
| Sparse Retrieval | 정확한 문자열, 코드, 조항 번호 | E1042, 제품 모델명, 계약 제12조 |
| Dense Retrieval | 유사 표현, 자연어 질문, 문맥 이해 | “로그인이 풀려요”, “해약 조건이 궁금해요” |
| Hybrid Retrieval | 두 조건이 섞인 실무 질의 | “E1042가 뜨면서 로그인이 안 됩니다” |
후보를 많이 찾는 것과, 좋은 근거를 남기는 것은 다르다
Hybrid Retrieval은 후보 문서를 넓고 안정적으로 모으는 단계입니다. 하지만 후보가 확보됐다고 해서 모두 생성 모델에 넣어서는 안 됩니다. 비슷해 보이지만 실제 질문에는 맞지 않는 문서가 섞일 수 있기 때문입니다.
예를 들어 “계약 갱신 조건”을 묻는 질문에 아래 문서들이 함께 검색될 수 있습니다.
- 고객 계약의 자동 갱신 조항
- 소프트웨어 라이선스 갱신 정책
- 직원 계약직 전환 규정
- 과거 계약 변경 이력
모두 ‘갱신’이라는 단어와 관련은 있지만, 사용자의 질문에 직접 답하는 근거는 아닐 수 있습니다. 여기서 HiRAG는 Small-LLM Reranking을 사용해 후보 문서를 다시 평가합니다.
소형 언어모델은 질의와 문서의 관계를 더 세밀하게 읽고, “이 문서가 실제 질문에 답하는가?”를 기준으로 순위를 조정합니다. 단순한 키워드 일치나 벡터 유사도만으로는 구분하기 어려운 관련성 차이를 보완하는 역할입니다.
질문 입력
↓
Sparse Retrieval: 정확한 키워드·코드 후보 확보
+
Dense Retrieval: 의미가 가까운 후보 확보
↓
후보 문서 통합
↓
Small-LLM Reranking: 질문에 직접 답하는 문서 우선 배치
↓
정제된 근거 문서만 생성 모델에 전달
왜 대형 모델이 아니라 작은 모델인가
모든 후보를 대형 LLM으로 재정렬하면 품질은 높일 수 있지만, 비용과 응답 시간이 빠르게 증가합니다. 특히 수많은 사내 문서와 동시 사용자 요청을 처리해야 하는 환경에서는 이 방식이 병목이 될 수 있습니다.
HiRAG는 재정렬 역할을 소형 모델에 맡깁니다. 이는 다음과 같은 실무적 이점을 만듭니다.
- 낮은 추론 비용: 대형 모델 호출 수와 토큰 사용량을 줄입니다.
- 짧은 응답 시간: 검색 결과를 빠르게 정제해 최종 답변 생성 단계로 넘깁니다.
- Context 낭비 감소: 관련성이 낮은 문서를 제거해 대형 LLM의 입력 공간을 아낍니다.
- 답변 품질 안정화: 생성 모델이 불필요한 근거에 흔들릴 가능성을 낮춥니다.
결국 HiRAG의 핵심은 검색 결과를 많이 모으는 데서 끝나지 않습니다. 키워드의 정확성과 의미의 유연성을 함께 확보한 뒤, 작은 모델로 정말 필요한 근거만 남기는 것입니다. 이는 RAG가 대규모 기업 지식베이스에서 더 빠르고 신뢰도 높게 작동하기 위한 현실적인 설계입니다.
RAG 성능 지표: Recall@5 14.5%p 상승과 지연시간 28% 감소의 의미
RAG 시스템에서 중요한 질문은 단순합니다. 생성 모델이 답하기 전에, 정말 필요한 근거 문서를 찾았는가?
HiRAG는 MDE-KB 평가에서 Naive RAG 대비 Recall@5를 14.5%p 높이고, 평균 질의 지연시간을 28% 줄였다고 보고했습니다. 하나는 답변 품질과 직결되고, 다른 하나는 사용자 경험과 운영 비용에 직접 영향을 주는 수치입니다.
Recall@5 14.5%p 상승: “상위 5개 안에 정답이 있을 확률”이 높아졌다
Recall@5는 검색 결과 상위 5개 문서 안에 정답의 근거가 포함되어 있는지를 측정하는 지표입니다. RAG에서는 생성 모델이 아무리 뛰어나도, 필요한 근거가 검색되지 않으면 정확한 답변을 만들기 어렵습니다.
예를 들어 사용자가 다음과 같이 질문한다고 가정해 보겠습니다.
“특정 오류 코드가 발생했을 때 적용해야 하는 장애 대응 절차는 무엇인가요?”
검색 상위 5개에 실제 기술 매뉴얼이나 장애 대응 정책이 포함되어 있다면, 생성 모델은 이를 바탕으로 구체적이고 검증 가능한 답변을 만들 수 있습니다. 반대로 관련 없는 문서만 검색되면, 모델은 일반론을 말하거나 근거 없는 내용을 생성할 위험이 커집니다.
따라서 Recall@5가 14.5%p 향상됐다는 것은 필요한 문서를 초기 검색 단계에서 놓칠 가능성이 크게 줄었다는 뜻입니다. 특히 수많은 부서 문서, 기술 문서, 계약서, 정책 자료가 섞인 기업 지식베이스에서는 이 차이가 더 크게 체감될 수 있습니다.
검색 품질은 단순히 “비슷한 문서를 찾는 능력”이 아니라, 생성에 필요한 정답 근거를 제한된 상위 결과 안에 넣는 능력입니다.
평균 지연시간 28% 감소: 더 빠른 답변이 아니라, 더 현실적인 서비스 운영
평균 질의 지연시간이 28% 줄었다는 결과도 중요합니다. RAG 서비스에서 응답시간은 검색, 재정렬, 프롬프트 구성, LLM 생성 과정이 모두 합쳐져 결정됩니다. 문서가 많아질수록 전체 벡터 저장소를 검색하고 많은 후보를 재정렬하는 비용은 빠르게 커집니다.
HiRAG는 질문의 의도를 먼저 분류한 뒤, 관련 가능성이 높은 영역만 대상으로 검색합니다. 이후 sparse·dense 검색을 결합하고, 소형 언어모델로 후보 문서를 재정렬합니다. 즉, 대형 모델이 처리해야 할 문서 수와 불필요한 컨텍스트를 줄이는 방식입니다.
이 구조는 실서비스에서 다음과 같은 효과로 이어질 수 있습니다.
- 사용자가 답변을 기다리는 시간이 짧아짐
- 동시 요청이 많아도 검색 인프라 부담이 감소함
- 대형 LLM에 전달하는 토큰 수가 줄어 비용을 절감할 수 있음
- 관련 없는 문서가 컨텍스트를 차지하는 문제를 완화함
- 고객지원, 사내 검색, 기술 운영처럼 즉시성이 중요한 업무에 적용하기 쉬움
다만 평균 지연시간만으로 운영 품질을 판단해서는 안 됩니다. 실제 서비스에서는 느린 요청이 사용자 불만을 만드는 경우가 많으므로, p95·p99 지연시간도 함께 확인해야 합니다. 평균은 빨라졌더라도 일부 복잡한 질문에서 라우팅 실패나 검색 범위 확장으로 응답이 크게 늦어질 수 있기 때문입니다.
두 숫자를 함께 봐야 하는 이유
검색 정확도만 높이고 속도가 지나치게 느리면 현업에서 사용하기 어렵습니다. 반대로 속도만 빠르고 필요한 근거를 자주 놓치면 RAG의 신뢰성이 떨어집니다.
HiRAG의 성과가 주목할 만한 이유는 두 목표를 동시에 겨냥했다는 데 있습니다.
| 지표 | 실제 서비스에서의 의미 |
|---|---|
| Recall@5 +14.5%p | 답변에 필요한 근거 문서가 상위 검색 결과에 포함될 가능성 증가 |
| 평균 지연시간 -28% | 사용자의 대기시간, 검색 인프라 부하, 추론 비용 감소 가능성 |
| Answer Relevance 0.92 | 생성된 답변이 질문과 높은 관련성을 보였다는 신호 |
다만 이 수치가 모든 기업 데이터에서 동일하게 재현된다는 의미는 아닙니다. 문서 구조, 분류 체계, 질의 유형, 라우터 정확도, 임베딩 모델, 하드웨어 환경에 따라 결과는 달라질 수 있습니다. 특히 HiRAG는 초기에 질문을 잘못된 영역으로 라우팅하면, 정답 문서가 검색 대상에서 제외될 수 있다는 위험도 있습니다.
그래서 실제 도입 시에는 Recall@5와 지연시간뿐 아니라 routing miss rate, nDCG 또는 MRR, faithfulness, 인용 정확도를 함께 측정해야 합니다. 핵심은 하나의 인상적인 수치가 아니라, 빠른 검색과 신뢰할 수 있는 근거 제공이 함께 유지되는지 확인하는 것입니다.
RAG의 성패는 더 큰 모델이 아니라, 더 똑똑한 검색 경로
HiRAG의 성능 수치만 보면 자연스럽게 Recall@5 14.5%p 향상, 평균 지연시간 28% 감소에 시선이 갑니다. 하지만 실제 도입에서 더 중요한 질문은 따로 있습니다.
라우터가 첫 단계에서 잘못된 길을 선택했을 때, 시스템은 정답을 다시 찾을 수 있는가?
HiRAG는 질의 의도를 먼저 판별하고, 해당 도메인으로 검색 범위를 좁힙니다. 예를 들어 계약 조건에 관한 질문은 법무 문서로, 오류 코드가 포함된 문의는 기술지원 문서로 보냅니다. 이 과정은 전체 코퍼스를 매번 탐색하는 기존 RAG보다 훨씬 효율적입니다.
문제는 이 효율이 동시에 초기 분류의 정확성에 크게 의존한다는 점입니다. 라우터가 “계약 해지 시 위약금과 시스템 접근 권한은 어떻게 되나요?”라는 질문을 법무 영역에만 보냈다고 가정해 보겠습니다. 실제 답변에 필요한 정보가 계약서뿐 아니라 보안 정책, 계정 관리 매뉴얼에도 있다면, 처음부터 다른 영역의 근거 문서는 검색 후보에서 빠질 수 있습니다.
이후의 hybrid retrieval과 small-LLM reranking은 선택된 영역 안에서는 매우 정교하게 작동할 수 있습니다. 그러나 처음 검색 공간에서 제외된 문서는 재정렬할 수 없습니다. 검색 경로가 틀리면, 그 뒤의 모델 성능만으로는 한계를 완전히 극복하기 어렵습니다.
성능 지표와 함께 봐야 할 운영 지표
따라서 HiRAG 같은 계층형 RAG를 평가할 때는 답변 관련성이나 평균 지연시간만 보아서는 부족합니다. 다음 지표를 함께 관리해야 합니다.
- Routing miss rate: 실제 정답 문서가 있는 영역을 라우터가 놓친 비율
- Top-k route recall: 상위 2~3개 라우팅 후보 안에 정답 영역이 포함되는 비율
- Fallback rate: 낮은 신뢰도에서 전체 검색 또는 확장 검색으로 전환되는 비율
- Cross-domain query rate: 여러 부서·도메인의 정보를 동시에 요구하는 질문의 비율
- p95 latency: 평균이 아닌, 느린 사용자 요청에서의 실제 응답시간
- Groundedness: 생성 답변이 검색된 근거 문서에 충실한지 여부
특히 기업 환경에서는 단일 의도로 깔끔하게 분류되는 질문보다, 여러 업무가 얽힌 질문이 더 자주 등장합니다. “이번 분기 매출 하락의 원인과 관련 제품 장애 이력을 정리해 주세요” 같은 질의는 재무와 기술지원 데이터를 함께 탐색해야 합니다. 이런 질문을 하나의 라우팅 카테고리에 고정하면, 검색 속도는 빨라져도 답변의 완전성은 떨어질 수 있습니다.
안전한 HiRAG 도입을 위한 설계 원칙
HiRAG를 실무 RAG 아키텍처에 적용한다면, 라우터를 단순한 전처리 단계가 아니라 오류 가능성을 가진 의사결정 모델로 다뤄야 합니다.
가장 현실적인 방법은 다음과 같습니다.
상위 복수 경로를 병렬 검색합니다.
라우터가 가장 가능성 높은 영역 하나만 선택하는 대신, 상위 2~3개 영역을 함께 검색합니다. 약간의 비용은 증가하지만, 초기 오분류로 인한 치명적인 누락을 크게 줄일 수 있습니다.신뢰도가 낮으면 전체 검색으로 우회합니다.
라우터의 confidence가 기준 이하라면 계층 구조를 고집하지 말고 전체 코퍼스 또는 넓은 범위의 검색으로 fallback해야 합니다.복합 질의를 분해합니다.
정책, 수치, 기술 원인이 한 질문에 섞여 있다면 질의를 여러 하위 질문으로 나누고 각각 다른 검색 경로를 적용하는 방식이 효과적입니다.라우팅 로그를 지속적으로 분석합니다.
사용자의 질의, 선택된 영역, 검색된 문서, 최종 인용 문서, 사용자 피드백을 함께 저장해야 합니다. 이 데이터가 쌓여야 어떤 도메인 경계에서 라우팅 오류가 반복되는지 확인할 수 있습니다.분류·요약 계층을 문서 변화에 맞춰 갱신합니다.
조직 개편, 신규 제품 출시, 정책 변경이 일어나면 기존 분류 체계는 빠르게 낡습니다. 인덱스와 요약 정보, 라우터의 학습 데이터도 함께 업데이트되어야 합니다.
HiRAG의 핵심 가치는 단순히 “작은 모델을 써서 비용을 낮춘다”는 데 있지 않습니다. 더 본질적으로는 모든 문서를 같은 방식으로 검색하지 않고, 질문에 맞는 탐색 경로를 설계한다는 데 있습니다.
다만 똑똑한 검색 경로는 정확한 길 안내가 전제될 때만 힘을 발휘합니다. HiRAG를 도입할 때 가장 먼저 검증해야 할 것은 화려한 평균 성능 수치가 아니라, 라우터가 틀렸을 때도 정답 근거를 놓치지 않는 회복력입니다.
