Как сравнить два LLM для customer support automation
Есть реальный продуктовый use case: customer support automation. Нужно сравнить два LLM/agent variants и выбрать, какой запускать. Как спроектировать evaluation: данные, offline metrics, human/LLM judging, system metrics и online validation?
Ответить самому
Сначала сформулируйте ответ как на собеседовании, затем откройте разбор и оцените себя.
Короткий ответ
Сначала определить product success: correct resolution, safe answer, escalation when needed, user satisfaction, latency and cost. Затем собрать representative ticket eval set with gold resolutions and policy labels, прогнать оба LLM в одинаковых условиях, оценить retrieval, final answer, routing/escalation, hallucination and tone, проверить human/LLM judges, и только потом запускать canary/A-B on real traffic.
Полный разбор
Evaluation начинается не с модели, а с product contract. Для support automation важны: правильное решение обращения, отсутствие hallucination, корректная эскалация к человеку, соблюдение policy, user satisfaction, latency, cost and containment rate. Нельзя выбирать LLM только по BLEU/F1 или generic benchmark.
Данные: берется репрезентативная выборка реальных tickets/chats по категориям, языкам, сложности, частым и редким intent-ам, sensitive cases and escalation cases. Для каждого примера нужны gold resolution или accepted answer, relevant knowledge-base snippets, expected routing decision, policy constraints and severity. Отдельно нужен holdout set, который не используется для prompt tuning.
Offline сравнение должно быть fair: одинаковый retrieval/index version, одинаковые prompts/tools/policies where possible, фиксированные decoding parameters, одинаковый context budget. Метрики делятся на компоненты: retrieval recall/precision, answer correctness/faithfulness, policy compliance, escalation accuracy, hallucination rate, tone/format, refusal correctness, latency, tokens/request and cost. Для answer quality можно использовать calibrated LLM-as-judge, но его надо валидировать на human-labeled sample and disagreement cases.
Решение принимается по slices, а не только по average score: high-risk topics, long-tail intents, non-English tickets, ambiguous user messages, missing-doc cases. Если одна модель выигрывает average, но проигрывает на regulated/high-risk slice, ее нельзя просто выкатывать всем.
После offline gate нужен online validation: canary или A/B на небольшой доле трафика. Online метрики: containment without recontact, escalation rate, repeat contact rate, CSAT/thumbs, human override rate, complaints, p95 latency and cost per resolved ticket. Нужен rollback threshold and monitoring. Финальный выбор может быть routing policy, а не одна модель для всего: cheap/fast model для простых intents, stronger model for complex/high-risk cases, human fallback for low confidence.
Теория
Support automation evaluation combines RAG quality, generation faithfulness, policy/routing correctness and product outcome. Offline benchmarks reduce risk, but model choice must be validated on production traffic and sliced by risk/intent/language.
Типичные ошибки
- Сравнить модели на generic benchmark вместо реальных tickets and policies.
- Поменять одновременно model, prompt, retriever and tools, поэтому невозможно понять источник улучшения.
- Смотреть только containment rate и игнорировать repeat contact, hallucinations and unsafe non-escalation.
- Не делать slice analysis for high-risk or long-tail support cases.
Как отвечать на собеседовании
- Начни с product success and support-specific risks.
- Назови fair offline setup: same prompts, same retriever, same parameters.
- Заверши online A/B and possibility of routing between models rather than picking one globally.