# Собеседование AI-инженера: 5 тем про продакшен

27 вопросов с собеседований AI-инженеров по пяти темам - агенты, RAG, идемпотентность, оценка и масштаб, - и что должно прозвучать в сильном ответе. Пройди каждую тему, ответь вслух на каждый вопрос и отметь, где плаваешь.

Про обучение моделей тут почти не спрашивают. Весь разговор сводится к одному: сможешь ли ты довести AI-прототип до продакшена. Ниже пять тем, по каждой - что спрашивают и опорные пункты ответа.

врезка `// Как готовиться`: текст «Отвечай вслух и на примере своего проекта. Определение из учебника - слабый ответ. Сильный - «вот что сломалось, вот как я это поймал, вот что поменял».»

// Тема 1

## Агенты и обвязка

Модель - только центр. Вокруг неё состояние, инструменты, права доступа, повторы и логи. Проверяют, понимаешь ли ты, что из этого и зачем строить.

- 1 «Чем агент отличается от workflow и когда агент не нужен?» — Workflow - заранее заданный путь, агент сам выбирает следующий шаг. Скажи, что начинаешь с самого простого решения и добавляешь автономию, только когда она окупает цену, задержку и риск ошибок.
- 2 «Где агент хранит состояние между шагами и что будет, если процесс упадёт посередине?» — Состояние - вне памяти процесса: история шагов, результаты инструментов, текущая цель. После падения агент продолжает с последнего сохранённого шага, а не начинает заново.
- 3 «Как ты описываешь инструменты, чтобы модель вызывала их правильно?» — Понятное имя, описание с примерами, строгая схема аргументов, внятные ошибки. Плохое описание инструмента ломает агента чаще, чем слабая модель.
- 4 «Как ограничить права агента?» — Минимум прав на каждый инструмент, разделение чтения и записи, подтверждение человеком для необратимых действий - оплата, удаление, отправка наружу.
- 5 «Что делаешь, если инструмент ответил ошибкой или агент зациклился?» — Повтор с паузой для временных ошибок, лимит шагов и бюджета токенов на задачу, остановка с понятной причиной вместо бесконечного цикла.
- 6 «Что логируешь, чтобы разобрать плохой ответ агента?» — Трассу целиком: промт, каждый вызов инструмента с аргументами и ответом, токены, задержку, итог. Без трассы разбор - гадание.

