에이전트의 검색 결과가 맞은 것처럼 보이면서도 틀린 이유: 인덱스 분포 문제 (The Index Distribution Problem)

당신은 에이전트(Agent)를 구축했습니다. 에이전트에게는 검색 도구가 있습니다. 당신은 사실 관계 질문, 비교, 기술적 조회와 같이 합리적인 질문으로 에이전트에게 쿼리(Query)를 던지고, 에이전트는 결과를 반환합니다. 결과는 맞은 것처럼 보입니다. 출처는 실제 존재하며, 스니펫(Snippet)은 그럴듯합니다. 에이전트는 이를 종합하여 자신감 있는 답변을 만들어냅니다.

하지만 그 답변은 틀렸습니다. 명백하게 틀린 것도 아니고, 환각(Hallucination) 증상처럼 이상하게 틀린 것도 아닙니다. 구조적으로 틀렸습니다. 모델이 컨텍스트(Context)를 확인하기도 전에 오류가 검색(Retrieval) 계층에 이미 내재되어 있기 때문에, 모든 표면적인 검사를 통과할 정도로 교묘하게 틀린 것입니다.

이것은 프롬프트 엔지니어링 (Prompt Engineering) 문제가 아닙니다. 컨텍스트 윈도우 (Context Window) 문제도 아닙니다. 이것은 **분포 문제 (Distribution Problem)**이며, 아무리 프롬프트를 잘 작성하더라도 해결할 수 없는 구조적 한계를 가지고 있습니다.

인덱스는 고정된 결정이다

대부분의 에이전트 빌더들이 내면화하지 못하는 사실이 있습니다. 검색 인덱스 (Search Index)는 지식에 대한 중립적인 표현이 아니라는 점입니다. 인덱스는 무엇이 중요하고 무엇이 중요하지 않은지에 대해 내려진 고정된 결정의 집합입니다.

BM25 역색인 (Inverted Index), 밀집 벡터 저장소 (Dense Vector Store), 또는 상용 웹 검색 API 등 모든 인덱스는 과거의 관련성 판단 (Relevance Judgments)에 의해 형성된 분포를 인코딩(Encoding)합니다. 누군가는 어느 시점에 어떤 문서가 특정 쿼리에 "관련이 있는지"를 결정했습니다. 이는 명시적일 수도 있고 (검색 결과에 라벨을 붙이는 인간 평가자), 암시적일 수도 있습니다 (클릭 로그, 체류 시간, 링크 그래프). 어떤 방식이든, 인덱스는 이제 시스템이 주어진 쿼리에 대한 좋은 답변이라고 간주하는 것에 대한 확률 분포 (Probability Distribution)를 인코딩합니다.

그 분포는 의미론적 진실 (Semantic Truth)이 아닙니다. 그것은 **과거의 관련성 합의 (Past Relevance Consensus)**입니다.

코퍼스 (Corpus)를 임베딩 (Embedding)하고 벡터 인덱스 (Vector Index)를 구축할 때 어떤 일이 발생하는지 생각해 보십시오. 당신의 임베딩 모델 (Embedding Model)은 어떤 개념들이 서로 가까운지에 대한 특정 가정들을 반영하는 데이터로 학습되었습니다. 당신의 청킹 전략 (Chunking Strategy)은 어떤 정보의 입도 (Granularity)가 유용한지에 대한 가정들을 인코딩합니다. 크로스 인코더 리랭킹 (Cross-encoder Reranking)이든 학습된 관련성 모델 (Learned Relevance Model)이든, 당신의 랭킹 모델 (Ranking Model)은 무엇이 "관련 있는지"에 대한 누군가의 판단을 반영하는 레이블링된 데이터 (Labeled Data)로 학습되었습니다.

이러한 선택 하나하나가 결정을 고착화합니다. 인덱스는 "무엇이 진실인가?"라고 묻지 않습니다. 대신 "사람들이 이와 같은 질문을 했을 때 무엇을 클릭했는가?"라고 묻습니다.

벤치마크의 함정: "어디를 찾아봐야 하는지 아는 것"에 보상하기

