기업용 LLM 모델 선택 매트릭스: Claude·OpenAI·Gemini·오픈소스 모델 비교 기준
결론부터 말하면, 기업용 LLM 선택의 정답은 Claude, OpenAI, Gemini, 오픈소스 중 하나를 고르는 일이 아닙니다. 업무별로 품질 목표, 월 토큰 예산, 허용 지연 시간, 데이터 민감도, 장애 시 대체 경로를 먼저 정한 뒤 ‘어떤 요청을 어떤 모델에 보낼지’ 설계해야 합니다. 고객 상담 챗봇, 사내 문서 검색, 자동 보고서, 관리자 업무 자동화는 같은 AI 기능처럼 보이지만 실패 비용과 보안 조건이 다릅니다.

실서비스의 LLM 선택은 모델명 비교표가 아니라 운영 설계 문제입니다. 데모에서 가장 답을 잘한 모델이 실제 서비스에서 가장 좋은 모델은 아닐 수 있습니다.
2026년 7월 기준 주요 벤더의 API, 데이터 보관, 프롬프트 캐싱, 지역 옵션은 계속 바뀌고 있습니다. 그래서 이 글은 특정 모델 버전을 ‘최고’라고 말하지 않습니다. 대신 대표, PM, 마케터, 개발 리더가 견적·보안 검토·PoC·MVP 출시 전에 바로 사용할 수 있는 선택 매트릭스를 제공합니다.
1. 먼저 업무 유형을 나눠야 한다
가장 흔한 실수는 “우리 서비스에 AI 챗봇을 붙이고 싶다”로 시작하는 것입니다. 챗봇 안에도 최소 네 가지 다른 업무가 섞입니다. 단순 FAQ, 사내 문서 검색, 고객 불만 분류, 환불·예약·계정 변경 같은 액션 실행입니다. 이 네 가지는 같은 모델로 처리할 수도 있지만, 비용과 리스크를 줄이려면 분리하는 편이 좋습니다.
| 업무 유형 | 주요 실패 리스크 | 우선 평가 기준 | 추천 출발점 |
|---|---|---|---|
| 공개 FAQ·상품 안내 | 부정확한 안내, 장황한 답변, 비용 증가 | 저비용, 빠른 응답, RAG 근거 | 저비용 모델 + 짧은 답변 + RAG + 상담원 연결 |
| 사내 문서 검색 | 권한 없는 문서 노출, 근거 없는 요약 | 접근권한, 검색 품질, 출처 표시 | RAG 우선 설계 후 모델 비교 |
| 보고서·마케팅 초안 | 브랜드 톤 불일치, 검수 누락 | 문체 품질, 길이 제어, 사람 검수 | 고성능 모델로 기준 답안 생성 후 저비용 모델 테스트 |
| 관리자 자동화·에이전트 | 잘못된 API 호출, 권한 초과, 추적 불가 | 구조화 출력, tool calling, 감사 로그 | 권한·승인 단계가 있는 LLM 게이트웨이 |
| 민감 데이터 처리 | 개인정보·영업비밀 외부 전송, 계약 위반 | 데이터 보관, 학습 사용, 지역, 감사 | 관리형 클라우드 지역 옵션 또는 온프렘 검토 |
OpenAI의 모델 선택 가이드도 먼저 정확도 목표를 정하고, 그 목표를 충족한 뒤 비용과 지연을 최적화하라고 설명합니다. 기업 프로젝트에서도 같은 순서가 안전합니다. 먼저 “정답률 몇 퍼센트가 필요하다”보다 “어떤 오류가 얼마의 업무 손실을 만드는가”를 정의해야 합니다. ([developers.openai.com](https://developers.openai.com/api/docs/guides/model-selection))
2. 기업용 LLM 모델 선택 매트릭스
아래 매트릭스는 초기 검토 회의에서 사용할 수 있는 기준입니다. 각 항목을 1점에서 5점으로 점수화하고, 프로젝트 성격에 따라 가중치를 조정합니다. 예를 들어 공개 랜딩페이지의 AI 상담은 지연 시간과 비용 가중치가 높고, 사내 법무 문서 검색은 데이터 거버넌스와 근거 품질 가중치가 높습니다.
| 평가축 | 확인 질문 | 기본 가중치 | 흔한 함정 |
|---|---|---|---|
| 응답 품질 | 업무별 golden set에서 목표 품질을 넘는가? | 25% | 벤치마크 점수만 보고 실제 한국어 업무 문서로 평가하지 않음 |
| 월 비용 | 입력·출력·캐시·검색·임베딩·재시도 비용을 모두 합산했는가? | 20% | 토큰 단가만 보고 긴 RAG 컨텍스트와 출력 토큰을 누락 |
| 지연 시간 | p50이 아니라 p95 기준으로 사용자가 기다릴 수 있는가? | 15% | 데모 1회 응답 속도를 운영 속도로 착각 |
| 보안·거버넌스 | 학습 사용 여부, 보관 기간, 지역, 감사 로그를 설명할 수 있는가? | 20% | 소비자용 챗봇 약관과 API·기업 계약 조건을 혼동 |
| 통합성 | RAG, MCP, function calling, 구조화 출력, 관리자 화면과 잘 맞는가? | 10% | 모델은 좋지만 기존 백엔드·권한 체계와 연결하기 어려움 |
| 운영성 | 장애, rate limit, 모델 변경, 로그 분석, 비용 알림이 가능한가? | 10% | PoC 코드를 그대로 운영 배포 |
평가 데이터셋은 크게 만들 필요가 없습니다. 초기에는 실제 문의·문서·업무 티켓에서 50~200개 정도를 뽑아도 모델 간 차이가 보입니다. 다만 질문만 모으지 말고 ‘좋은 답변의 조건’을 같이 적어야 합니다. 예를 들어 “정책 근거 2개 이상 제시”, “고객에게 확정 환불을 약속하지 않음”, “JSON 스키마를 깨지 않음”처럼 채점 가능한 기준이 필요합니다. 구체적인 평가 항목은 LLM 평가 지표 가이드와 함께 보면 좋습니다.
3. Claude·OpenAI·Gemini·오픈소스는 이렇게 비교한다

아래 표는 벤더별 우열표가 아니라 검토 방향표입니다. 같은 Claude나 OpenAI라도 모델 크기, 추론 옵션, 캐싱, 지역, 호출 경로에 따라 비용과 지연이 달라집니다. 따라서 최종 결정은 반드시 우리 서비스 데이터로 재평가해야 합니다.
| 후보 | 잘 맞는 상황 | 장점으로 볼 부분 | 반드시 확인할 부분 |
|---|---|---|---|
| Claude 계열 | 긴 문서 검토, 정책 해석, 글쓰기·코딩·에이전트성 업무 | 복잡한 지시 준수와 장문 컨텍스트 업무에서 후보로 자주 검토됨 | API·Claude 제품 인터페이스별 보관 조건, ZDR 가능 여부, 지역 옵션, 캐싱 비용 |
| OpenAI 계열 | 웹서비스 AI 기능, 구조화 출력, 도구 호출, 멀티모달·에이전트 연동 | 모델·도구·문서·생태계가 넓어 제품 기능 통합 후보로 검토하기 좋음 | 모델별 가격, 캐시 write/read 과금, 프로젝트 단위 데이터 제어, snapshot·버전 고정 |
| Gemini·Vertex 계열 | Google Cloud, Workspace, BigQuery, Search 기반 조직 | 클라우드 IAM·데이터 레지던시·검색·멀티모달 흐름과 함께 검토 가능 | 무료·유료 서비스 데이터 사용 차이, 지역별 기능 제한, grounding·RAG 예외 |
| AWS Bedrock·Azure·Vertex 같은 관리형 클라우드 경로 | 이미 특정 클라우드 보안·구매·네트워크 체계를 쓰는 기업 | 계정·권한·청구·지역·감사 정책을 기존 클라우드 운영과 맞추기 쉬움 | 동일 모델이라도 리전, 출시 시점, 기능 지원, 가격표가 직접 API와 다를 수 있음 |
| 오픈소스·오픈웨이트 LLM | 데이터 주권, 온프렘 요구, 고정 대량 트래픽, 특수 도메인 | 모델·서빙·로그를 직접 통제할 수 있고 장기적으로 단위 비용을 낮출 가능성 | GPU 비용, 활용률, 서빙 엔지니어링, 보안 패치, 모델 업데이트, 품질 평가 인력 |
가격 비교는 단가 표를 복사하는 것으로 끝나지 않습니다. 일부 벤더 문서에는 기간 한정 가격, 캐시 write/read 가격, 지역 추론 배율 같은 조건이 별도로 표시됩니다. 견적서에는 현재 단가뿐 아니라 계약 기간 중 가격이 바뀌거나 프로모션이 종료될 경우의 비용도 별도로 계산해야 합니다. ([claude.com](https://claude.com/pricing))
4. 비용은 ‘월 API 요금’이 아니라 요청 구조로 계산한다
LLM 비용은 대략 다음 구조로 계산합니다.
월 비용 = 요청 수 × 평균 입력 토큰 × 입력 단가 + 요청 수 × 평균 출력 토큰 × 출력 단가 + 캐시 write/read + 임베딩·검색·rerank + tool 호출 + 재시도·fallback + 관측성·로그 저장 비용
특히 사내 문서 검색은 사용자의 질문보다 RAG로 붙는 문서 조각이 훨씬 큽니다. “질문은 30자니까 싸다”가 아니라, 매 요청마다 붙는 시스템 프롬프트, 권한 정보, 검색 결과, 대화 히스토리, 출력 길이를 합산해야 합니다. OpenAI의 지연 최적화 문서는 출력 토큰 생성이 대체로 가장 큰 지연 단계이며, 출력 토큰을 줄이면 지연도 줄 수 있다고 설명합니다. 비용과 지연은 분리된 문제가 아닙니다. ([developers.openai.com](https://developers.openai.com/api/docs/guides/latency-optimization))
프롬프트 캐싱은 비용과 지연을 줄이는 좋은 수단이지만 자동으로 항상 이득을 주지는 않습니다. OpenAI 문서는 반복되는 prefix를 앞쪽에 두고, cache hit와 cache write를 로그로 관찰하라고 설명합니다. Anthropic도 긴 예시, 반복 업무, 장기 대화에서 캐싱을 활용할 수 있으나 TTL과 write/read 가격 구조를 확인해야 한다고 안내합니다. ([developers.openai.com](https://developers.openai.com/api/docs/guides/prompt-caching))
초기 산정은 엑셀로도 충분합니다. 다만 실서비스 전에는 백엔드 로그에 tenant, user type, task type, model, input tokens, output tokens, cached tokens, latency, error, fallback reason을 남겨야 합니다. 이 구조가 없으면 비용이 늘었을 때 “사용자가 늘어서인지, 프롬프트가 길어져서인지, 모델이 바뀌어서인지” 구분할 수 없습니다. 세부 계산은 LLM API 비용 예측 가이드를 참고해 월별 시나리오로 나누는 편이 안전합니다.
5. 보안·데이터 거버넌스는 네 가지 질문으로 시작한다
LLM 도입 회의에서 “이 API는 안전한가요?”라고 묻는 것만으로는 부족합니다. 최소한 다음 네 가지를 분리해야 합니다.
- 학습 사용: 입력·출력이 모델 개선이나 학습에 사용되는가?
- 보관 기간: 프롬프트, 응답, 파일, 로그, 캐시가 얼마나 저장되는가?
- 데이터 위치: 저장 at-rest와 추론 processing이 어느 지역에서 일어나는가?
- 운영 감사: 누가 어떤 문서를 어떤 모델에 보냈는지 추적 가능한가?
OpenAI는 비즈니스 제품과 API 플랫폼의 입력·출력을 기본적으로 모델 학습에 사용하지 않는다고 설명하며, API 데이터 제어와 일부 조직의 zero data retention 옵션을 안내합니다. Anthropic은 API 입력·출력을 표준적으로 일정 기간 후 삭제한다고 설명하고, 별도 ZDR arrangement에서는 API 응답 후 customer prompts와 responses를 at-rest로 저장하지 않는다고 안내합니다. Google은 Gemini API 유료 서비스에서 prompts와 responses를 제품 개선에 사용하지 않는다고 설명하지만, 무료 서비스와 유료 서비스의 데이터 사용 조건이 다르므로 계정·청구 상태를 확인해야 합니다. ([openai.com](https://openai.com/business-data/))
| 데이터 등급 | 예시 | 허용 가능한 기본 접근 | 추가 통제 |
|---|---|---|---|
| 공개 | 상품 설명, 공개 FAQ, 보도자료 | 일반 API + 비용·품질 모니터링 | 브랜드 톤, 부정확 답변 방지 |
| 사내 일반 | 운영 매뉴얼, 비공개 업무 문서 | 상용 API 또는 클라우드 경로 | 계약 조건, 로그 마스킹, 접근권한 기반 RAG |
| 기밀 | 가격 정책, 영업 전략, 고객사 자료 | ZDR·지역 옵션·관리형 클라우드 검토 | 익명화, 전송 최소화, 관리자 승인, 감사 로그 |
| 규제·개인정보 | 민감정보, 의료·금융·교육 기록 | 법무·보안 검토 후 제한적 사용 | 온프렘 또는 강한 계약·기술 통제, 보존 정책, human review |
데이터 레지던시도 단순하지 않습니다. 저장 위치만 보장되는지, 추론 처리가 해당 지역에서 일어나는지, grounding·검색·RAG·파일 API·외부 tool 호출은 예외인지 확인해야 합니다. Gemini Enterprise 문서는 global 위치가 응답 시간과 최신 기능 측면에서 유리할 수 있지만, 지역 선택 시 기능 제한이 있을 수 있음을 설명합니다. 즉 규제상 지역 고정이 필요한 경우에는 성능·기능 포기를 감수해야 할 수도 있습니다. ([docs.cloud.google.com](https://docs.cloud.google.com/gemini/enterprise/docs/locations))
6. 단일 모델 고정보다 LLM 게이트웨이가 필요하다

운영 시스템에서는 프론트엔드가 특정 모델 API를 직접 호출하지 않는 편이 좋습니다. 중간에 LLM 게이트웨이 계층을 두고 요청을 분류해야 합니다.
- 요청이 공개 데이터인지 민감 데이터인지 분류한다.
- RAG가 필요한지, 단순 분류인지, 도구 실행인지 판단한다.
- 응답 형식이 자유 텍스트인지 JSON인지 정한다.
- 업무 중요도에 따라 저비용 모델, 균형 모델, 고성능 모델 중 하나로 보낸다.
- 실패, rate limit, 지연 초과 시 대체 모델 또는 사람 검수로 넘긴다.
- 비용, 지연, 오류, 거절, fallback 사유를 기록한다.
LiteLLM 같은 게이트웨이 도구는 여러 LLM을 OpenAI 호환 형식으로 호출하고 retry·fallback, 비용·지연 추적을 지원하는 구조를 문서화하고 있습니다. 자체 구현을 하든 도구를 쓰든 핵심은 모델 호출을 애플리케이션 코드에서 분리하는 것입니다. ([docs.litellm.ai](https://docs.litellm.ai/))
fallback은 “Claude가 실패하면 OpenAI로, OpenAI가 실패하면 Gemini로”처럼 단순히 나열하면 위험합니다. 이미 사용자에게 스트리밍 응답을 보여주기 시작했다면 중간에 모델을 바꾸기 어렵고, 두 모델의 정책·문체·JSON 스키마가 달라질 수 있습니다. 더 중요한 점은 보안 조건입니다. 예를 들어 US-only 처리 조건 때문에 선택한 모델이 실패했는데 global 모델로 자동 fallback하면, 서비스는 살아도 거버넌스는 깨집니다.
7. RAG를 넣으면 모델 선택이 쉬워지는 것이 아니라 평가 항목이 늘어난다
사내 문서 기반 AI는 대부분 RAG가 필요합니다. 그러나 RAG가 있으면 저렴한 모델만 써도 된다고 단정하면 안 됩니다. 검색 결과가 틀리면 고성능 모델도 틀리고, 검색 결과가 맞아도 질문이 복잡하면 저성능 모델이 근거를 제대로 조합하지 못할 수 있습니다.
RAG 프로젝트에서는 모델 품질 외에 다음 항목을 봐야 합니다.
- 문서 chunking이 업무 단위와 맞는가?
- 사용자 권한에 따라 검색 결과가 달라지는가?
- 답변이 어떤 문서에서 왔는지 출처를 남기는가?
- 검색 결과가 없을 때 모른다고 말하는가?
- 요약 과정에서 내부 정책을 과도하게 일반화하지 않는가?
RAG 설계가 약하면 모델을 바꿔도 문제가 반복됩니다. 사내 문서 연결을 준비 중이라면 모델 비교 전에 RAG 엔터프라이즈 구현 기준으로 문서 권한, 색인, 출처 표시, 로그 구조를 먼저 점검하는 것이 좋습니다.
8. 오픈소스·온프렘 LLM은 ‘통제권’과 ‘운영 부담’을 같이 산다
오픈소스 또는 오픈웨이트 LLM을 온프렘으로 운영하면 민감 데이터를 외부 API로 보내지 않는 구조를 만들 수 있습니다. 또한 트래픽이 많고 일정하며 GPU 활용률이 높은 조직은 장기적으로 단위 비용을 낮출 가능성이 있습니다. 하지만 초기 스타트업이나 지원사업 MVP에서 “API 비용이 아까우니 온프렘으로 가자”는 판단은 대부분 추가 비용을 만듭니다.
온프렘을 검토할 때는 다음 질문에 답해야 합니다.
- 피크 트래픽과 평균 트래픽 차이가 얼마나 큰가?
- GPU가 놀고 있는 시간이 많은가, 계속 활용되는가?
- 서빙 엔진, quantization, batch, 캐시, 장애 대응을 운영할 사람이 있는가?
- 모델 업데이트 후 품질 회귀를 평가할 golden set이 있는가?
- 보안 패치, 컨테이너 취약점, 접근 로그를 누가 관리하는가?
vLLM은 다양한 Hugging Face 모델 아키텍처를 지원하는 LLM 서빙 엔진으로 문서화되어 있지만, 서빙이 가능하다는 것과 기업 서비스의 품질·보안·SLA가 확보된다는 것은 다른 문제입니다. 오픈소스 모델은 자유도가 높지만 운영 책임도 내부로 옵니다. ([docs.vllm.ai](https://docs.vllm.ai/en/latest/index.html))
9. 도입 전 체크리스트

모델 후보가 2~3개로 좁혀졌다면 아래 체크리스트를 통과한 뒤 개발에 들어가는 편이 좋습니다.
| 단계 | 체크 항목 | 통과 기준 |
|---|---|---|
| 업무 정의 | AI가 답변만 하는지, 검색하는지, 실제 업무 액션을 실행하는지 구분 | 업무별 실패 시나리오와 사람 개입 기준이 있음 |
| 평가 | 실제 데이터 기반 golden set 구성 | 모델별 품질, hallucination, 형식 준수율을 비교함 |
| 비용 | 월 요청 수, 입력·출력 토큰, RAG 길이, 캐시, 재시도 반영 | 보수·기준·낙관 3개 시나리오가 있음 |
| 지연 | p95 응답 시간과 스트리밍 UX 기준 정의 | 느린 요청은 요약·비동기·알림 방식으로 우회 가능 |
| 보안 | 데이터 등급, 보관, 학습 사용, 지역, 로그 마스킹 검토 | 민감 데이터 전송 경로와 예외가 문서화됨 |
| 운영 | rate limit, 장애, fallback, 비용 알림, 관리자 로그 | 운영자가 대시보드에서 원인 추적 가능 |
| 교체 가능성 | 모델 호출 추상화, 프롬프트 버전 관리, 스키마 분리 | 모델 교체 시 프론트엔드와 핵심 업무 로직을 고치지 않음 |
정부지원사업이나 초기 MVP라면 처음부터 모든 모델을 붙일 필요는 없습니다. 공개 데이터 기반 기능은 관리형 API로 빠르게 검증하고, 민감 데이터가 포함되는 기능은 아키텍처·보안 계획을 분리해 제시하는 편이 현실적입니다. 최종보고나 투자 검토에서 중요한 것은 “어떤 모델을 썼다”가 아니라 “왜 이 모델 조합이 비용·품질·보안 기준을 만족하는가”를 설명하는 것입니다.
10. AgentMit 관점의 구현 순서
AgentMit은 특정 LLM 벤더를 먼저 추천하지 않습니다. 보통은 업무 중요도, 데이터 민감도, 예상 트래픽, 예산, 운영 인력 수준을 기준으로 모델 선택 기준부터 정리합니다. 이후 BizMit 같은 업무 시스템이나 SaaS에 AI 기능을 붙일 때는 단일 모델 고정이 아니라 LLM 게이트웨이, RAG, 캐싱, fallback, 관리자 감사 로그, 비용 알림을 함께 설계합니다.
실제 프로젝트에서는 다음 순서가 가장 낭비가 적습니다.
- 1차 워크숍: 업무 유형과 데이터 등급 분류
- 평가 세트 작성: 실제 문의·문서·보고서 샘플 50~200개 구성
- 모델 후보 테스트: Claude, OpenAI, Gemini, 오픈소스 후보를 같은 입력으로 비교
- 비용·지연 시뮬레이션: 월 트래픽과 p95 기준으로 산정
- 운영 아키텍처 설계: RAG, gateway, 로그, fallback, 관리자 화면
- MVP 구현: 가장 위험한 업무부터 작게 출시하고 로그로 재평가
이 접근은 모델 유행에 덜 흔들립니다. 새로운 모델이 나와도 평가 세트와 게이트웨이가 있으면 교체 판단을 데이터로 할 수 있습니다. 반대로 프론트엔드에 모델 API를 직접 붙이면, 모델 변경 때마다 품질·비용·보안 검토를 처음부터 다시 해야 합니다.
참고한 공개 자료
가격, 약관, 데이터 보관 조건은 변동성이 높습니다. 본문은 특정 단가를 고정하기보다 의사결정 기준으로 정리했으며, 실제 계약·출시 전에는 각 벤더의 최신 공식 문서를 다시 확인해야 합니다.
- OpenAI 비즈니스 데이터 보호, API 데이터 제어, 모델 선택, 프롬프트 캐싱 문서. ([openai.com](https://openai.com/business-data/))
- Anthropic Claude API 데이터 보관, ZDR, 데이터 레지던시, 프롬프트 캐싱 문서. ([platform.claude.com](https://platform.claude.com/docs/en/manage-claude/api-and-data-retention))
- Google Gemini API ZDR, Gemini API 약관, Gemini Enterprise 데이터 레지던시 문서. ([ai.google.dev](https://ai.google.dev/gemini-api/docs/zdr))
- LiteLLM과 vLLM 공식 문서. ([docs.litellm.ai](https://docs.litellm.ai/))
FAQ
Q1. Claude, OpenAI, Gemini 중 기업용으로 가장 좋은 LLM은 무엇인가요?
하나로 고정할 수 없습니다. 고객 응대, 문서 검색, 보고서 작성, 관리자 자동화, 에이전트 업무마다 품질 기준과 보안 조건이 다릅니다. 실무에서는 고성능 모델 하나를 고르는 방식보다 업무별로 고성능 모델, 저비용 모델, RAG, 캐싱, fallback을 조합하는 방식이 안전합니다.
Q2. 오픈소스 LLM을 온프렘으로 돌리면 API보다 항상 저렴한가요?
아닙니다. 트래픽이 일정하고 GPU 활용률이 높으며 MLOps 인력이 있는 조직은 유리할 수 있지만, 초기에는 GPU 임대·구매, 서빙, 모니터링, 보안 패치, 모델 업데이트, 장애 대응 비용이 큽니다. 요청량이 낮거나 변동이 큰 MVP라면 관리형 API가 더 단순할 때가 많습니다.
Q3. 내부 문서를 LLM API로 보내도 되나요?
문서 등급에 따라 다릅니다. 공개 자료나 일반 업무 문서는 계약·보관·학습 사용 조건을 확인한 뒤 API 사용이 가능할 수 있습니다. 개인정보, 영업비밀, 규제 데이터는 최소 전송, 익명화, 접근권한 기반 RAG, ZDR 또는 지역 옵션, 감사 로그, 법무·보안 검토가 필요합니다.
Q4. 나중에 모델을 바꾸기 쉽게 하려면 어떻게 설계해야 하나요?
모델 호출을 서비스 코드에 직접 박지 말고 LLM 게이트웨이 계층을 둡니다. 프롬프트 버전, 입력·출력 스키마, 평가 데이터셋, 토큰·지연 로그, 모델별 제한 기능을 분리해야 합니다. 또한 같은 요청을 여러 모델로 재평가할 수 있는 오프라인 eval 구조를 만들어야 교체 비용이 낮아집니다.
Q5. RAG를 쓰면 저렴한 모델만으로도 충분한가요?
항상 그렇지는 않습니다. RAG는 최신성·출처성·사내 문서 접근을 보완하지만, 검색 품질이 낮거나 질문이 복잡하면 모델의 추론력과 답변 통제력이 여전히 중요합니다. 먼저 검색 정확도, 근거 인용률, 답변 형식 준수율을 평가하고, 단순 질의는 저비용 모델, 복잡 질의는 상위 모델로 라우팅하는 편이 현실적입니다.

