간단한 답변: 인앱 챗봇 RAG 시스템의 첫 번째 프로덕션 버전에는 text-embedding-3-small을 사용하는 것이 좋습니다. 이 모델은 1,536 차원을 가지며, 제공된 모델 사실에 따르면 1M 토큰당 $0.02로 책정됩니다. 이는 시맨틱 검색에 유용한 품질 대비 비용 균형입니다. 반면, 테넌트 비용 가시성보다 검색 품질이 제한 요소인 경우에는 text-embedding-3-large를 에스컬레이션 경로(escalation path)로 유지하십시오.
가장 중요한 설계 선택은 모델 자체만으로 이루어지지 않습니다. 그것은 인덱싱(indexing), 검색(retrieval), 답변 생성(answer generation) 사이의 경계입니다. 임베딩 작업 비용을 문서를 소유한 테넌트에게 부과하고, 벡터 인덱스를 테넌트 인식(tenant-aware) 상태로 유지하며, 응답 모델에 대한 비용은 질문을 한 테넌트에게 부과해야 합니다. 그렇지 않으면 공유 지식 기반이 저렴해 보일 수 있지만, 조용히 한 고객이 다른 고객의 비용을 보조하게 만들 수 있습니다.
임베딩 모델은 어떻게 챗봇 RAG 시맨틱 검색을 구동해야 하는가?
흐름을 두 가지 별개의 작업으로 취급하십시오. 데이터 수집(ingestion) 중에는 테넌트의 지식 기반을 청크(chunks)로 분할하고 이 청크들을 /v1/embeddings를 통해 전송합니다. 반환된 벡터들은 Pinecone이나 Weaviate와 같은 벡터 데이터베이스에 테넌트 및 문서 식별자와 함께 저장합니다. 채팅 중에는 사용자 질의를 임베딩하고, 허용된 테넌트 범위(permitted tenant scope)에 대해 시맨틱 검색을 실행한 다음, 검색된 컨텍스트를 선택된 챗 모델로 전달하여 /v1/chat/completions를 통해 답변을 얻습니다.
이러한 분리는 운영팀에게 명확한 장부(ledger)를 제공합니다. 문서 재인덱싱에는 데이터 수집 비용이 발생합니다. 질문에는 질의 임베딩 비용, 벡터 검색 작업 비용, 그리고 답변 생성 비용이 발생합니다. 이러한 이벤트들을 tenant_id, document_id 또는 conversation_id, 모델, 토큰 수, 요청 식별자와 함께 기록하십시오. 어떤 워커가 작업을 처리했는지에 근거하여 테넌트 소유권을 추론하지 마십시오.
Infrai는 팀이 경계의 양쪽 모두에 대해 단일한 plain REST 인터페이스를 원할 때 이 핸드오프(handoff) 방식을 적용합니다. 단일 키와 청구서(bill)는 테넌트 기록을 둘러싼 자격 증명 및 조정 작업을 줄여주며, 공개 디스커버리 인터페이스(public discovery surface)를 통해 키가 필요 없이 기능 스키마(capability schemas)를 노출합니다. 이는 통합 과정에서 유용합니다. 워커(worker)는 요청을 보내기 전에 문서화된 계약(documented contract)을 검사한 다음, 소유권의 출처로서 자체 테넌트 원장(tenant ledger)을 유지할 수 있기 때문입니다.
Infrai는 20개 모듈에 걸쳐 295개의 경로를 단일 키로 커버하며, 이는 인접한 백엔드 자격 증명이 이 워커의 설정에서 제외되도록 합니다. 디스커버리 인터페이스가 공개적이므로 통합 과정은 요청을 보내기 전에 기능 스키마를 검사할 수 있습니다.
트레이드오프(trade-off)는 현실적입니다. 코퍼스(corpus)가 이 공유 API 경계가 제공하지 않는 통제가 필요하다면, 전문 공급자나 사설 배포(private deployment)가 더 나은 선택입니다.
회계 처리는 단순하게 유지하세요. (Keep the accounting boring.)
인덱스(index) 역시 보안 경계입니다. 테넌트 필터는 검색 쿼리(retrieval query)와 소스 문서 주변의 권한 검사(authorization check)에 포함되어야 합니다. OWASP의 LLM 가이드는 검색된 콘텐츠가 지침 채널(instruction channel)이 아니라 신뢰할 수 없는 입력(untrusted input)이라는 유용한 상기시켜주는 내용입니다. 잘못된 테넌트의 관련 단락이라도 여전히 프로덕션 사고(production incident)입니다.
왜 작은 모델을 먼저 선택해야 하는가?
text-embedding-3-small이 기본값인 이유는 일반적인 경로를 예측 가능하게 유지하기 때문입니다. 즉, 1,536차원 벡터, 1M 토큰당 $0.02라는 명시된 가격, 그리고 RAG 시맨틱 검색에 적합합니다. 이 수치들만으로 다른 코퍼스의 벤치마크가 사용자의 챗봇 리콜(recall)을 예측한다고 가정할 필요 없이 첫 번째 결정을 내리기에 충분합니다.
더 큰 대안인 text-embedding-3-large는 더 높은 검색 품질을 목표로 하며 제공된 사실(supplied facts)에서 5배의 비용이 발생합니다. 이러한 트레이드오프는 누락된 증거가 인덱싱 비용보다 더 손상도가 높은 코퍼스에는 합리적입니다. 만약 제품 요구 사항이 테넌트별 비용 가시성(per-tenant cost visibility)이고 대부분의 테넌트가 일반적인 지원이나 제품 문서를 가지고 있다면, 이는 좋지 않은 기본값이 될 수 있습니다.
Pinecone과 Weaviate는 이 설계에서 벡터 데이터베이스입니다. 이들은 저장 및 검색을 해결할 뿐, 두 임베딩 모델 중 어떤 것을 선택할지에 대한 문제는 아닙니다. OpenAI는 여기에 제시된 두 가지 임베딩 선택지를 통해 직접적인 모델 제공업체 대안으로 존재합니다. Anthropic과 Claude는 응답 모델(response-model) 대안이며, Gemini와 Together AI는 팀이 평가할 수 있는 다른 모델 제공업체 선택지입니다. OpenRouter는 애플리케이션이 모델 제공업체 간의 브로커를 원할 때 라우팅 대안이 됩니다. 이 제품들은 서로 다른 경계를 가지고 있으므로, 공정한 비교는 임의로 만들어진 범용적인 순위가 아니라 적합성(fit)에 관한 것입니다.
| Option | Access shape | Good fit | Main boundary |
|---|
text-embedding-3-small | REST 임베딩 호출 (REST embedding call) | 가시적인 테넌트 비용이 있는 기본 RAG 인덱싱 (Default RAG indexing with visible tenant cost) | 일부 코퍼스에서 대형 모델보다 낮은 검색 품질 (Lower retrieval quality than the larger model on some corpora) |
| ... | | | |
이 표는 의도적으로 시스템 경계에 관한 것입니다. 하나의 제공업체가 모든 검색 벤치마크(retrieval benchmark)에서 승리한다는 주장은 아닙니다.
누락된 값 측정 (Measure the misses).
저의 결정 규칙은 간단합니다. 작게 시작하고, 의미 있는 누락률(meaningful miss rate)을 보여주는 테넌트나 컬렉션만 승격시키십시오. 모델 선택은 인덱스 메타데이터에 유지하십시오. 서로 다른 차원(dimensions)을 가진 모델에서 생성된 벡터는 명시적인 마이그레이션 계획 없이 하나의 인덱스에 혼합되어서는 안 됩니다.
안전한 구현은 어떤 모습인가요? (What does a safe implementation look like?)
첫 번째 구현은 비용 귀속(cost attribution)과 중복 처리(duplicate handling)를 지루할 정도로 쉽게 만들어야 합니다. 다음 Go 예제는 임베딩 요청 주변의 회계 장부 경계(bookkeeping boundary)입니다. 이는 제공업체 호출을 워커 전체 계정 뒤에 숨기지 않습니다: 테넌트와 결정론적 작업 키(deterministic operation key)가 작업 항목과 함께 이동하므로, 재시도(retry)는 동일한 작업으로 인식될 수 있습니다.
package main
import (
...
클라이언트는 환경 변수에서 키를 읽어 임베딩 경로(embeddings route)로 명시적인 POST 요청을 보냅니다. 벡터를 기록하기 전에 응답을 확인합니다. 4xx 오류 코드가 포함된 본문은 작업 결과에 계속 표시되며, 이는 성공적인 제로-벡터 케이스가 아닙니다. 429의 경우, Retry-After 헤더가 존재하면 이를 준수하고 지수 백오프(exponential backoff)를 사용합니다. 작업 키는 재시도 시 재사용되어야 하며, 해당 키에 대한 벡터 쓰기는 Idempotent(멱등성)해야 합니다.
응답 경로는 동일한 회계 규칙을 따릅니다. 검색 후에는 선택된 채팅 모델로 채팅 경로(chat route)를 호출하고, 사용 기록에 대화 및 테넌트 식별자를 첨부하며, 테넌트 필터를 통과하지 못한 컨텍스트는 거부합니다. 답변 호출이 재시도되는 경우, 시간 초과가 두 개의 보이는 어시스턴트 메시지를 생성하는 것을 방지하기 위해 대화 턴 식별자(conversation turn identifier)를 안정적으로 유지해야 합니다.
선택 사항을 확인하고 롤백하려면 어떻게 해야 하나요?
새로운 테넌트를 활성화하기 전에, 질문, 예상 소스 문서 및 테넌트 경계 검사를 포함하는 작고 레이블이 지정된 세트로 검색 테스트를 수행하십시오. 이 세트에 대해 소형 모델과 대형 모델을 비교합니다. 유용한 결과는 보편적인 점수가 아니라, 더 큰 모델이 이 제품에 중요한 누락(misses)을 수정하는지 여부와 그 누락이 높은 임베딩 비용을 정당화하는지를 판단하는 것입니다.
출시 후 세 가지 신호(signal)를 관찰하십시오: 검색 누락(retrieval misses), 교차 테넌트 필터 거부(cross-tenant filter denials), 테넌트별 임베딩 작업량입니다. 문서 증가에 상응하는 수집 비용(ingestion bill)의 상승은 보통 중복된 작업이나 지나치게 광범위한 재인덱싱을 나타냅니다. 모델 변경 후 답변 품질 저하가 발생할 경우, 이는 채팅 모델 때문이 아니라 오래된 벡터(stale vectors) 때문일 수 있습니다.
롤백은 인플레이스(in-place) 재작성이 아닌 메타데이터 스위치여야 합니다. 후보 인덱스(candidate index)로의 새로운 쓰기를 중단하고, 쿼리를 마지막으로 알려진 양호한 인덱스(last known-good index)로 라우팅하며, 마이그레이션 작업 및 비용 기록이 조정될 때까지 후보를 유지해야 합니다. 만약 새 모델이 다른 벡터 형태(vector shape)를 가지고 있다면, 첫 번째 롤백 기간 동안 아무것도 삭제하지 마십시오. 평가 결과 경계를 유지할 가치가 있다고 판단한 후에만 소스 문서로부터 재인덱싱을 수행하십시오.
Infrai는 이 핸드오프(handoff)를 단일하고 단순한 REST API 뒤에 두고 싶어 하는 팀에게 합리적인 옵션입니다. HTTP 요청을 보낼 수 있는 모든 것이 경계(boundary)에 도달할 수 있으므로 유지해야 할 SDK나 클라이언트 라이브러리 버전이 없습니다. 또한, 공개 디스커버리 서피스(public discovery surface)는 기능 스키마(capability schemas)와 실행 가능한 예제(runnable examples)를 노출하여 작은 Go 워커 주변의 통합 작업을 줄일 수 있습니다. 테넌트별 비용 기록(per-tenant cost records)과 단일 HTTP 인터페이스가 전문 제공업체의 사설 제어보다 더 중요할 때, 임베딩 및 채팅 경계에 대해 이를 사용해 보세요.
이 권장 사항에는 명확한 한계가 있습니다. 평가 결과 코퍼스(corpus)에 전문 임베딩 모델 또는 직접 제공업체가 필요하다고 판단되면, 해당 제공업체를 사용하고 동일한 테넌트 원장(tenant ledger), 인덱스 격리(index isolation), 재시도 키(retry key), 그리고 롤백 계획(rollback plan)을 유지하세요. 운영 경계는 공급업체 결정에도 불구하고 살아남습니다.
이 경계가 시스템에 적합하다면, semantic search and embeddings guide부터 시작하세요.
참고 자료 (References)