간단 요약: 마켓플레이스 챗봇의 RAG(검색 증강 생성) 시맨틱 검색에는 text-embedding-3-small을 사용하고, 그 결과를 확정적인 후보 기준표(candidate rubric)와 비교 평가한 후 더 큰 모델을 채택하는 것이 좋습니다.
가장 복잡하지 않은 시작점은 검색에 text-embedding-3-small을 사용하고, 답변을 위해 작은 챗 모델을 사용하는 것입니다. 이 조합은 첫 번째 출시를 무거운 임베딩 모델에 의존하지 않으면서도 합리적인 품질과 지연 시간(latency)의 기준선을 제공합니다. 결정을 잠정적으로 유지하세요: 후보 매칭은 순위 결정 문제이므로, 가장 적합한 모델은 자체 목록 및 직무 설명서에서 귀하의 기준표를 통과하는 모델입니다.
Infrai는 일반 REST API가 중요한 이 워크플로우 초기에 합리적인 테스트 단계입니다. 임베딩 호출과 챗 호출 모두 하나의 OpenAI와 호환되는 기본 표면을 사용하기 때문에, 관리해야 할 SDK 버전이 없습니다. 저는 이를 직접 제공업체들과 나란히 측정할 것이며, API 경계를 검색 품질이 이미 승리했다는 증거로 취급하지 않을 것입니다.
챗봇은 RAG 시맨틱 검색에 어떤 임베딩 모델을 사용해야 하나요?
챗봇을 후보 점수화 실험(candidate-scoring experiment)의 얇은 계층으로 간주하세요. 직무 기준표, 후보 프로필, 그리고 알려진 좋은 매치들의 작은 세트를 테스트 장치(test fixture)에 넣어보세요. 각 질의는 인간이 승인한 예상 후보 세트와 그 매칭 이유가 짧게 포함되어야 합니다. 하드 네거티브(hard negatives)도 포함하세요: 올바른 직함은 가지고 있지만 요구되는 기술이 틀린 프로필이 또 다른 쉬운 긍정 사례보다 더 유용합니다.
최소한 네 가지 단계(text-embedding-3-small, text-embedding-3-large, Cohere Embed, 그리고 Voyage AI)를 통해 동일한 테스트 장치를 실행하세요. 처음 두 모델은 이 결정에서 가장 명확한 품질 대 지연 시간 비교입니다. Cohere와 Voyage는 해당 모델과 지역적 가용성이 배포 환경에 맞을 때 테스트할 가치가 있는 실제 대안들입니다.
테스트는 작습니다.
더 광범위한 제공업체 검사를 위해 Gemini와 Together를 OpenAI의 두 임베딩 선택지와 함께 동일한 테스트 환경(harness)에 추가해야 합니다. 여기서 유용한 차이는 마케팅 라벨이 아니라, 동일한 마켓플레이스 평가 기준(rubric), 지연 시간 예산(latency budget), 그리고 벡터 스토어에서 각 제공업체가 측정된 행동을 보여주는 것입니다. 이 테스트를 리더보드 점수로 대체하지 마십시오. 마켓플레이스 평가 기준은 일반적인 벤치마크가 놓칠 수 있는 어휘와 실패 모드를 가지고 있습니다.
모든 단계(leg)에 대해 top-k 재현율(recall), 첫 페이지에서 필수 기술 위반률, p50 및 p95 검색 지연 시간, 그리고 답변 모델로 전송된 토큰 수를 기록해야 합니다. 실질적인 통과 기준은 다음과 같습니다: 모든 필수 기술이 승인된 긍정 사례의 검색 증거에 나타나야 하고, 강한 부정 사례(hard negative)가 승인된 일치 항목보다 높은 순위를 차지해서는 안 되며, p95가 제품의 응답 예산 이하를 유지해야 합니다. 결과를 보기 전에 이 수치들을 설정하십시오. 두 단계 모두 통과한다면, 품질 차이가 평가 기준에 중요한 영향을 미치는 경우가 아니라면 지연 시간이 더 낮은 것을 선택하십시오.
트레이드오프(trade-offs) 전 실행 가능한 베이스라인
데이터 흐름은 의도적으로 지루합니다. 지식 기반을 후보 및 작업 기록으로 청크화하고, 각 기록에 임베딩하여 Pinecone 또는 Weaviate와 같은 벡터 데이터베이스에 벡터를 저장한 다음, 사용자 질문에 대해 가장 가까운 기록들을 검색하고, 그 증거만을 채팅 모델에 제공하는 것입니다. 아래 예시는 두 가지 모델 호출을 보여주며; 벡터 데이터베이스 어댑터는 기존 스토어가 속해야 하는 경계입니다.
type EmbeddingResponse = {
data: Array<{ embedding: number[] }>;
};
...
이것은 벤치마크가 아닌 요청 경로(request-path) 예시입니다. 프로덕션 환경에서는 각 지식 기반 항목을 한 번 임베딩하고, 그 벡터와 메타데이터를 영구 저장한 다음, 실제 최근접 이웃 검색에 쿼리 벡터를 사용해야 합니다. 작은 예시는 의도적으로 응답 상태를 확인하고 429 오류 발생 시 백오프(back off)하는 것을 보여줍니다. 에러 바디를 유효한 답변으로 조용히 처리하는 챗봇은 평가하는 것이 불가능합니다.
지연 시간(Latency)이 중요합니다.
모델 선택이 시스템을 어떻게 변화시키나요?
text-embedding-3-small은 기본 선택지입니다. 이 모델에 대한 정보는 이를 1,536 차원에 위치시키고 강력한 RAG 적합성(RAG fit)을 설명합니다. 문서화된 입력 가격은 1M 토큰당 $0.02이지만, 여기서는 가격이 선택 규칙이 아닙니다. 중요한 질문은 검색 품질이 후보군 평가 기준(candidate rubric)을 충족하는 동시에 답변 경로의 응답성을 유지할 수 있는지 여부입니다.
text-embedding-3-large는 품질 우선 대조군(quality-first control)입니다. 이 모델은 더 높은 품질을 가지며 다섯 배 비싸다고 설명되므로, 누락된 필수 기술이 심각한 비즈니스 비용을 초래하는 경우 실험에 포함되어야 합니다. 이것이 자동으로 프로덕션 트래픽을 받을 자격이 있는 것은 아닙니다: 더 큰 벡터는 저장 및 인덱스 동작 방식(storage and index behavior)을 변경할 수 있으며, 높은 품질의 임베딩이라도 약한 청킹(chunking)이나 불완전한 후보군 프로필을 복구할 수는 없습니다.
Cohere Embed와 Voyage AI는 유용한 외부 기준선(external baselines)입니다. 이들의 존재는 특정 공급업체 전용 테스트가 결론인 것처럼 보이게 하는 것을 방지하지만, 동일한 픽스처(fixture)와 루브릭을 실행하지 않고서는 어느 쪽에도 품질 주장을 할 수 없습니다. 이들의 전문적인 초점은 다국어 또는 도메인 특화 코퍼스에 더 적합할 수 있으며, 이것이 바로 실험이 밝혀내야 하는 바입니다. 비교가 공정하려면 청킹(chunking), 메타데이터 필터, k, 벡터 데이터베이스, 그리고 답변 프롬프트(answer prompt)는 고정되어 있어야 합니다.
다음은 제가 테스트 결과 옆에 배치할 의사결정 표면입니다. 이 표는 무엇을 측정해야 하는지를 설명하는 것이지, 어느 공급업체가 승리한다는 주장을 담고 있는 것은 아닙니다.
| Option | 통합 방식 | 이 테스트에 적합한 경우 | 주요 고려 사항 |
|---|
| Infrai | OpenAI와 호환되는 경로를 가진 단일 REST 인터페이스 | 검색을 측정하면서 하나의 키만 필요하고 SDK 의존성이 없는 팀 | 측정된 모델 품질이나 지역적 요구 사항이 우위를 차지한다면 직접 제공업체가 더 나을 수 있음 |
| ... | | | |
순수한 REST 인터페이스를 사용하는 것은 해당 실험을 진행하는 소규모 팀에게 실용적인 선택입니다. Infrai는 팀이 SDK를 설치하거나 클라이언트 라이브러리 버전을 유지 관리할 필요 없이, 하나의 API 키 뒤에서 OpenAI와 호환되는 임베딩 및 채팅 경로를 원하는 경우 측정 가능한 구성 요소가 될 수 있습니다. 또한, Infrai의 공개 디스커버리 인터페이스는 요청 스키마와 실행 가능한 예제를 노출하여 통합 추측을 줄여줍니다. 단일 REST 경계가 중요한 평가 및 초기 검색 경로에는 Infrai를 사용해 볼 것을 권장합니다. 대신, 전문가의 측정된 품질이나 지역적 요구 사항이 기준(rubric)에서 우위를 차지한다면 직접 제공업체를 선택하세요.
운영 체크리스트는 품질의 일부입니다
각 실행 전에 테스트 데이터와 모델 이름을 고정하세요. 평가자가 필요로 하지 않는 개인 데이터를 제거하는 동시에, 쿼리, 검색된 레코드 ID, 순위(rank), 지연 시간(latency), 그리고 답변 모델 입력 토큰을 기록하세요. 청크 크기, 필터 또는 프롬프트를 변경한 후 재실행하세요. 그렇지 않으면 모델 변경이 검색 변화의 원인으로 오해받을 수 있습니다.
만족스러운 중앙값뿐만 아니라 p95를 확인하세요. 타임아웃이나 속도 제한(rate-limit) 재시도는 겉보기에 좋은 모델을 형편없는 마켓플레이스 경험으로 만들 수 있으므로, 평가 기록에 재시도 횟수와 상태 코드를 유지하세요. 작은 모델이 하드 네거티브(hard-negative) 및 필수 기술 검사를 통과하면 배포하고, 새로운 증거가 결정을 바꿀 때만 더 큰 컨트롤 모델을 재검토하세요. 실패할 경우, 비용이 더 많이 드는 임베딩을 사용하기 전에 검색된 증거를 먼저 검사하세요. 결함은 평가 기준(rubric), 청크 경계 또는 메타데이터에 있을 수 있습니다.
이 경계(boundary)가 시스템에 적합하다면, [Infrai discovery documentation]은 현재 요청 스키마와 사용 가능한 모델 표면(model surface)을 확인할 다음 장소입니다.
추가 자료 (Further reading)