모델 문제처럼 보였던 검색 실패 (Retrieval Failure)

AI 시스템에서 가장 비용이 많이 드는 디버깅 실수 중 하나는 모델이 문제라고 가정하는 것입니다.

사용자가 잘못된 답변을 받습니다.

응답이 틀려 보입니다.

즉각적인 반응은 대개 다음과 같습니다:

"모델이 환각 (Hallucination)을 일으켰다."

때로는 그것이 사실일 수도 있습니다.

하지만 많은 경우 그렇지 않습니다.

한 운영 사고(production incident)가 그 사실을 매우 명확하게 상기시켜 주었습니다.

처음에는 모델 품질 문제처럼 보였던 것이, 실제로는 그 아래에 숨겨진 검색 (Retrieval) 문제로 밝혀졌습니다.

모든 것이 모델을 가리키고 있었다

첫 보고는 단순했습니다.

사용자들은 시스템이 불완전한 답변을 제공한다고 말했습니다.

완전히 틀린 것은 아니었습니다.

단지 중요한 정보가 누락되어 있었습니다.

언뜻 보기에는 추론 (Reasoning) 문제처럼 보였습니다.

응답은 다음과 같았습니다:

• 예상보다 짧음
• 핵심 세부 사항 누락
• 유사한 질문들 사이에서 일관성 없음

아무것도 충돌하지 않았습니다.

오류도 나타나지 않았습니다.

지연 시간 (Latency)은 정상적으로 유지되었습니다.

인프라 지표 (Infrastructure metrics)는 건강해 보였습니다.

명백한 용의자는 모델이었습니다.

프롬프트 테스트로도 아무것도 바뀌지 않았다

우리가 가장 먼저 시도한 것은 많은 팀이 시도하는 방식이었습니다.

프롬프트 조사 (Prompt investigation)였습니다.

우리는 다음을 검토했습니다:

• 시스템 지침 (System instructions)
• 응답 형식 (Response formatting)
• 워크플로우 로직 (Workflow logic)
• 추론 동작 (Reasoning behavior)

모든 것이 정상적으로 보였습니다.

우리는 여러 변형을 테스트했습니다.

답변은 거의 변하지 않았습니다.

그것이 모델이 실제 문제가 아닐 수도 있다는 첫 번째 신호였습니다.

프롬프트 변경이 거의 영향을 미치지 않는다면, 상류 (Upstream)의 무언가가 주의를 기울일 가치가 있습니다.

모델은 잘못된 컨텍스트 (Context)와 함께 작동하고 있었다

다음 단계는 검색 추적 (Retrieval traces)을 검토하는 것이었습니다.

그것이 조사 전체를 바꾸어 놓았습니다.

우리는 검색된 결과에서 관련 문서들이 누락되었다는 것을 발견했습니다.

가끔이 아니었습니다.

일관적이었습니다.

모델이 정보를 무시하고 있었던 것이 아닙니다.

모델은 정보를 아예 받지 못했던 것입니다.

그 차이는 중요합니다.

모델은 오직 전달받은 컨텍스트 (Context)를 바탕으로만 추론할 수 있습니다.

중요한 문서가 프롬프트에 도달하지 않는다면, 아무리 많은 프롬프트 엔지니어링 (Prompt engineering)도 문제를 해결할 수 없습니다.

근본 원인은 놀라울 정도로 작았다

실제 문제는 검색 순위 (Retrieval ranking) 변경에서 비롯되었습니다.

배포 과정에서 문서 점수 (Scoring) 방식이 조정되었습니다.

그 변화는 무해해 보였습니다.

인프라 (Infrastructure)는 건강한 상태를 유지했습니다.

쿼리 (Queries)는 성공적으로 완료되었습니다.

검색 결과도 여전히 반환되었습니다.

하지만 관련성 품질 (Relevance quality)이 변했습니다.

매우 중요한 문서들이 순위에서 점점 낮게 나타나기 시작했습니다.

덜 유용한 콘텐츠들이 더 높은 순위로 올라왔습니다.

운영 측면에서는 아무것도 고장 난 것처럼 보이지 않았습니다.