이 지점이 바로 벤치마크가 상황을 개선하는 것이 아니라 악화시키는 부분입니다.

표준 검색 벤치마크 — BEIR, MTEB, MS MARCO — 는 시스템이 사전에 레이블링된 관련성 판단과 일치하는 문서를 검색할 수 있는지를 측정합니다. 지표는 nDCG, MRR, Recall@K입니다. 정답 (Ground Truth)은 고정된 쿼리 세트에 대해 인간이 레이블링한 관련 문서 세트입니다.

여기에 문제가 있습니다. 이러한 벤치마크는 문서 안에 무엇이 들어있는지 이해하는 것이 아니라, 올바른 문서를 검색하는 것에 보상을 줍니다. 정확한 상위 5개 구절 (Passages)을 가져온 뒤 이를 잘못 해석하는 에이전트는 완벽한 검색 점수를 받으면서도 틀린 답을 내놓게 됩니다. 벤치마크는 검색 단계에서 멈추기 때문에, 검색 (Retrieval)과 추론 (Reasoning) 사이의 간극을 결코 측정하지 못합니다.

에이전트의 검색 성능을 평가할 때, 당신은 아마도 다음과 유사한 것을 측정하고 있을 것입니다: "시스템이 인간 평가자가 이전에 관련 있다고 레이블링한 것과 동일한 문서를 제시했는가?" 이것은 정확성에 대한 대리 지표 (Proxy)이며, 인간이 관련성 판단을 내린 적이 없는 새로운 쿼리(Novel Queries)가 등장하여 정작 지표가 가장 필요할 때 바로 무너져 버리는 대리 지표입니다.

이것이 바로 당신의 에이전트가 벤치마크에서는 훌륭해 보이지만 실제 운영 환경 (Production)에서는 실패하는 이유입니다. 벤치마크는 과거의 결정을 재현하는 인덱스의 능력을 측정합니다. 반면 운영 환경은 인덱스에게 과거의 어떤 결정과도 닮지 않은 쿼리들을 처리하도록 요구합니다.

새로운 쿼리: 분포가 무너지는 지점 (Novel Queries: Where the Distribution Cracks)

실제 운영 환경에서의 대부분의 에이전트 워크로드(workload)는 "프랑스의 수도는 어디인가요?"와 같은 형태가 아닙니다. 그것들은 조합적(combinatorial)이고, 멀티홉(multi-hop) 방식이며, 새로운(novel) 형태를 띱니다. 다음과 같은 예시가 있습니다:

• "라이브러리 X 버전 3.2의 에러 처리(error handling) 전략을 라이브러리 Y 버전 2.1의 재시도 로직(retry logic) 접근 방식과 비교해 주세요."
• "프로토콜 Z를 사용하는 미국 외 거주자의 스테이킹 보상(staking rewards)에 따른 세금 영향은 무엇인가요?"
• "논문 A에 기술된 마이그레이션 패턴이 데이터셋 B의 데이터와 일치한다는 증거를 찾아주세요."

이러한 쿼리들은 특정한, 그리고 위험한 방식으로 새로운(novel) 것입니다. 즉, 인덱스가 관련성 판단(relevance judgment)을 한 적이 없는 패턴으로 개념들을 결합합니다. 인덱스에는 "라이브러리 X 3.2 에러 처리 vs 라이브러리 Y 2.1 재시도 로직"에 대한 잠재적인 관련성 결정(latent relevance decision)이 존재하지 않습니다. 인덱스가 가진 것은 라이브러리 X에 관한 쿼리, 라이브러리 Y에 관한 쿼리, 에러 처리에 관한 쿼리, 그리고 재시도 로직에 관한 쿼리들로 형성된 분포입니다. 그리고 이 각각의 쿼리들은 서로 다른 시기에, 서로 다른 가정하에, 서로 다른 사람들에 의해 독립적으로 판단되었습니다.

검색 시스템(retrieval system)은 이러한 분포들 사이를 보간(interpolate)합니다. 이 보간은 합리적으로 보입니다. 라이브러리 X의 에러 처리에 관한 문서와 라이브러리 Y의 재시도 로직에 관한 문서를 반환하기 때문입니다. 하지만 이 보간은 추측이며, 쿼리가 실제로 요구하는 비교에 대한 의미론적 이해(semantic understanding)가 아니라 인덱스의 사전 확률(prior)에 의해 형성된 추측입니다.

