1. 아키텍처를 올바르게 잡기: 2단계 검색
Reranking은 독립적인 검색 방법이 아닙니다. 파이프라인의 두 번째 단계입니다.1
Recall
전체 말뭉치에서 후보 집합을 가져오기 위해 벡터 검색 또는 BM25를 사용합니다. 이 단계는 반드시
빠라야 하며, 넉넉히 가져와야 합니다: 목표는 “답이 이 안 어딘가에 있습니다”이지
“답이 맨 앞에 있습니다”가 아닙니다.
2
Rerank
후보 집합과 쿼리를
bge-reranker-v2-m3에 보내 점수를 매기고 다시 정렬합니다.
이 단계는 반드시 정확해야 합니다: 목표는 올바른 답을 맨 위로 올리는 것입니다.3
잘라서 LLM에 전달하기
다시 순위가 매겨진 상위 3~5개를 프롬프트에 넣습니다. 이 과정이 더 정밀할수록 모델의
환각은 줄고, 지불하는 컨텍스트 비용도 줄어듭니다.
Recall과 rerank를 모두 건너뛸 수 없는 이유: 크로스 인코더는 계산을 시작하기 전에 쿼리가 필요하므로,
오프라인에서 미리 계산할 수 있는 것이 없습니다. 수백만 개의 문서를 하나씩 점수화하는 것은 비용과 지연 시간
모두에서 감당할 수 없습니다. Recall은 수백만 개를 수백 개로 줄여 주고, reranking은 그 수백 개를
올바르게 정렬합니다.
완전한 동작 예제
이것은 최소이지만 완전한 2단계 리트리버입니다 — Recall에는text-embedding-3-small, reranking에는 bge-reranker-v2-m3를 사용하며, 둘 다 동일한 APIYI token을 통해 처리합니다:
2. 몇 개의 후보를 회수해야 합니까?
측정된 지연 시간(짧은 문서, 각 단계당 5회 실행의 P50):
중요한 점은 약 2초의 고정 오버헤드입니다. 문서가 1개뿐이어도 2초가 듭니다. 후보를 1개에서 100개로 늘려도 1.8초만 추가되며, 검색 품질 향상은 그보다 훨씬 더 큰 가치가 있습니다.
지연 시간을 실제로 좌우하는 것은 문서 수가 아니라 총 token입니다. 동일한 50개 후보 기준으로 보면:
개수는 같지만 지연 시간은 4.7배입니다. 이것이 다음 섹션의 청킹이 검색 속도를 늦추지 않는 이유이기도 합니다 — 청킹은 총 token을 늘리지 않으면서 문서 수를 늘립니다.
정말로 많은 문서를 순위화해야 한다면(예: 오프라인 배치 작업), 동시 실행 수를 4로 제한한 상태에서 여러 개의 ≤100문서 요청으로 분할하십시오. 분할한다고 총 token이 줄어드는 것은 아닙니다 — TPM 20,000이 여전히 전체 관문이므로, 배치 작업에는 분당 제한 속도가 필요합니다. 해당 쿼터는 확장 중이며, 대규모 배치 워크로드라면 먼저 APIYI 지원팀에 현재 사용할 수 있는 여유분을 확인하는 것이 좋습니다.
3. 긴 문서 청크로 나누기
이것은 가장 효과가 큰 전처리 단계입니다. 이유는 두 가지 측정값이 설명합니다. 첫째, 관련 없는 내용은 관련성을 희석합니다. 같은 일치 문장에 서로 다른 양의 군더더기를 덧붙이면:
둘째, 길이는 잡음 점수를 부풀립니다. 같은 관련 없는 문서는 짧을 때 0.029였고, 450문자의 군더더기를 더한 뒤에는 0.121이 되어 4배 높아졌습니다.
종합하면: 답이 끝에 있는 긴 문서는 완전히 주제에서 벗어난 긴 문서에 밀립니다.
4. 임계값 설정(0.5만 고르지 마십시오)
relevance_score는 sigmoid로 0–1 범위에 매핑되므로 신뢰도 값처럼 보입니다. 그렇지 않습니다.
전체 품질 테스트 사례에서 측정한 분포는 다음과 같습니다.
고정된 0.5 임계값은 모든 올바른 교차 언어 결과를 제외하고, 비중국어 언어에서 두 번째로 높은 적중 대부분도 제외하는 반면, “Apple Inc. FY2024 revenue”의 경우 사과 재배 가격에 대한 문서가 0.945점을 받아 3위에 올랐습니다.
마지막 행에 주목하십시오. 가장 높은 점수의 무관한 문서(0.945)가 가장 낮은 점수의 관련 있는 문서(0.289)보다 높습니다. 두 분포는 겹칩니다. 바로 그 때문에 안전한 절대 임계값은 존재하지 않습니다.
5. 부정에는 안전장치가 필요합니다
이것은 이 모델의 분명한 약점입니다. “겨울에 가기 좋은 관광지는 어디입니까?”라는 질문에서, 두 문서는 자신들이 아니라고 명시적으로 말했는데도 2위와 3위에 랭크되어, 정말 관련 있는 결과가 4위와 5위로 밀려났습니다. nDCG@3는 0.47이었습니다. 모델은 “겨울 + 관광지 + 여행”이라는 주제에만 맞췄고, 부정을 전혀 처리하지 못했습니다. 해결책: reranking 뒤에 가벼운 LLM 검증 단계를 추가하십시오. 저렴한 소형 모델이면 충분합니다:6. 다국어 및 교차 언어 사용
중국어, 영어, 일본어, 한국어, 러시아어, 프랑스어, 아랍어 — 그리고 ZH↔EN 교차 언어 검색까지 — 모두 테스트에서 정확한 순서로 정렬됩니다. 하나의 모델로 다국어 지식 베이스를 커버하므로, 언어별 배포가 필요하지 않습니다. 하지만 점수 크기에는 주의해야 합니다:
교차 언어의 정답은 1~2자릿수 정도 더 낮은 점수를 받지만 — 순서는 여전히 유지됩니다.
7. 동시 실행 수, 캐싱 및 멱등성
먼저 쿼터를 예산으로 잡고, 그다음 동시 실행 수를 논의합니다
상위(Huawei Cloud MaaS)는 이 모델에 대해 TPM 20,000 / RPM 120을 허용합니다. 이것은 사람들이 가장 자주 과소평가하는 제약입니다. 같은 플랫폼의 BGE-M3 embedding model은 TPM 1,200,000을 제공하므로 60배 더 많습니다. 테스트는(각 케이스마다 쿼터 윈도우가 초기화되도록 70초간 무응답을 둠) 두 개의 독립적인 메커니즘을 분리해 보여줍니다:
발견 1: 대략 4~5개의 동시 진행 슬롯입니다. R1/R2는 TPM의 3
분당 검색 수
측정된≈26.9 tokens/document를 사용하면:
후보 수는 품질 결정이기도 하지만 용량 결정이기도 합니다: 후보를 두 배로 늘리면 품질 이득은 제한적인 반면 처리량은 절반으로 줄어듭니다.
또한 단일 요청에 후보를 너무 많이 담을 수 없는 이유도 설명합니다. 후보 1000개는 26,867 token으로, **한 번의 호출에 해당 분 전체 예산의 134%**이므로 429가 확정입니다. 2000개면 269%입니다.
쿼터 확대가 진행 중입니다. 위의 TPM 20,000은 상위의 초기 할당량이며,
APIYI는 이미 상향 조정을 신청했습니다. 워크로드가 표에서 허용하는 범위를 초과한다면,
현재 수치에 맞추어 설계를 축소하기보다는 APIYI 지원팀에 문의해 상위 쿼터 재검토를 요청하십시오
.
캐싱
동일한 요청을 10번 반복하면 비트 단위로 동일합니다(드리프트 0). 드리프트 ~3.7e-4는 후보 순서를 섞을 때만 나타나며(bf16 배칭 지터), 순서는 영향을 받지 않습니다. 따라서 결과는 캐시해도 안전합니다:normalised query + ordered hash of document contents를 키로 사용합니다relevance_score자체를 멱등성 또는 중복 제거 키로 사용하지 마십시오 — 후보 순서를 바꾸면 마지막 자릿수가 변합니다- 반복 쿼리(FAQ, 인기 검색)는 보통 잘 캐시되어 지연 시간과 상위 부하를 모두 줄입니다
8. 기존 프레임워크와의 통합
파라미터 이름은 Cohere Rerank v1(query / documents / top_n / return_documents)와 일치하지만, documents는 문자열 배열만 허용합니다 — [{"text": "..."}]는 400을 반환합니다 — 그리고 응답에는 id / meta 필드가 없습니다.
9. 출시 전 체크리스트
정확성
정확성
-
results[].index를 통해 역매핑하며, 텍스트를 일치시켜서 하지 않음 - 긴 문서는 200–500자 단위로 분할하고 최적 청크 점수 기준으로 집계함
- 단일 쿼리-문서 쌍이 8192 tokens를 초과하지 않음
- 부정 또는 제외가 포함된 쿼리는 LLM 검증 단계를 거침
신뢰성
신뢰성
- 후보 집합은 100개로 상한을 둠
- 동시 실행 수는 4로 상한을 둠 (측정 결과: 상위 시스템은 약 4–5개의 in-flight 요청까지 허용하며, 초과분은 대기열에 쌓이지 않고 즉시 거부됨)
- 피크 처리량이 TPM 20,000 기준으로 점검됨 (~100개 후보에서 분당 약 15회 검색) 그리고 충분함이 확인됨
- 429에 대한 백오프 재시도 구현됨 (상위 시스템의 혼잡은 일시적임)
- 타임아웃이 60초 이상으로 설정됨 (짧은 문서 100개는 P95에서 약 4.3초이지만, 긴 문서나 큰 집합은 수십 초에 도달함)
- 요청 경로가
/v1/rerank로 확인됨 — 잘못된 경로는 404가 아니라 200 + HTML을 반환함 - 모델 이름이 정확하고 소문자로 표기됨 — 오타는 503을 반환하며, 쉽게 장애로 오인될 수 있음
품질
품질
- 필터링은 추정된 고정값이 아니라 Top-N 또는 상대 임계값을 사용함
- 다국어 및 교차 언어 점수 크기를 검증하여 낮은 점수가 필터링되지 않도록 함
- 소규모 라벨링된 쿼리 세트로 A/B 테스트를 수행하여 (rerank 켬 대 끔) 지표가 실제로 움직였는지 확인함
비용 및 캐싱
비용 및 캐싱
-
usage.input_tokens/output_tokens는 항상 0임을 인지함 —prompt_tokens/total_tokens를 읽어야 함 -
top_n도return_documents도 사용량을 줄이지 않음을 인지함 — 모든 후보가 점수화됨 - 콘솔 청구서를 기준으로 비용을 집계함 (100개 후보에서
prompt_tokens와total_tokens는 약 45% 차이가 나며, 이번 라운드에서는 어느 쪽이 과금되는지 확인할 수 없었음) - 자주 사용하는 쿼리에 대한 결과 캐싱이 적용됨