[Building effective agents - Anthropic](https://www.anthropic.com/engineering/building-effective-agents)

// Тема 2

## RAG и поиск

«Что такое RAG» уже не спрашивают. Спрашивают, точно ли найденный кусок документа относится к вопросу: чанки, эмбеддинги, top-k и реранк.

- 1 «Как ты режешь документы на чанки и как выбираешь размер?» — По смыслу - разделы, абзацы, - а не по фиксированному числу символов, с небольшим перекрытием. Размер подбираешь на своих вопросах: слишком мелкий теряет контекст, слишком крупный размывает поиск.
- 2 «Почему поиск только по эмбеддингам промахивается?» — Эмбеддинги ловят смысл, но теряют точные совпадения - артикулы, коды ошибок, имена. Поэтому гибрид: векторный поиск плюс BM25 по ключевым словам.
- 3 «Как выбираешь top-k и зачем нужен реранк?» — Сначала достаёшь с запасом - например, 20-50 кандидатов, - потом реранкер пересортировывает их по реальной связи с вопросом, и в модель идут лучшие несколько.
- 4 «Как проверить, что найденный контекст относится к вопросу?» — Отдельно мерить поиск и ответ. Для поиска - набор «вопрос → правильный чанк» и метрика, нашёлся ли он в top-k. Для ответа - опирается ли он только на найденное.
- 5 «Чанк вырван из документа и потерял смысл. Что делаешь?» — Добавляешь к чанку контекст: заголовок документа и раздела или короткое пояснение, о чём этот кусок. Anthropic называет это Contextual Retrieval - по их данным, провалы поиска в top-20 падают на 49%, а с реранком - на 67%.
- 6 «Что делает модель, если нужного в базе нет?» — Говорит, что не нашла, а не придумывает. Это задаётся в промте и проверяется отдельными тестами на запросы, ответа на которые в базе нет.

[Contextual Retrieval - Anthropic](https://www.anthropic.com/news/contextual-retrieval)

// Тема 3

## Надёжность и идемпотентность

Повтор запроса - это ещё не надёжность. Сервис упал, запрос ушёл второй раз, и без ключа идемпотентности клиент заплатил дважды.

- 1 «Что такое идемпотентная операция?» — Её можно выполнить несколько раз с тем же результатом, что и один раз. GET и DELETE идемпотентны по определению, создание платежа через POST - нет.
- 2 «Почему ретраи без ключа опасны?» — Клиент не знает, дошёл ли запрос: ответ мог потеряться уже после списания. Повтор без ключа - второе списание.
- 3 «Как работает ключ идемпотентности?» — Клиент генерирует уникальный ключ - например, UUID v4 - и шлёт его с запросом. Сервер запоминает результат первого запроса и на повтор с тем же ключом отдаёт сохранённый ответ, не выполняя операцию снова.
- 4 «Что если пришёл тот же ключ, но с другими параметрами?» — Ошибка, а не выполнение. Сервер сравнивает параметры с исходным запросом - так ловится случайное переиспользование ключа.
- 5 «Как это связано с LLM-приложением?» — Агент и воркеры тоже ретраят: повтор шага может второй раз отправить письмо, создать заказ или списать деньги. Каждый инструмент с побочным эффектом принимает ключ, а повторы идут с паузой, которая растёт с каждой попыткой.

```
curl https://api.stripe.com/v1/customers \
  -u sk_test_...: \
  -H "Idempotency-Key: KG5LxwFBepaKHyUD" \
  -d description="My First Test Customer"
```

_Так выглядит ключ в запросе к Stripe_

[Idempotent requests - Stripe](https://docs.stripe.com/api/idempotent_requests)

// Тема 4

## Оценка

Тестовый набор обычно лёгкий, а в проде прилетают сложные случаи - и метрики с тестов там не держатся.

- 1 «Почему метрики на тестах не совпадают с продом?» — Тестовый набор собирали руками, и в нём простые, чистые запросы. В проде - опечатки, длинный контекст, запросы не по теме и редкие случаи, которых в тестах нет.
- 2 «Как собрать набор сложных случаев?» — Брать из реальных логов: жалобы, дизлайки, ответы, которые исправил человек, запросы, на которых упал агент. Каждый разобранный провал становится новым тестом.
- 3 «Чем мерить качество, если правильный ответ не один?» — Где можно - простые проверки кодом: формат, наличие нужных полей, запрещённые слова. Где нельзя - LLM-судья с чёткими критериями, и его оценки сверяешь с оценками человека.
- 4 «Как понять, что новая версия промта не сломала старое?» — Прогнать весь набор до и после и сравнить по каждому случаю, а не по средней цифре. Средняя может вырасти, пока важный сценарий сломался.
- 5 «Как следишь за качеством уже в проде?» — Логи и трассы, выборочная ручная проверка, сигналы пользователей, алерты на рост отказов и пустых ответов.

[Your AI Product Needs Evals - Hamel Husain](https://hamel.dev/blog/posts/evals/)

// Тема 5

## Масштаб LLM-приложений

Приходит 120 запросов в секунду, воркеры тянут 80. Очередь мощности не добавляет, она просто копит хвост. Плюс лимиты RPM и TPM, цена и задержка.

- 1 «Приходит 120 запросов в секунду, обрабатываешь 80. Что будет?» — метрика «+40 запросов/с в хвост» — Хвост растёт на 40 запросов в секунду - 2 400 в минуту, - и задержка растёт вместе с ним. Очередь сглаживает пики, но не решает нехватку мощности: нужно больше воркеров, меньше работы на запрос или отказ части трафика.
- 2 «Что такое RPM и TPM и что делать при 429?» — Лимиты провайдера: запросы в минуту и токены в минуту. При ошибке 429 ждать столько, сколько сказано в заголовке retry-after, и повторять с растущей паузой, а не долбить API сразу.
- 3 «Как снизить нагрузку на лимиты и цену?» — Кэшировать повторяющуюся часть промта, отдавать простые задачи модели поменьше, резать лишний контекст, неспешные задачи гнать пакетом.
- 4 «Как уменьшить задержку для пользователя?» — Стримить ответ, параллелить независимые вызовы, держать короткий промт, ставить таймауты и запасного провайдера или модель.
- 5 «Как защитить систему, когда очередь растёт?» — Ограничить длину очереди, отдавать понятный отказ вместо бесконечного ожидания, разделить приоритеты - платные и интерактивные запросы вперёд фоновых.

```
рост хвоста = входящие - обработанные = 120 - 80 = 40 запросов/с
через минуту в очереди: 40 × 60 = 2 400 запросов
```

_Посчитай хвост очереди сам_

[Rate limits - Claude API](https://platform.claude.com/docs/en/api/rate-limits)

---

// Итог

## Проверь себя

- [ ] Объясни вслух, когда нужен агент, а когда хватит workflow
- [ ] Расскажи, где агент хранит состояние и что логируешь в трассе
- [ ] Нарисуй RAG-конвейер: чанки, эмбеддинги + BM25, top-k, реранк
- [ ] Назови, как отдельно мерить качество поиска и качество ответа
- [ ] Объясни на примере платежа, зачем нужен ключ идемпотентности
- [ ] Скажи, что сервер делает с повтором того же ключа и с тем же ключом, но другими параметрами
- [ ] Собери из своих логов 10 сложных случаев для тестового набора
- [ ] Опиши, как сравниваешь две версии промта по каждому случаю
- [ ] Посчитай хвост очереди при 120 входящих и 80 обработанных в секунду
- [ ] Перечисли три способа уложиться в лимиты RPM и TPM
- [ ] Ответь на каждый вопрос из пяти тем на примере своего проекта

---

Источник: https://localhost:3000/m/sobesedovanie-ai-inzhenera-5-tem-pro-prodakshen