당신의 에이전트는 이러한 결과들을 전달받고, 그것들이 맞다고 느낍니다. 올바른 라이브러리에서 가져온 것이며, 올바른 개념들을 언급하고 있기 때문입니다. 하지만 그것들은 잘못된 버전(version), 잘못된 문맥(context), 또는 잘못된 _프레이밍(framing)_일 수 있습니다. 그리고 검색 계층(retrieval layer)이 모든 것을 순위가 매겨진 관련성(ranked relevance)으로 제시하기 때문에, 에이전트는 이를 감지할 수 있는 신호(signal)가 없습니다.

구조적 한계 (The Structural Ceiling)

여기 불편한 사실이 있습니다. 이것은 더 나은 검색(retrieval)만으로는 해결할 수 없습니다. 이 한계는 구조적인 것입니다.

인덱스 분포 (index distribution)는 과거 인간의 관련성 판단 (relevance judgments)을 손실 압축 (lossy compression)한 결과물입니다. 여러분의 임베딩 모델 (embedding model), 리랭커 (reranker), 또는 하이브리드 검색 (hybrid search) 파이프라인이 아무리 훌륭하더라도, 결국 여러분은 과거의 손실 압축된 정보를 쿼리하고 있는 것입니다. 만약 여러분의 쿼리가 과거의 판단에 의해 충분히 커버된 분포 영역 내에 있다면 좋은 결과를 얻을 수 있습니다. 하지만 쿼리가 공백 영역(gap)에 위치한다면 — 그리고 새로운 쿼리는 거의 항상 여기에 해당합니다 — 그 결과는 그럴싸해 보이지만 근거가 없는 보간 (interpolation) 결과가 됩니다.

문서(documents)를 더 추가하는 것도 도움이 되지 않습니다. 데이터가 많아진다는 것은 과거의 결정이 많아진다는 것을 의미하지만, 그것이 가능한 새로운 쿼리 공간을 더 잘 커버한다는 것을 의미하지는 않습니다. 가능한 쿼리의 공간은 조합론적으로 무한하지만, 과거 관련성 판단의 공간은 유한하며 흔한 패턴에 편향되어 있습니다.

더 나은 임베딩 모델도 도움이 되지 않습니다. 임베딩 모델은 보간의 매끄러움 (smoothness)을 개선하여 결과가 더 그럴싸해 보이게 만들 수는 있지만, 공백 영역에 실제 정답 (ground truth)을 추가해주지는 않습니다. 잘못된 사전 확률 (prior)을 더 매끄럽게 보간한다고 해서 결과가 맞게 되는 것은 아닙니다.

더 강력한 LLM도 도움이 되지 않습니다. LLM은 검색 계층 (retrieval layer)이 제공하는 정보를 바탕으로 작동합니다. 만약 검색 계층이 그럴싸해 보이지만 문맥적으로는 틀린 문서 세트를 반환한다면, LLM은 그 문서들을 바탕으로 올바르게 추론하여 자신감 있고 구조적으로 잘 짜인 '틀린 답변'을 내놓을 것입니다. LLM의 추론 능력은 검색 병목 현상 (retrieval bottleneck)의 하류 (downstream)에 위치합니다.

실질적인 완화 방법 (Practical Mitigations)

구조적인 한계(structural ceiling)를 완전히 제거할 수는 없지만, 한계에 도달하고 있음을 감지하고 이를 보완할 가드레일 (guardrails)을 구축할 수는 있습니다. 다음은 효과적인 네 가지 접근 방식과 그 한계에 대한 솔직한 평가입니다.

1. 쿼리 재구성 일관성 검사 (Query Reformulation Consistency Checks)

동일한 쿼리를 여러 가지 방식 — 다른 표현, 다른 분해, 다른 추상화 수준 —으로 재구성하고, 각각에 대해 독립적으로 검색을 수행합니다. 그런 다음 결과 세트를 비교합니다.