하지만 여러 워크플로 (Workflows) 전반에서 답변 품질이 저하되었습니다.

이것이 검색 문제 (Retrieval issues)를 탐지하기 어렵게 만드는 이유입니다.

시스템은 기능적으로 작동하는 것처럼 보입니다.

오직 품질만이 저하될 뿐입니다.

검색 문제가 모델 문제처럼 보이는 이유

사용자의 관점에서는 차이가 없습니다.

사용자는 질문을 합니다.

그리고 잘못된 답변을 받습니다.

모델이 눈에 보이는 타겟이 됩니다.

검색 계층 (Retrieval layer)은 숨겨진 채로 남습니다.

하지만 많은 증상이 겹칩니다.

검색 실패 (Retrieval failures)와 모델 실패 (Model failures) 모두 다음과 같은 현상을 일으킬 수 있습니다:

• 불완전한 답변 (Incomplete answers)
• 잘못된 결론 (Incorrect conclusions)
• 일관성 없는 응답 (Inconsistent responses)
• 누락된 세부 정보 (Missing details)
• 낮은 신뢰도의 출력 (Low confidence outputs)

검색 관측성 (Retrieval observability) 없이는 이 둘을 분리하는 것이 어려워집니다.

그렇기 때문에 AI 시스템을 디버깅 (Debugging)하려면 모델 자체를 넘어선 가시성이 필요합니다.

우리는 애플리케이션 로직처럼 검색을 로깅하기 시작했습니다

그 사건 이후, 검색은 일급 운영 고려 사항 (First-class operational concern)이 되었습니다.

우리는 다음 항목들을 추적하기 시작했습니다:

• 검색된 문서 (Retrieved documents)
• 순위 점수 (Ranking scores)
• 누락된 결과 패턴 (Missing result patterns)
• 검색 커버리지 (Retrieval coverage)
• 중복 검색률 (Duplicate retrieval rates)
• 문서 최신성 (Document freshness)

이를 통해 다음과 같은 질문에 답할 수 있게 되었습니다:

• 모델이 실제로 어떤 정보를 받았는가?
• 어떤 문서가 답변에 영향을 주었는가?
• 어떤 관련 정보가 제외되었는가?
• 배포 후에 검색 품질이 변했는가?

그러한 답변들은 종종 모델 로그만으로는 알 수 없는 것들을 드러냅니다.

"성공적인" 검색의 숨겨진 위험

한 가지 교훈이 두드러졌습니다.

검색 시스템은 완전히 정상적으로 보이면서도 실패할 수 있습니다.

데이터베이스가 응답합니다.

검색이 완료됩니다.

결과가 반환됩니다.

모니터링 대시보드 (Monitoring dashboards)는 초록색을 유지합니다.

하지만 가장 중요한 문서들이 모델에 도달하지 못할 수도 있습니다.

전통적인 인프라 모니터링 (Infrastructure monitoring)은 이를 잡아내지 못합니다.

가용성 모니터링 (Availability monitoring)이 아닌 품질 모니터링 (Quality monitoring)이 필요합니다.

잘못된 문서를 반환하는 검색 시스템은 문서를 전혀 반환하지 않는 검색 시스템보다 종종 더 위험하기 때문입니다.

적어도 명백한 실패는 빠르게 감지됩니다.

조용한 관련성 실패 (Silent relevance failures)는 그렇지 않습니다.

더 큰 교훈

AI 시스템이 잘못된 답변을 내놓을 때, 모델이 자동으로 첫 번째 용의자가 되어서는 안 됩니다.

답변의 품질은 그 뒤에 있는 컨텍스트 (Context)만큼만 좋습니다.

모델은 추론 (Reason)합니다.

검색 (Retrieval)은 모델이 무엇에 대해 추론할 수 있는지를 결정합니다.

이 점이 검색을 전체 아키텍처 (Architecture)에서 가장 영향력 있는 구성 요소 중 하나로 만듭니다.

그리고 때때로 가장 큰 AI 문제는 전혀 AI 문제가 아닐 수도 있습니다.

그것은 모델 응답 뒤에 숨겨진 검색 문제 (Search problem)입니다.