- 책: RAG 포켓 가이드: 생산을 위한 검색, 청크 및 재정렬 패턴
- 저의 다른 책: Go로 사고하기 (2책 시리즈) — Go 프로그래밍 완전 가이드 + Go에서의 헥사곤 아키텍처
- 저의 프로젝트: 헬멘스 IDE |GitHub — 개발자들이 Claude Code와 다른 AI 코딩 도구와 함께 출시하는 데 사용되는 IDE
- 나: xgabriel.com | GitHub
귀하의 PM이 Gemini 2M 맥락 데모를 보았습니다. 그들은 명백한 질문을 되돌아왔습니다: "전체가 프롬프트에 들어맞는데 왜 여전히 문서를 청크하고 있나요?" 깔끔한 답변은 없습니다. 그 이유는 반은 "비용"이며, 그들은 비용이 떨어질 것이라고 생각하고, 반은 "정확도"이며, 그것을 측정하지 않았기 때문입니다.
이 게시물은 두 번째 절반입니다. 허황된 것을 찾는 벤치마크 공급자들이 자신들의 랜딩 페이지에 넣지 않은 것은 공개되었습니다. 검색과 유사한 쿼리에 대한 정확도는 60k 토큰을 초과하는 모든 1백만 토큰 창을 주장하는 모델에서 저하됩니다. 전체 코퍼스를 컨텍스트에 넣는 것을 채우는 여섯 가지 쿼리 형태에서는 품질이 가격보다 먼저 손실되기 전에 손실됩니다. 또한 세 가지 경우에서는 긴 컨텍스트가 진정으로 이기고, 그렇지 않다고 속이면 XML을 새 API에 사용하는 엔지니어처럼 보이게 됩니다.
토론을 끝낸 두 숫자
500,000개의 토큰 코퍼스를 가져오세요: 중간 규모의 SaaS 제품의 도움 문서 또는 단일 팀의 마지막 두 해 디자인 문서. 쿼리는 그 안에서 대략 4,000개의 토큰을 참조해야 합니다.
단일 쿼리에 대한 수학적 분석은 2026년 4월 가격 목록을 사용하여 세 가지 경계 모델에 대한 것입니다. 긴 맥락은 프롬프트에 있는 전체 500k 코퍼스를 의미합니다. 검색은 관련 청크 ~4k 토큰을 반환하는 벡터 검색을 의미합니다.
| 모델 | 입력 가격 ($/MTok) | 긴 맥락 비용 | 검색 비용 | 배수 |
|---|---|---|---|---|
| GPT-4.1 | $2.00 | $1.00 | $0.008 | 125x |
| 클로드 소네트 4.5 | $3.00 | $1.50 | $0.012 | 125x |
| 제미니 2.5 프로 (>200k) | $2.50 | $1.25 | $0.010 | 125x |
쿼리당 125배의 요소. 하루 10k 쿼리 시, 긴 컨텍스트 비용은 $12,500이고 검색 비용은 $100입니다. 프롬프트 캐싱은 최선의 경우, 모든 쿼리가 동일한 접두사를 가지면 이를 5-10배로 줄일 수 있지만, 대부분의 생산 트래픽은 그렇지 않습니다.
테일 지연 시간은 두 번째 숫자이며, 아무도 슬라이드 데크에 넣지 않는 것입니다. 500k 토큰 프롬프트의 TTFT(첫 토큰까지의 시간)는 대부분의 최전선 엔드포인트에서 8초에서 25초 사이에 있습니다. 뜨거운 벡터 인덱스를 사용한 검색은 50-150ms에 반환하고, 4k 토큰에 대한 LLM 호출은 첫 토큰을 초보만에 스트리밍합니다. 채팅 표면의 p95 지연 예산은 2초입니다. 긴 컨텍스트는 모델이 토큰화를 완료하기 전에 예산을 초과합니다.
"긴 컨텍스트가 비용이 얼마나 드는지"에 대한 답은 다음과 같습니다: 125배 더 많은 돈, 10-25배 더 나쁜 지연 시간, 그리고 아직 품질에 대해서는 이야기하지 않았습니다.
흙 속에 바늘을 찾는 차트 공급자들이 더 이상 보여주지 않았습니다
2024년에는 모든 긴 컨텍스트 릴리스가 녹색과 빨간색 열람도를 포함했습니다: 컨텍스트 깊이와 위치를 가리키는 흙 속 바늘. 열람도는 거의 전부 녹색이었습니다. 2025년 말에는 열람도가 릴리스 게시물에 더 이상 나타나지 않았습니다. 벤치마크는 여전히 존재합니다. 하지만 "이 문장을 찾아라"와 더 어려운 작업을 수행할 때는 더 이상 좋은 모습을 보이지 않습니다.
NVIDIA에서 제공하는 대중적인 RULER 벤치마크(후속 제품인 LongBench v2와 같은 것들 포함)는 다양한 컨텍스트 길이에서 검색식 작업을 테스트합니다: 다중 키 너드 검색, 가변 추적, 집계, 다호프 추론. 1M 토큰 창을 가진 모든 테스트된 모델에서, 다호프 및 집계 작업의 정확도는 모델에 따라 32k와 128k 토큰 사이 어딘가에서 급격히 떨어집니다. 단일 너드는 높게 유지됩니다; 작업을 어렵게 만들수록 절벽은 더 일찍 나타납니다.
바위의 모양이 관점입니다. 단일 사실은 알려진 위치에서: 500k을 넘어서면 약 100% 근처에 머무릅니다. 다중 사실 추론에서는 모델이 세 곳의 증거를 조합해야 하는 경우: 대부분 테스트된 모델에서 64k까지는 60% 미만으로 떨어집니다. 이것이 실제 RAG 쿼리가 사는 환경입니다.
사례 1: 멀리 떨어진 청크를 가로질러 다중 힉 추론
사용자가 질문합니다: "3월에 제출된 계약 수정안이 우리가 사용 중인 API 계층의 SLA 벌금을 변경했나요?" 이 질문에 답하기 위해 모델은 원본 SLA 섹션을 찾아야 하며, 수정안을 찾아야 하고, 사용자가 사용 중인 API 계층을 식별해야 하며(아마도 별도의 문서에서), 수정안이 해당 계층에 영향을 미쳤는지 판단해야 합니다.
세 번의 검색, 한 번의 추론 단계. 검색을 통해 세 개의 관련 청크(다중 쿼리 확장을 포함할 수 있음)를 가져오고, 모델은 이들을 인접하게 본다. 긴 컨텍스트에서는 모델이 200개의 다른 계약 섹션 중 보기 흉내만 같은 세 개를 주의력만으로 찾아야 한다. 모델은 가장 두드러진 것, 주의력이 우연히 떨어지는 곳에 가장 가까운 것을 선택하고 자신감 있는 잘못된 답을 준다.
수정은 더 지능적인 프롬프트가 아닙니다. 수정은 모델 앞에 관련된 세 개의 청크를 놓는 것뿐입니다.
사례 2: 코퍼스 내의 모순되는 출처
당신의 지식 베이스에는 Q4의 새로운 정책 문서와 Q1의 구형 정책 문서가 모두 남아있어서 아무도 정리하지 않았기 때문입니다. 사용자가 정책에 대해 질문합니다. 긴 맥락이 혼합됩니다. 모델은 두 문서를 모두 읽고, 응답은 "정책은 X이지만 일부 경우에는 Y일 수 있습니다"라고 모호하게 말합니다. 이것은 부정확한 정보를 세심함으로 위장한 것입니다.
검색은 긴 맥락이 할 수 없는 일을 할 수 있게 해줍니다: 신선도로 순위를 매기고, 출처로 중복을 제거하고, 모델에 하나의 표준 조각을 전달합니다. 검색기는 한쪽을 택합니다. 그런 다음 모델은 깨끗한 답변을 작성합니다 زیرا 그것은 오직 하나의 버전만 본다. 사용자에게 갈등을 드러내고 싶다면, 자신감이 드는 문단 안에 흩어진 문장으로 하지 말고 별도의 "참고로" 패널로 하세요.
사례 3: 최신 정보에 민감한 답변
"현재 환불 정책은 무엇인가요?" 코퍼스에는 지난 네 년 동안의 정책의 모든 버전이 포함되어 있습니다. 긴 맥락은 모두를 읽고 빈도나 위치에 따라 가중치를 부여하지만, 둘 다 진실과 상관 관계가 없습니다. 2022년 버전은 가장 오랫동안 남아 있었기 때문에 두 번 언급됩니다. 모델은 이에 의존합니다.
메타데이터 필터링은 검색 원시형입니다.WHERE doc_type = 'policy' AND status = 'current' ORDER BY updated_at DESC LIMIT 1. 단일 트랜스포머 전방향 패스 내에서는 동일한 대응물이 없습니다. 모델은 자신의 컨텍스트를 필터링할 수 없습니다; 당신이 필터링해야 합니다. 긴 컨텍스트 지지자들은 당신에게 "그냥 날짜를 시스템 프롬프트에 넣으세요"라고 말할 것입니다. 그것은 하나의 문서에 작동합니다. 코퍼스와 함께, 당신은 다시 검색으로 돌아가지만, 당신은 그것을 이상하게 쓰셨습니다.
사례 4: 주의가 60k 마크를 넘어섰습니다
여기서 RULER 차트가 작용합니다. 4k 토큰에서 95%의 정확도를 얻는 동일한 질문을 256k 토큰에서 물어보세요. 최고의 전장 모델에서 정확도는 60-70%로 떨어집니다. 1M일 때는 기준이 더 낮습니다. 동일한 바늘이지만, 히스테그가 커지고 모델이 더 신뢰할 수 없게 되었습니다.
최근 내가 이야기한 팀은 내부 문서와 함께 이것의 자체 버전을 실행했습니다. 그들은 400k 토큰 기술 사양 덤프에 단일 줄을 넣었습니다: "청구 웹훅의 재시도 예산은 5번입니다." 그들은 모델에게 "청구 웹훅은 몇 번 재시도를 받는가"라는 문장의 50가지 다른 변형을 요청했습니다. 매번 새로운 프롬프트마다 정확도는 42%였습니다. 동일한 질문이 동일한 청크를 검색기가 가져온 것에 대해 점수는 96%였습니다. 모델은 더 짧은 프롬프트에서 더 어둡지 않았습니다. 그저 줄을 찾을 필요가 없어졌을 뿐입니다.
5번 사례: 스펀-그라운드 인용 요구 사항
준수는 말합니다: "모델이 주장을 기반으로 한 문장은 어떤 문서에서 왔는지 보여줘." 긴 텍스트는 인용할 수 있습니다. 그러나 그가 인용한 곳을 신뢰할 수 있지 않습니다. "어떤 문서와 어떤 페이지"를 묻으면 모델은 입력에서 출처를 추적하도록 강제되지 않았기 때문에 가능해 보이는 페이지 번호를 가상합니다.
검색은 출처를 무료로 제공합니다. 모든 청크에는doc_id، page، offset، bbox은 모델이 답변을 작성하고, 당신의 후처리 레이어는 각 인용된 주장에 원본 범위를 첨부하고, 감사 로그는 규제자가 추적할 수 있는 내용을 가지고 있습니다. 긴 컨텍스트에서는 모델의 출력에서 검색을 다시 실행하여 인용을 채우거나(처음부터 RAG를 구축했을 것입니다), "우리가 만들어낸 인용이 있는 AI 도구"를 배포하게 됩니다. 그런 것을 배포하지 마세요.
6번 사례: PDF 내에서 구조화된 표 조회
사용자가 질문: "2024년 3분기 순수익은 얼마였습니까?" 답변은 재무 보고서 PDF의 한 셀에 있습니다. 긴 맥락은 PDF를 토큰 스트림으로 읽고 표 레이아웃이 혼란스러워집니다. 인접한 열의 숫자가 잘못된 행에 할당됩니다. 모델은 한 열씩 잘못된 값을 반환하는 가능성이 있는 숫자를 반환합니다.
수정 사항은 수용 중에 레이아웃 민감한 추출입니다: 테이블을 감지하고, 각 행을 구조화된 레코드로 변환하고, 열 헤더와 함께 레코드를 컨텍스트로 포함하고, 올바른 행을 검색합니다. 검색 단계는 벡터 기반일 필요가 없습니다. 추출된 레코드에 대한 SQL 필터는 이 쿼리 형태에 대해 벡터 검색과 긴 컨텍스트를 모두 뛰어넘습니다.
긴 컨텍스트가 실제로 이긴 3가지 경우
모든 것의 답은 검색이 아닙니다. 세 가지 모양이 다른 방향으로 뒤집힙니다.
단문 요약. "이 300페이지 계약서를 요약해라." 검색을 할 필요가 없습니다. 사용자는 이미 하나의 문서를 주면서 검색을 마쳤습니다. 요약을 청크링하고 재조립하는 것은 모델이 전체를 볼 때 무료로 얻는 교차면 일관성을 잃어버립니다.
고정된 작업 세트에 대한 대화적 추적. 사용자가 10분 안에 세 가지 문서를 업로드하고 20개의 질문을 하고, 각 턴마다 검색을 다시 실행하면 지연 시간이 추가되고 유사한 질문에 대해 다른 청크를 가져오는 위험(사용자가 발견하는 불일치)이 있습니다. 작업 세트를 맥락에 고정하고 접두사를 캐시하고 빠르고 일관된 답변을 제공하세요.
탐색적 "이 전체를 읽고 놀라운 점이 무엇인지 알려줘." 쿼리는 구체적인 대상이 없습니다. 검색에는 쿼리 벡터가 필요합니다. "흥미로운 것은 무엇인가"는 그것을 만들지 못합니다. 긴 맥락은 중간 맥락 인식이 저하되어도 검색기가 관련성을 추측하는 것보다 더 많은 것을 드러낼 것입니다.
설계 문서에 붙일 수 있는 결정 규칙
제품이 처리하는 각 쿼리 유형에 대해 순서대로 따릅니다. 첫 번째 예를 들어 "네"라고 답하면 멈춥니다.
질의가 사실, 숫자, 사람, 또는 섹션과 같은 대상을 지정하는가? 예, 그렇다면 검색. 모델은 이미 히스테리 안을 좁힌 경우 더 빨리 대상을 찾는다.
여러 먼 곳에서 증거를 구성해야 하는가? 예, 그렇다면 검색, 검색 전에 멀티 쿼리 또는 분해를 고려하라. 긴 컨텍스트는 60k을 넘어 멀티 홉 추론을 희미하게 만든다.
코퍼스에 중복이나 모순, 혹은 버전 관리가 있는가? 있다면 리트리버에서 검색하고 중복을 제거하라. 모델은 어떤 입장을 취할 수 없다; 리트리버는 취할 수 있다.
답변이 근거가 필요한가? 감독자나 감사인이 확인할 수 있는 인용문이 필요한가? 있다면 검색하라. 근거는 검색의 결과물이지 생성의 결과물이 아니다.
사용자가 이미 선택한 문서가 작업 세트인가요, 그리고 짧은 세션 동안 많은 질문을 하고 있나요? 예시라면, 긴 컨텍스트와 프리픽스 캐싱을 사용하세요.
요청이 구체적인 목표가 없이 탐색적인가요? 예시라면, 긴 컨텍스트를 사용하세요. 검색에는 쿼리가 필요합니다.
기본값: 검색. 긴 맥락은 특별한 경우이지, 새로운 정상이 아니다. 125x 비용 격차와 중간 맥락 정확도 절벽은 창이 계속 커지기만 해서 사라지지 않는다.
생산 환경에서 가장 심각하게 문제가 되는 여섯 가지 경우 중 어떤 것이 있었고, 더 나은 검색으로 해결했거나 다른 모델을 사용했나요? 댓글에 전쟁 이야기를 남기지 마세요.
이것이 유용했다면
이것은 정신적 모델의 종류입니다RAG 포켓 가이드는 다음과 같은 순서로 작동합니다: 쿼리 모양이 먼저이고, 검색 패턴이 두 번째입니다. 이 책은 청크 처리, 하이브리드 검색, 재정렬, 그리고 이 포스트의 맨 위 표를 만들기 위해 내 표를 믿지 말고 필요한 평가 방법론을 다룹니다. 만약 당신의 팀이 "RAG가 여전히 필요한가요?"라는 대화를 하고 있다면, 쿼리 라우팅과 재현율 대 정밀도 트레이드오프에 대한 장을 먼저 읽어야 합니다.