def consistency_check(query, retriever, n_variants=5):
    """여러 가지 재구성을 통해 검색을 수행하고 중첩도를 측정합니다."""
    variants = generate_query_variants(query, n=n_variants)
...

동일한 의도(intent)를 가진 질의를 재구성(reformulation)했을 때 top-k 결과가 크게 달라진다면, 당신은 검색(retrieval)이 불안정한 인덱스 분포(index distribution) 영역에 있는 것입니다. 이는 질의가 공백(gap) 근처에 있다는 신호이며, 에이전트는 검색된 컨텍스트(context)에 대해 낮은 신뢰도를 적용하거나 추가적인 검증 단계를 실행해야 합니다.

한계: 일관성(consistency)이 정확성(correctness)을 보장하지는 않습니다. 모든 재구성된 질의가 구조적 편향(structural bias)을 공유한다면, 모두 동일한 방식으로 틀릴 수도 있습니다. 하지만 불일치(inconsistency)는 강력한 부정적 신호입니다. 재구성된 질의들이 서로 일치하지 않는다면, 적어도 한 세트는 틀린 것입니다.

2. 소스 다양성 조사 (Source Diversity Probing)

단일 소스에서 top-k를 검색하는 것에 그치지 마세요. 여러 독립적인 인덱스 — 서로 다른 검색 백엔드(search backends), 서로 다른 코퍼스(corpora), 서로 다른 검색 방법(BM25 vs. 밀집 검색(dense) vs. 하이브리드(hybrid)) — 를 조사하고 일치 여부를 측정하세요.

핵심 아이디어: 만약 인덱스 분포가 문제라면, 서로 다른 분포를 가진 인덱스들은 새로운 질의에 대해 서로 일치하지 않을 것입니다. 독립적인 인덱스들 간의 일치 여부는 단일 인덱스의 top-k 내에서의 일치 여부보다 더 강력한 신호입니다.

def diversity_probe(query, retrievers, k=5):
    """여러 독립적인 소스에서 검색하고, 소스 간 일치 여부를 측정합니다."""
    source_results = {}
...

이는 단일 검색 도구를 사용하는 에이전트에게 특히 중요합니다. 만약 에이전트가 항상 동일한 API에 질의한다면, 항상 동일한 분포 편향(distributional bias)을 얻게 됩니다. 교차 확인(cross-check)을 위해 단 하나의 독립적인 소스라도 추가한다면, 기본 소스의 인덱스가 당신을 공백(gap)으로 유도하는 경우를 포착할 수 있습니다.

한계: 독립적인 인덱스들이 완전히 독립적인 것은 아닙니다. 이들은 종종 중첩된 데이터로 학습되거나, 유사한 랭킹 신호(ranking signals)를 사용하거나, 동일한 기반 웹 크롤(web crawl)을 공유합니다. 하지만 이들은 서로 다른 관련성 판단(relevance judgments)과 서로 다른 랭킹 사전 확률(ranking priors)을 가지고 있으므로, 일치 여부가 완전히 결정적이지 않더라도 불일치 여부는 유익한 정보를 제공합니다.

3. 검색과 독립적인 신뢰도 교정 (Confidence Calibration Independent of Retrieval)

가장 중요한 완화 방법은 에이전트가 답변에 대해 갖는 신뢰도(confidence)가 단순히 검색(retrieval)의 성공 여부에만 의존해서는 안 된다는 것입니다. 검색 결과가 확신을 준다고 해서, 그 답변이 반드시 확신할 수 있는 정답임을 의미하지는 않습니다.

RAG 설정에서의 신뢰도 교정(confidence calibration)에 관한 최근 연구(NAACL Rules, CalibRAG)에 따르면, LLM은 검색된 컨텍스트(context)가 노이즈가 많거나 무관할 때조차도 검색된 컨텍스트가 주어지면 체계적으로 과잉 확신(overconfident)하는 경향을 보입니다. 검색 계층은 "관련 있어 보이는 문서를 찾았다"라는 유창성 신호(fluency signal)를 제공하는데, 모델은 이를 정답 신호(correctness signal)와 혼동합니다.

