검색이 무너지면 생성은 손쓸 수 없다

2026년 RAG 실패의 73%는 생성이 아니라 검색 단계에서 발생합니다. 프롬프트와 모델을 아무리 다듬어도, 검색이 엉뚱한 근거를 물어오면 생성 단계에서는 이를 되돌릴 방법이 없습니다. 품질 개선의 무게중심은 프롬프트가 아니라 검색으로 옮겨가야 합니다. 실패의 대부분이 검색에서 난다면, 관측과 복구 분기도 검색 단계에 집중해야 합니다.

naive 파이프라인은 프로덕션이 아니다

chunk→embed→cosine→prompt로 이어지는 단일 파이프라인은 프로토타입일 뿐 프로덕션이 아니라는 것이 현재의 합의입니다. 이 구조는 질의를 한 번 임베딩해 코사인 유사도 상위 k개를 그대로 프롬프트에 밀어넣습니다. 질의가 모호하거나, 근거가 여러 문서에 흩어져 있거나, 상위 k개가 실제로는 무관할 때 이를 걸러낼 판단 지점이 하나도 없습니다.

Agentic RAG는 검색을 다단계 의사결정으로 다룬다

Agentic RAG는 검색을 단일 조회가 아니라 계획·재검색 판단·중간 증거 검사로 이어지는 다단계 의사결정으로 취급합니다. 질의를 분해해 검색 계획을 세우고, 1차 검색 결과의 근거 충분성을 평가한 뒤, 부족하면 질의를 재작성해 재검색하며, 확보한 증거가 답변에 충분한지 다시 검사한 다음에야 생성으로 넘깁니다.

A4 분량 상세 가이드: 기획부터 운영까지

기획 단계에서는 검색 품질 목표를 수치로 고정합니다. 예를 들어 근거 충분성 검사 통과율 95% 이상, 검색 p95 지연 1.5초 이하, 질의당 재검색 최대 2회, 인용된 근거의 출처 일치율 100%를 목표로 둡니다. 목표가 수치로 없으면 어느 단계가 실패인지 판정할 수 없고, 재검색과 중단의 경계도 흐려집니다.

실패 패턴은 검색 단계에 집중됩니다. 상위 k개가 모두 무관한 무근거 검색, 근거가 여러 문서에 흩어져 한 번의 조회로는 부족한 분산 근거, 질의 모호성으로 엉뚱한 축으로 검색되는 경우가 대표적입니다. 복구 분기는 세 갈래로 둡니다. 근거 충분성 점수가 임계값 미만이면 질의를 재작성해 재검색하고, 재검색 상한 2회 안에서도 충분성이 확보되지 않으면 사람 확인으로 넘기거나 확실한 부분만 답하고 나머지는 모른다고 명시하는 안전 축약으로 내려갑니다. 검색이 연속 실패하거나 지연이 상한을 넘으면 중단 조건을 발동해 생성을 시도하지 않습니다.

운영에서는 표준 로그를 남깁니다. 질의, 검색 계획, 각 라운드의 상위 k 문서 ID와 점수, 근거 충분성 판정, 재검색 횟수, 최종 인용 출처를 한 형식으로 기록해 어느 단계에서 실패했는지 사후에 재구성할 수 있게 합니다. 로그와 검색 색인에 개인정보가 들어가지 않도록 PII 마스킹 규칙을 검색 입력과 저장 양쪽에 적용합니다. 무근거 응답 위반은 0건을 목표로, 근거 없이 생성으로 넘어간 사례를 매일 집계합니다.

지속 개선 루프는 주간 단위로 실패 로그를 검색 단계별로 분류합니다. 무근거 검색이 많으면 색인·청킹 전략을, 재검색이 잦으면 질의 재작성 규칙을, 사람 확인 이관이 많으면 충분성 임계값을 조정합니다. 개선은 통과율·p95 지연·재검색 평균 횟수의 추세로 검증하며, 한 지표를 올리려다 다른 지표가 상한을 넘지 않는지 함께 확인합니다.

실행 요약

정리하면 RAG 실패의 73%는 검색에서 나므로, 개선의 무게중심을 검색으로 옮겨야 합니다. naive 단일 파이프라인을 계획·재검색·중간 증거 검사의 다단계 의사결정으로 바꾸고, 통과율 95%·p95 1.5초 같은 수치 목표와 재검색·사람 확인·안전 축약·중단이라는 복구 분기를 명시하며, 표준 로그와 PII 마스킹으로 실패를 사후 재구성하고 주간 루프로 임계값을 계속 조정하는 것이 핵심입니다.

참고 링크

Agentic RAG (Lyzr)