System design для LLM-приложения

Задача и план на 45 минут

Возьмём типичное условие: «Design an AI support assistant for a software company: it answers customer questions from the documentation and can check order status and open a support ticket». Время делим так: 5 минут requirements, 10 минут общая архитектура, 15 минут углубление в одну-две части по выбору собеседующего, 10 минут eval, safety и cost, 5 минут rollout и вопросы. Вслух объяви план в начале — это показывает, что ты ведёшь разговор.

Requirements и architecture

1. Requirements: сначала цифры и границы. Functional requirements (что система делает): отвечать по базе из 20 000 документов, смотреть статус заказа, открывать ticket, передавать разговор человеку. Non-functional (с какими свойствами): нагрузка, задержка, языки, приватность, бюджет. Задай вопросы и запиши допущения:

• 5 000 разговоров в день по 4 реплики — около 20 000 вызовов модели в день;
• TTFT (time to first token, время до первого token ответа) по p95 (95-му перцентилю) — не больше 2 с;
• два языка, английский и испанский;
• в разговорах есть PII (персональные данные), их нельзя хранить в logs открытым текстом;
• что считается провалом: неверный ответ о возврате денег, ticket не на того клиента.

Последний пункт важнее остальных: от него зависят eval и safety.

2. Architecture: простое, потом сложное. Начни с самого простого, что может работать, и добавляй части только с причиной. Anthropic в «Building effective agents» советует «finding the simplest solution possible»: workflow (заранее заданный путь в коде) там, где путь известен, и agent (модель сама выбирает шаги) только там, где шаги нельзя предсказать.

Путь запроса: клиент → API gateway (аутентификация, rate limits — ограничения частоты запросов) → router (классификатор намерения: вопрос по документации, действие, передача человеку) → для вопросов RAG: hybrid search (поиск по словам плюс по embeddings — векторам смысла) → reranker → top-5 фрагментов → LLM → output guardrails (проверки ответа) → клиент. Для действий — tools: get_order_status (только чтение, заказ берётся из сессии клиента) и create_ticket (запись, с подтверждением и idempotency key — ключом, который не даёт создать ticket дважды при повторе запроса). Рядом — LLM gateway (единая точка доступа к моделям с fallback — запасной моделью — и учётом расходов), cache и traces для каждого шага.

Data и eval

3. Data: откуда знания и как они обновляются. Ingestion pipeline (конвейер загрузки): документы режутся на chunks (фрагменты) по структуре, с metadata — источник, версия, дата действия, кому доступно. Обновление — по change feed (потоку изменений): новые, изменённые и удалённые документы; удаление так же важно, как добавление. Второй источник данных — история tickets: из неё берут реальные вопросы для eval, предварительно обезличив.

4. Eval: как поймёшь, что работает. Offline: golden set (размеченный набор) из 200 реальных вопросов по двум языкам и 50 задач с действиями. Метрики по слоям: retrieval — recall@5 (нашёлся ли нужный документ в первых пяти); generation — groundedness (подтверждён ли ответ источником), его оценивает LLM-as-judge, проверенный на 100 ответах, размеченных людьми; действия — конечное состояние (создан ли ticket нужному клиенту), детерминированно. Для действий считай pass^k (доля задач, решённых во всех k прогонах): клиенту нужна стабильность, а не удача. Online: доля разговоров без передачи человеку, повторные обращения, оценки клиентов и еженедельная выборка разговоров, которую читают люди.

Safety и cost

5. Safety: что может пойти не так.

• Prompt injection: инструкция в документе или в тексте ticket. Защита — tools с минимальными правами, данные отделены от инструкций, действие с последствиями — только с подтверждением.
• Excessive agency (лишние полномочия агента): у ассистента нет tool для возврата денег — значит, он не может его сделать при любом prompt.
• PII: redaction в logs, срок хранения, доступ к traces по ролям.
• Output guardrails: формат, запрещённые темы, обещания вне политики → передача человеку.

6. Cost: арифметика на доске. Цены меняются; возьми условные для арифметики и скажи об этом: $1 за 1 млн input tokens и $5 за 1 млн output tokens. На вызов — 3 000 tokens входа (system prompt, история, 5 фрагментов) и 300 tokens ответа.

• Input: 20 000 × 3 000 = 60 млн tokens в день → $60.
• Output: 20 000 × 300 = 6 млн tokens в день → $30.
• Итого около $90 в день, около $2 700 в месяц, около $0,018 за разговор.

Рычаги: prompt caching (повторное использование общего начала prompt), маленькая модель для простых вопросов через router, меньше фрагментов в context, exact cache для частых одинаковых вопросов. Каждый рычаг проверяют на eval: дешевле, но не хуже.

Rollout и компромиссы

7. Rollout: как выпустить без вреда. Eval gate в CI блокирует merge → внутреннее тестирование сотрудниками → shadow (новая версия отвечает параллельно, клиент видит старую) → canary на 5% трафика с автоматическим rollback при падении метрик → полный выпуск за feature flag (переключателем). Мониторинг: TTFT и TPOT (time per output token), доля ошибок, стоимость разговора, доля передач человеку, по каждому языку отдельно.

Компромиссы, которые стоит назвать вслух. Собеседующий ждёт не одной правильной схемы, а осознанного выбора. Workflow или agent: workflow предсказуем и дешевле, agent гибче, но дороже и труднее в оценке. RAG или длинный context: длинный context проще, но дороже на каждый вызов и тонет в лишнем тексте, а RAG требует индекса и его обновления. Reranker повышает точность и добавляет задержку. Judge масштабируется, люди точнее, поэтому judge проверяют по человеческой разметке. Назови выбор, причину и что заставит его пересмотреть: «If retrieval recall stays below target, I'd revisit chunking before changing the model».