이를 해결하기 위해 검색 파이프라인(retrieval pipeline)과 독립적으로 작동하는 신뢰도 계층을 구현하십시오:

• 자기 일관성 샘플링 (Self-consistency sampling): 검색된 컨텍스트로부터 여러 개의 답변을 생성하고(서로 다른 온도(temperature) 설정, 서로 다른 프레이밍 사용), 답변 간의 일치도를 측정합니다. 일치도가 낮으면 → 신뢰도를 낮게 설정합니다.
• 역사실적 탐사 (Counterfactual probing): 검색된 컨텍스트 없이 에이전트에게 동일한 질문을 던집니다. 만약 답변이 크게 달라진다면, 검색이 과도한 역할을 수행하고 있다는 뜻입니다. 이는 검색 품질이 더 중요하다는 것을 의미하며, 일관성 검사(완화 방법 #1)에서 불안정성이 감지되었다면 신뢰도를 더 낮게 가져가야 합니다.
• 명시적 불확실성 프롬프팅 (Explicit uncertainty prompting): 에이전트가 검색된 컨텍스트에서 자신이 모르는 것이 무엇인지 나열하도록 강제합니다. 만약 에이전트가 그 공백(gap)을 명확히 설명하지 못한다면, 자신이 찾은 정보의 한계를 이해하지 못하고 있는 것입니다.

def calibrate_confidence(query, retrieved_context, agent):
    """검색 성공 여부와 분리된 독립적인 신뢰도 평가."""
    # 자기 일관성: 여러 번 생성 후 일치도 측정
...

한계: 교정(Calibration) 자체도 고유한 분포 가정(distributional assumptions)을 가진 학습된 함수입니다. 즉, 하나의 불확실성을 다른 불확실성과 맞바꾸는 것입니다. 하지만 교정된 불확실성 — "60%의 확신이 있으며, 이유는 다음과 같습니다" — 은 교정이 완벽하지 않더라도, 교정되지 않은 과잉 확신보다 엄격하게 더 유용합니다.

4. 검색 결과에서의 명시적 공백 탐지 (Explicit Gap Detection in Retrieved Results)

에이전트가 검색 결과에 존재하는 것뿐만 아니라, 검색 결과에서 무엇이 _누락되었는지(missing)_를 찾도록 훈련시키세요. 이것은 검색 전략 (retrieval strategy)이 아니라 프롬프팅 (prompting) 및 평가 (evaluation) 전략이지만, 구조적인 문제, 즉 인덱스 (index)가 필요한 것이 아니라 자신이 가진 것을 반환한다는 문제를 직접적으로 해결합니다.

만약 쿼리 (query)가 비교를 요청한다면, 에이전트는 다음을 확인해야 합니다: 비교의 양측을 실제로 모두 다루는 결과를 얻었는가, 아니면 한쪽은 잘 다루고 다른 한쪽은 제대로 다루지 못하는 결과를 얻었는가? 만약 쿼리가 특정 버전을 요청한다면, 결과가 실제로 해당 버전을 명시하고 있는가, 아니면 버전과 무관한 (version-agnostic) 내용인가?

이것은 가장 비용이 적게 드는 완화 방법이자, "맞는 것처럼 보이지만 틀린" 실패 모드 (failure mode)를 포착할 가능성이 가장 높은 방법입니다. 왜냐하면 에이전트가 검색 결과를 신뢰하는 대신 검증하도록 강제하기 때문입니다.

이것이 에이전트 설계에 의미하는 바

웹 검색 API (web search API), 자체 코퍼스 (corpus)에 대한 RAG 파이프라인 (RAG pipeline), 또는 언제 검색할지를 결정하는 도구 사용 에이전트 (tool-use agent) 등 검색 도구를 사용하여 에이전트를 구축하고 있다면, 검색 레이어 (retrieval layer)를 진실의 원천 (source of truth)이 아닌 **손실이 있고 편향된 신탁 (lossy, biased oracle)**으로 취급해야 합니다.

인덱스 분포 문제 (index distribution problem)란 다음을 의미합니다: