RAG 시스템이 생산에 실패하게 만드는 일반적인 함정

검색 증강 생성은 외부 지식으로 대규모 언어 모델을 강화하도록 되어 있습니다. 데모에서는 훌륭하게 작동할 수 있습니다. 선별된 작은 데이터 세트, 깔끔한 쿼리, 제한 없는 대기 시간 예산을 통해 사용자가 옳다고 믿는 지식이 풍부하고 근거 있는 답변을 얻을 수 있습니다. 그러나 많은 팀에서는 RAG 애플리케이션을 사용자에게 배포하면 성능이 저하된다는 사실을 알게 됩니다. 쿼리가 모호해지고, 말뭉치가 확장되고, 검색 품질이 떨어지고, 대기 시간이 늘어나며, 시스템의 정확도가 소리 없이 사라지기 시작합니다. 더 나쁜 것은, 잘못된 평가 기술은 사용자가 불평할 때까지 시스템이 실제로 실패하기 시작하는 부분을 숨긴다는 것입니다. 이 기사에서는 많은 RAG 시스템이 프로덕션에서 실패하는 이유를 살펴봅니다. 우리는 최근 연구 및 업계 지침을 참고합니다. 우리는 검색 품질, 대기 시간 상쇄, 드리프트 삽입 및 평가 격차에 관한 문제를 일련의 실패 모드의 링크로 구성합니다. 강력한 프로덕션 RAG 시스템을 구축하려면 이 체인의 각 링크를 고려해야 합니다.

주요 시사점

• 대부분의 RAG 실패는 생성이 아닌 검색에서 시작됩니다. 시스템이 불완전하거나 관련성이 없거나 순위가 낮은 증거를 검색하면 강력한 LLM이라도 약한 답변을 생성하게 됩니다.
• 더 나은 검색을 위해서는 더 나은 엔지니어링 선택이 필요합니다. 도메인 인식 청킹, 하이브리드 검색 및 순위 재지정은 관련성을 높이고 자동 검색 실패를 줄이기 위한 핵심 기술로 제시됩니다.
• 지연 시간은 빠르게 제작 병목 현상을 발생시킵니다. 더 큰 top_k, reranker, 긴 컨텍스트 및 추가 검색 단계를 추가하면 재현율이 향상될 수 있지만 실제 사용자에게는 시스템이 너무 느려질 수도 있습니다.
• 드리프트를 삽입하면 시간이 지남에 따라 성능이 조용히 저하됩니다. 내장 모델, 문서 컬렉션 및 사용자 어휘의 변경으로 인해 검색 동작이 모두 바뀔 수 있으므로 버전 관리 및 관찰 가능성이 필요합니다.
• 최종 답변 품질만으로는 평가하기에 충분하지 않습니다. 팀에는 별도의 검색 및 생성 지표, 현실적인 테스트 세트, 지속적인 모니터링, 증거가 약하거나 누락된 경우 시스템이 이를 중단할 수 있는 능력이 필요합니다.

검색 품질 저하로 인한 실패

낮은 검색 품질은 프로덕션에 배포할 때 RAG 시스템이 실패하는 가장 빈번한 원인 중 하나입니다. 개발자는 종종 잘못된/잘못된 답변에 대해 LLM을 비난합니다. 그러나 결함은 일반적으로 파이프라인 초기에 발생합니다. 시스템이 완전하거나 관련성 있는 증거를 검색할 수 없거나 증거의 순위가 좋지 않은 경우 최고의 모델이라도 신뢰할 수 있는 응답을 생성할 가능성이 낮습니다. 검색 품질은 백그라운드 단계가 아닌 최고의 엔지니어링 문제로 다뤄져야 합니다.

대부분의 실패는 LLM이 쿼리를 확인하기 전에 발생합니다

표준 파이프라인은 사용자 쿼리를 포함하고 벡터 저장소에서 상위 k 문서를 검색한 후 LLM으로 보냅니다. 해당 파이프라인의 모든 화살표는 잠재적인 실패 지점입니다.

Naïve RAG는 검색이 잘못된지 여부에 관계없이 시스템이 답변을 제공하므로 이러한 실패를 모호하게 만듭니다. LLM의 단점보다는 잘못된 청크 전략, 제한된 리콜, 재순위 누락으로 인해 많은 제작 문제가 발생합니다.

청크 실수는 소리 없는 실패를 낳습니다

청크 크기는 정밀도/재현율에 영향을 미칩니다. 청크가 클수록 관련성이 낮으면서 더 많은 컨텍스트를 제공하는 반면, 청크가 작을수록 정밀도는 높아지지만 주변 정보는 손실됩니다. 계층적(상위-하위) 청킹은 전체 섹션을 상위 청크로 저장하고 더 작은 관련 하위 청크만 검색하여 이러한 절충안을 해결합니다.

대학 프레젠테이션 데크에 대한 NVIDIA의 내부 테스트에서는 계층적 청크가 고정 크기 청크의 답변 정확도를 61%에서 89%로 향상시키는 것으로 나타났습니다. 구조적 경계를 존중하고 가능한 경우 도메인 인식 분할을 적용하면서 적절한 청크 크기를 선택하는 것이 중요합니다.

하이브리드 검색 및 순위 재지정

순수 밀집 검색은 의미론적 유사성은 좋지만 정확한 식별자는 누락됩니다. 순수 키워드 검색은 정확한 용어에 민감하지만 의미론적 해석에서는 실패합니다. 하이브리드 검색 시스템은 밀집(벡터) 검색과 희소(BM25/키워드) 검색을 동시에 실행한 다음 상호 순위 융합을 통해 결과를 융합합니다.

하이브리드 검색 시스템은 의미적 유사성 신호와 어휘 일치 신호를 결합하여 어휘 불일치를 해결합니다. 융합 후 리랭커(크로스 인코더)를 사용하여 후보 쌍의 점수를 다시 매기면 재현율이 향상됩니다. 기본적으로 reranker는 검색된 문서의 순서를 변경하여 가장 관련성이 높은 문서만 LLM이 검토하는 컨텍스트에 포함되도록 합니다. 이를 통해 토큰 제한을 절약하고 LLM 회상을 향상시키면서 컨텍스트 스터핑을 방지합니다.

검색 측정항목은 별도로 모니터링해야 합니다

팀에서는 엔드투엔드 답변 품질만 측정하는 경향이 있습니다. 검색 자체에는 정밀도@k(검색된 청크 중 어느 부분이 관련되어 있습니까?), 회상@k(관련 청크 중 어느 부분을 검색했습니까?), 평균 상호 순위(첫 번째 관련 청크가 얼마나 높았습니까?), 표준화된 할인 누적 이득(전체 순위가 얼마나 좋은가요?) 등 사용할 수 있는 측정항목이 있습니다.

이를 측정하지 않으면 오류가 잘못된 검색으로 인해 발생했는지 또는 잘못된 생성기로 인해 발생했는지 알 수 없습니다. 테스트 쿼리와 골든 데이터 세트를 사용하면 오프라인으로 평가할 수 있습니다. 실제 쿼리에서 이러한 측정항목을 추적하면 생산 회귀를 표면화할 수 있습니다.

예시를 통한 검색 실패 진단

모호한 쿼리와 어휘 불일치로 인해 잘못된 검색이 발생하는 경우가 많습니다. 사용자는 문서에서 "보상 패키지"를 언급하는 동안 "급여"를 검색할 수 있습니다. 조밀한 임베딩은 동의어를 인식하지 못할 수 있지만 하이브리드 검색은 이를 수정합니다. 또 다른 경우는 식별자와 같은 정확한 일치를 위한 것입니다. "SKU‑B4920" 또는 "섹션 4.2.1"에 대한 쿼리에는 정확한 어휘 일치가 필요합니다.

"중간 손실"은 관련 정보가 긴 문서에 깊이 묻혀 있을 때 발생합니다. LLM은 중간 청크의 토큰에 과소 가중치를 부여합니다.

청킹 아티팩트는 답변이 두 개의 청크로 분할될 때 발생하므로 두 청크 모두 완전한 답변을 포함하지 않습니다. 계층적 청킹은 상위 노드와 하위 노드를 연결하여 이를 완화하는 데 도움이 됩니다.

실제 시스템의 지연 시간 폭발로 인한 실패

지연 시간은 데모에서 작동하는 RAG 시스템이 프로덕션에서 어려움을 겪는 주요 이유 중 하나입니다. 검색 파이프라인이 더욱 정교해짐에 따라 응답 시간이 빠르게 증가하고 팀이 답변 품질과 유용성을 희생하게 될 수 있습니다.

검색-지연 시간 균형

프로덕션 팀은 검색 품질과 대기 시간 예산의 균형을 맞춰야 하는 경우가 많습니다. 응답 시간을 늘리는 모든 것(top_k로 더 커짐, 하이브리드 검색 추가, 순위 재지정 또는 장기 컨텍스트 모델 실행)은 이러한 예산을 절감합니다. 사용자는 응답성 있는 답변을 기대하고 기업 통합에는 엄격한 대기 시간 예산이 따르기 때문에 절충이 특히 어렵습니다. 그러나 Cornell과 NVIDIA의 최근 연구에서 알 수 있듯이 RAG는 상당한 대기 시간 오버헤드를 발생시킵니다. 검색을 너무 자주 실행하면 정확성이 향상되지만 엔드투엔드 대기 시간이 약 30초로 늘어납니다. 이는 프로덕션 용도로 사용하기에는 너무 높은 수치입니다.

일반적으로 세대가 지배적이지만 검색이 중요합니다

RAGPerf를 사용한 벤치마킹은 생성이 종종 텍스트 전용 RAG 파이프라인의 지배적인 부분임을 보여줍니다. . 검색 품질이 유지된다면 더 작은 LLM을 선택하면 답변 품질을 저하시키지 않고 대기 시간을 크게 줄일 수 있습니다. 다중 모드 파이프라인(PDF 및 이미지 검색)에는 순위 재지정 및 관련 교차 모드 모델로 인해 부분적으로 컴퓨팅 수요가 높습니다. 벡터 데이터베이스가 느리거나 동시 조회를 허용하지 않는 경우 검색 대기 시간이 늘어날 수 있습니다. 그러나 빠른 조회를 사용하더라도 순위 재지정은 많은 RAG 워크로드의 총 대기 시간을 지배할 수 있습니다.

지연 시간, 비용 및 컨텍스트 창

일부 팀은 top_k를 늘리거나 LLM의 컨텍스트에 더 많은 문서를 넣어서 재현율을 해결하려고 합니다. 연구에 따르면 이는 반대 효과가 있는 것으로 나타났습니다. 프롬프트에 더 많은 문서를 추가할수록 LLM이 올바른 정보를 기억하는 능력이 떨어집니다. 검색 재순위는 많은 문서를 검색한 다음 LLM에 가장 적합한 문서만 선택하여 이 문제를 해결합니다. 컨텍스트 창이 길면 '중간 상실' 및 천문학적인 계산 비용이 발생합니다.

지연 시간 최적화

RAG 시스템의 지연 시간을 해결하려면 전체 파이프라인에 걸쳐 의도적인 조정이 필요합니다.

내장 드리프트 및 지식 변경으로 인한 실패

임베딩은 텍스트를 서로 가까운 유사한 의미를 지닌 고차원 벡터로 나타냅니다. 팀에서는 인덱스 버전을 적절하게 관리하거나 관련성 변경 사항을 벤치마킹하지 않고 문서를 다른 포함 모델로 다시 포함하거나 쿼리 인코더를 교체하는 경우가 많습니다. 새로운 모델은 객관적으로 더 강력할 수 있지만 순위, 회상 또는 도메인별 언어에 영향을 미치는 예상치 못한 방식으로 동네 구조를 변경할 수 있습니다. 일반화된 벤치마크에서 탁월한 모델이 실제 기업 용어로는 매우 뛰어난 성능을 발휘할 수도 있습니다.

드리프트의 세 가지 원인

1. 모델 드리프트. 임베딩 모델은 지속적으로 업데이트됩니다. 임베딩 모델 버전을 사용하여 문서를 인덱싱하는 경우 다른 모델의 임베딩으로 문서를 검색할 수 없습니다. 코퍼스를 다시 색인화하지 않고 임베딩 모델을 전환하면 검색에 영향을 미칩니다.
2. 코퍼스 드리프트. 색인에 새 문서, 특히 새 유형의 문서를 추가하면 벡터 공간이 변경됩니다. 새로운 밀집 벡터 클러스터가 나타납니다. 이러한 밀집된 클러스터는 다른 문서와 일치해야 하는 쿼리를 가져오기 시작합니다. 사용자 생성 콘텐츠나 시끄러운 콘텐츠를 추가하면 임베딩 모델을 변경하지 않더라도 시간이 지남에 따라 검색 품질이 저하됩니다.
3. 쿼리 드리프트. 사용자의 어휘는 시간이 지남에 따라 확장되고 변화합니다. 새로운 용어(“원격 근무”, “스테이블코인”, “신속한 엔지니어링”)가 사용되기 시작하고 오래된 용어는 사라집니다. 기존 임베딩은 훈련 당시 존재하지 않았던 단어와 일치할 수 없습니다. 회사가 제품 중 하나의 이름을 변경하는 경우 임베딩에 여전히 이전 이름이 반영되므로 새 이름을 검색할 수 없습니다.

평균 상호 순위로 임베딩 드리프트 감지

다음은 시스템 변경 전후 또는 시간 경과에 따른 검색 성능의 변화를 모니터링하여 임베딩 드리프트를 감지하는 방법을 보여주는 예제 다이어그램입니다. 다이어그램은 먼저 관련 문서가 순위 상위에 표시되는 기준 MRR 점수를 계산합니다. 그런 다음 관련 문서의 순위가 더 낮은 현재 MRR 점수를 계산합니다. 그런 다음 시스템은 기준 MRR과 현재 MRR 사이의 감소율을 계산합니다. MRR 하락이 미리 선택된 임계값을 초과하는 경우 시스템은 드리프트 임베딩에 대한 경고를 발생시키고 임베딩 모델, 데이터 분포 및 인덱스 검토를 제안합니다. 그렇지 않고 하락폭이 임계값 미만이면 시스템은 검색 시스템이 안정적인 것으로 판단하고 계속 모니터링합니다.

이러한 이유로 프로덕션 RAG 시스템은 명시적으로 버전이 지정되고 관찰 가능해야 합니다. 임베딩에는 버전이 지정되어야 합니다. 인덱스 빌드는 추적 가능해야 합니다. 청킹 정책은 문서화되고 재현 가능해야 합니다. 품질이 저하되기 시작하면 다음과 같은 질문에 대답할 수 있어야 합니다. 이 인덱스를 생성한 임베딩 모델은 무엇입니까? 이 콘텐츠 덩어리를 만든 청크 규칙은 무엇입니까? 이 문서가 마지막으로 시스템에 다시 수집된 때는 언제입니까? 이 요청을 처리한 검색기와 순위 재지정자는 무엇입니까?

파이프라인에 대한 가시성이 없으면 드리프트가 무작위로 보일 것입니다. 이를 통해 진단이 가능해집니다.

평가 격차로 인한 실패:실제 병목 현상을 숨김

약한 평가는 팀이 RAG 시스템을 프로덕션에 배포하지 못하는 네 번째로 흔한 이유입니다. 우리는 최종 답변만을 평가하는 경향이 있습니다. 그것만으로는 충분하지 않습니다.

프로덕션 등급 RAG는 파이프라인입니다. 레이어 수에 관계없이 입력이 좋지 않으면 최종 출력이 좋지 않을 수 있습니다. 검색자가 올바른 문서를 검색하지 못했을 수 있습니다. 순위 결정자가 최고의 증거의 순위를 너무 낮게 매겼을 수도 있습니다. 컨텍스트 어셈블러에 노이즈가 너무 많이 포함되었을 수 있습니다. 발전기가 가장 강한 통로를 간과했을 수도 있습니다. 검색된 증거에 대해 완전히 불성실하면서도 대답은 광범위한 수준에서 정확할 수 있습니다. 최종 출력 텍스트에만 점수를 매기면 약한 단계를 식별할 수 없습니다.

검색 측정항목은 별도로 평가되어야 합니다

이러한 이유로 RAG 평가에는 생성 메트릭과 별도의 검색 메트릭이 포함되어야 합니다. 검색 지표에는 컨텍스트 정밀도와 컨텍스트 회상이 포함되어야 합니다.

• 맥락 회상 :문맥 회상은 검색된 구절에 질문에 답하는 데 필요한 정보가 포함되어 있는지 확인합니다.
• 컨텍스트 정확성 :컨텍스트 정밀도는 검색된 세트가 대부분 관련성이 있는지 아니면 노이즈로 오염되었는지를 측정합니다.
• 순위 품질: 순위 품질도 중요합니다. 왜냐하면 1순위의 관련 구절이 10순위의 동일한 관련 구절보다 더 유용하기 때문입니다.

세대 측정항목도 그만큼 중요합니다

검색이 측정되면 생성 계층은 자체 용어로 평가되어야 합니다. 두 가지 핵심 측정항목은 근거와 충실도입니다.

• 접근성: 근거는 답변이 검색된 맥락에서 제공된 정보를 반영하는지 여부를 묻습니다.
• 성실함: 충실도는 모델이 해당 맥락을 정확하게 나타내는지 여부를 묻습니다. 시스템이 원본 자료를 잘못 표현하면서도 그럴듯하게 들릴 수 있기 때문에 이 측정항목이 중요합니다.

비현실적인 테스트 데이터는 실제 실패를 숨깁니다

비현실적인 테스트 데이터도 또 다른 주요 문제입니다. 많은 팀이 내부 팀에서 신중하게 선별한 명확하고 종합적인 질문이나 프롬프트를 평가합니다. 이는 근본적으로 실제 실패 표면을 숨깁니다. 프로덕션에서의 평가 조건에는 모호한 질문, 모순되는 문서, 부분적인 사용자 입력, 오래된 콘텐츠, 전혀 답변하지 않는 것이 정답인 상황 등이 포함되어야 합니다. 데이터 세트가 실제 사용자 행동을 반영하지 않는 경우 평가는 진단 도구가 아닌 편안한 메커니즘이 됩니다.

배포 후에도 평가는 계속되어야 합니다

초기 실행을 완료한 후에도 평가가 중단되어서는 안 됩니다. 생산 RAG가 변경됩니다. 문서가 변경됩니다. 임베딩이 교체됩니다. 순위 논리가 진화합니다. 프롬프트 템플릿이 이동됩니다. CI/CD 및 배포 후 프로덕션 추적의 일부로 평가하지 않으면 자체 모니터링이 아닌 불만스러운 사용자의 회귀에 대해 알게 됩니다.

벤치마크가 좋아 보이는데도 프로덕션 RAG가 실패하는 이유

많은 팀이 혼란스러워하는 부분이 바로 여기에 있습니다. 벤치마크는 개선되었지만 라이브 시스템은 여전히 실망스럽습니다.

생산 실패는 일반적으로 인센티브 불일치로 인해 발생합니다. 팀은 대기 시간 예산을 고려하지 않고 검색 회상을 최적화하거나 검색 정밀도를 추적하지 않고 더 높은 LLM 점수를 위해 최적화하려고 노력합니다. 생성 품질을 희생하면서 검색이 과도하게 조정되어 노이즈가 발생할 수 있습니다. 검색 개선에 관계없이 생성이 과도하게 조정될 수 있습니다. 검색 정확도와 생성 정확도 사이의 적절한 비율은 애플리케이션에 따라 다릅니다. 규정 준수, 법률 및 기타 고위험 사용 사례에는 최대한의 충실성과 상황 정확성이 필요합니다. 창의적인 사용 사례에서는 속도 대신 소음을 허용할 수 있습니다.

생산은 단일 지표에 최적화되지 않습니다. 검색 품질, 대기 시간, 신선도, 근거 및 운영 단순성 간에는 장단점이 있습니다. 이것이 바로 데모 성공이 오해의 소지가 있는 이유입니다. "제대로 들리는" 데모 보상 시스템. 생산은 신뢰성을 보상합니다.

프로덕션 RAG 시스템을 수정하는 방법

앞으로 나아갈 길은 RAG를 버리는 것이 아닙니다. 규율 있는 검색 시스템으로 취급하는 것입니다.

FAQ 섹션

RAG에서 검색 품질을 어떻게 측정하나요?

우리는 문맥 정밀도, 문맥 재현율, 순위 품질 등의 검색 지표를 사용하고 검색된 증거가 실제로 답변 생성을 지원하는지 여부도 확인합니다.

RAG 시스템이 생산에 실패하는 원인은 무엇입니까?

생산 실패는 검색 품질 저하, 대기 시간 증가, 임베딩/코퍼스 드리프트, 문제 시작 위치를 숨기는 잘못된 평가 관행으로 인해 가장 일반적으로 발생합니다.

RAG 파이프라인에 드리프트 삽입이란 무엇인가요?

임베딩 드리프트는 임베딩 모델, 말뭉치 또는 실시간 쿼리 동작에 대한 업데이트가 명백히 손상된 시스템 동작을 유발하지 않으면서 검색 동작을 천천히 변경(관련성 저하)할 때 발생합니다.

RAG 지연 시간이 대규모로 증가하는 이유는 무엇인가요?

프로덕션 시스템에 쿼리 재작성, 다중 검색 패스, 순위 재지정, 추가 모델 호출, 대규모 말뭉치를 추가하는 경우가 많아 처리 시간과 운영 복잡성이 증가하기 때문에 지연 시간이 늘어납니다.

RAG의 기반과 충실성을 어떻게 평가하시나요?

생성된 답변을 검색된 증거와 비교하여 주장이 출처에 의해 뒷받침되는지 여부와 문구가 발명이나 왜곡 없이 해당 출처를 정확하게 반영하는지 여부를 확인합니다.

결론

대부분의 RAG 시스템의 생산 실패는 단일 실패 지점의 결과가 아닙니다. 대신 책임 있는 엔지니어는 대부분의 고장이 연결된 체인의 약한 링크에서 시작된다는 것을 알아차릴 것입니다. 검색 품질은 거의 항상 가장 먼저 실패합니다. 엔지니어는 더 많은 검색, 더 많은 컨텍스트 및 더 많은 오케스트레이션 레이어를 활용하여 이 문제를 "해결"합니다. 그렇게 하면 대기 시간이 늘어납니다. 임베딩, 말뭉치, 사용자 행동이 모두 시간이 지남에 따라 표류함에 따라 약한 평가 지표는 시스템이 실제로 실패하는 부분을 숨깁니다. 관리자가 문제가 있음을 깨닫기도 전에 사용자는 이를 깨닫고 신뢰를 잃기 시작합니다. 그때쯤이면 패턴의 붕괴가 신비롭게 느껴집니다. 하지만 문제는 처음부터 분명했습니다.

RAG가 대규모로 실패하는 이유는 패턴이 잘못되었기 때문이 아니라 프로덕션 RAG 시스템을 구축하려면 강력한 검색 엔지니어링, 대기 시간 관리, 드리프트 완화 및 지속적인 평가가 필요하기 때문입니다. 그들은 향상된 순위, 향상된 청크, 더 나은 관찰 가능성, 근거와 충실도 측정을 요구합니다. 가장 중요한 것은 팀이 RAG를 일단 설정하고 잊어버리는 데모 아키텍처가 아닌 살아있는 시스템으로 접근해야 한다는 것입니다.

참조

• 프로덕션 중인 RAG 시스템:실패 이유 및 해결 방법
• 2026년 RAG(및 LLM)를 위한 최고의 청킹 전략
• RAG 평가란 무엇입니까? 검색 품질 및 답변 근거 측정
• 검색-증강 생성 모델 추론의 시스템 장단점 이해를 위해
• RAGPerf:검색 증강 생성 시스템을 위한 엔드투엔드 벤치마킹 프레임워크
• 재순위 지정 및 2단계 검색
• RAG에서 컨텍스트까지 - RAG 2025년 연말 리뷰

이 저작물은 Creative Commons Attribution-NonCommercial- ShareAlike 4.0 International에 따라 라이센스가 부여됩니다. 라이센스.