AI / LLM
Сборка LLM-приложений: тест с выбором ответа
Суть Тест с выбором на синтез по всему треку AI/LLM — где caching, tools, RAG, streaming, бюджеты, агенты и evals падают на швах между собой.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего трека. Ни один не тестирует один слой — каждый ставит два корректных слоя вместе и спрашивает, где ломается композиция. Этот шов и есть место, где production LLM-приложения реально падают.
Цель
Убедись, что рассуждаешь о швах: как RAG взаимодействует с кэшем, как tool call взаимодействует со стримом, как agent loop взаимодействует с бюджетом и почему evals обязаны включать живой retrieval-путь.
Викторина
Completed
У RAG-ассистента длинный статический system-промпт с пометкой cache_control, но cache hit rate в проде около 0% — хотя на демо он выглядел закэшированным. В чём причина и фикс?
Heads-up TTL управляет тем, сколько живёт запись, а не тем, совпадает ли префикс. Если префикс разный на каждом запросе, дольше живущая запись всё равно не матчится — hit rate остаётся нулём. Проблема в нестабильности префикса, а не в вытеснении.
Heads-up Объём не помогает, когда у каждого запроса разный префикс. На демо «закэшировалось» только потому, что повторялся один и тот же вопрос; реальные запросы несут разные чанки внутри префикса.
Heads-up Это меняет фичу заземления на метрику кэша — оптимизация не того слоя. Фикс сохраняет retrieval и переносит его за брейкпойнт, чтобы статический префикс остался в кэше.
Викторина
Completed
Стримящийся ход заканчивается с stop_reason: tool_use посередине, и UI вечно висит на спиннере. Какая ментальная модель чинит это?
Heads-up Ничего не ошиблось — модель намеренно запросила тулзу. Перезапуск повторяет работу и может зациклиться; нужно обработать переход tool_use и продолжить, а не рестартовать.
Heads-up max_tokens ограничивает длину, а не решение модели вызвать тулзу. Она остановилась, чтобы запросить тулзу; больший лимит не меняет эту ветку.
Heads-up Буферизация выбрасывает выигрыш стриминга по латентности и всё равно не запускает тулзу — забуферишь, а потом всё равно надо выполнить и возобновить. Ветка tool_use в любом случае не обработана.
Викторина
Completed
У агента есть дашборд token-бюджета с алертами, но плохой ввод загнал его в retry-цикл, спаливший тысячи долларов за ночь. Почему бюджет не защитил?
Heads-up Более быстрая наблюдаемость всё равно только наблюдает. К моменту срабатывания любого алерта доллары уже потрачены; только pre-call гейт, который отказывает следующему запросу, реально ограничивает стоимость.
Heads-up Более дешёвая модель делает runaway-цикл дешевле за шаг, но он всё равно бежит бесконечно на плохом вводе. Дефект — отсутствие условия остановки, а не цена за токен.
Heads-up Больше retry — это противоположность фикса, оно кормит цикл. Знаменитый случай бежал 11 дней на $47 000 именно потому, что ничто не ограничивало число итераций.
Викторина
Completed
Твой офлайн eval-набор зелёный на каждом деплое, но пользователи жалуются на худшие ответы сразу после смены ретривера. Почему evals пропустили регрессию?
Heads-up Флейкость проявляется как шумный pass/fail, а не как стабильно зелёное, скрывающее реальную регрессию. Это пробел в покрытии: шов retrieval просто не в тестовом пути.
Heads-up Изменился ретривер, а не модель. Перегон generation-only evals на замороженном контексте всё равно пропускает путь, который реально регрессировал.
Heads-up Метрики генерации могут быть нормальны в изоляции; проблема в том, что они гоняются на замороженном контексте. Нужен end-to-end eval с живым retrieval, а не другие метрики генерации.
Викторина
Completed
Сетевой сбой обрывает стримящийся ход с stop_reason: tool_use, но с нулём tool_use-блоков, и агент тихо замирает. Поздний запрос отвергается с 'unexpected tool_use_id found in tool_result block'. Какова общая первопричина?
Heads-up Оба — один и тот же шов: стрим и протокол тулзов делят состояние между запросами, а композиция никогда не валидировала эту пару. Пустой tool_use-стоп и осиротевший tool_use_id — два симптома невалидированных переходов.
Heads-up Ни один симптом — не галлюцинация: один — оборванный стрим без tool-блока, другой — устаревший id от упавшего хода. Фикс — парность на уровне протокола и восстановление, а не формулировка промпта.
Heads-up HTTP-идемпотентность дедуплицирует retry; она ничего не делает с пустым tool_use-стопом или с tool_result, ссылающимся на id, который модель не выдавала. Нужен state-machine-трекинг tool_use ↔ tool_result.
Викторина
Completed
Выкатывается RAG-агентный ассистент: каждый компонент прошёл свой тест, но счёт утроился и ответы кажутся медленнее в проде. Какой senior-ход для дебага?
Heads-up Они все всё ещё проходят — в этом ловушка. Сбой между корректными компонентами (например, RAG бьёт кэш-префикс, пока зацикленные запросы растят транскрипт), поэтому покомпонентные тесты его не вскроют.
Heads-up Фичи обязаны сосуществовать; цель — корректная композиция, а не избегание композиции. Трассировка шва позволяет оставить все шесть слоёв и починить границу.
Heads-up Больше железа оплачивает сломанный шов вместо его починки — кэш всё ещё бит, а цикл всё ещё растит транскрипт. И стоимость, и латентность идут из шва, а не из ёмкости.
Итог
Сквозная линия трека — одно предложение: каждый слой корректен по своему контракту, а сбой живёт там, где выход одного слоя тихо нарушает входное допущение следующего. RAG меняет префикс, который кэш считал стабильным; tool_use-стоп меняет стрим, который рендерер считал прозой; реальный ввод меняет цикл, который бюджет считал конечным; retrieval-путь меняется под eval-набором, считавшим контекст фиксированным. Эти баги не дебажат, перетестируя куски — трассируют один реальный запрос насквозь и на каждой границе спрашивают, что следующий слой считал само собой, а предыдущий это только что изменил.