Агенты и инструменты: function calling, MCP, structured output и evals

Темы 63–66: вызов инструментов, агентные циклы и MCP, гарантированный JSON на выходе, evals и LLM-as-judge.

63. Function calling и вызов инструментов

Важность на собеседовании: 8/10 ████████░░

🔥🔥🔥 Критично. Базовый механизм всех агентов. Ждут понимания, что модель ничего не выполняет сама, и знания практики проектирования инструментов.

Как это работает — важно проговорить точно. Модель не вызывает функции. Она получает описания доступных инструментов (имя, описание, JSON-схема параметров) и, если считает нужным, возвращает не текст, а структурированный запрос «вызови get_weather с аргументом city=Москва». Ваш код выполняет вызов и возвращает результат обратно в диалог. Модель продолжает с учётом результата.

Цикл: запрос → модель просит инструмент → ваш код выполняет → результат в контекст → модель отвечает или просит следующий инструмент.

Как проектировать инструменты (это и отличает опытного):

• Описания — это промпт. Модель выбирает инструмент по описанию. Плохое описание = неправильный выбор. Пишите их так же тщательно, как системный промпт.
• Проектируйте под задачу пользователя, а не под ваш REST API. Один осмысленный search_orders(customer, period, status) лучше, чем три сырых эндпоинта, которые модель должна научиться комбинировать.
• Мало инструментов лучше многих. После примерно 15–20 качество выбора падает. Если инструментов много — группируйте, роутьте, используйте отложенную загрузку описаний.
• Строгие схемы (strict, additionalProperties: false) — гарантия валидности аргументов.
• Возвращайте ошибки в модель как текст, а не роняйте процесс: «Клиент не найден, проверьте ID» — модель исправится сама.
• Отделяйте читающие инструменты от изменяющих. Всё, что тратит деньги, отправляет сообщения или удаляет данные, — только с подтверждением человека. Это популярный сценарий на собеседовании: «спроектируй агента для брони билетов, который никогда не тратит деньги без подтверждения».
• Идемпотентность. Повтор вызова из-за ретрая не должен создавать второй заказ.

Параллельные вызовы. Модель может запросить несколько инструментов сразу — выполняйте их параллельно и возвращайте все результаты одним сообщением.

Function calling против structured output: инструменты — когда нужно действие или свежие данные; structured output — когда нужно просто извлечь данные в заданном формате, без побочных эффектов.

Вопрос: Агент зациклился: вызывает один и тот же инструмент по кругу. Причины и что делать? — Причины: инструмент возвращает бесполезный или пустой результат, и модель пробует снова; описание не даёт понять, что делать при неудаче; нет ограничения на число шагов; результат не попадает в контекст корректно. Лечение: жёсткий лимит итераций и бюджета, детект повторяющихся вызовов с одинаковыми аргументами, явная инструкция «если инструмент дважды вернул пусто — скажи пользователю, что не нашёл», информативные сообщения об ошибках, и трассировка всех шагов, чтобы это вообще увидеть.

64. Агенты и MCP

Важность на собеседовании: 8/10 ████████░░

🔥🔥🔥 Критично и растёт. Ждут трезвости: когда агент нужен, а когда достаточно обычного пайплайна. Про MCP достаточно понимать смысл и место в архитектуре.

Что такое агент. Система, где LLM сама решает, какие шаги предпринять, в каком порядке и когда остановиться. Отличие от workflow: в workflow последовательность шагов задана вами в коде, в агенте — определяется моделью на ходу.

ReAct — базовый цикл: Reason (подумать) → Act (вызвать инструмент) → Observe (посмотреть результат) → и снова, пока задача не решена.

Когда агент оправдан (и это половина ответа):

Честная позиция для собеседования: большинство продуктовых задач решаются обычным пайплайном или единичным вызовом модели. Агент — дорого (десятки вызовов вместо одного), медленно и непредсказуемо. Кандидат, который тянет агентов везде, выглядит хуже того, кто говорит «здесь агент не нужен, вот почему».

Память агента — четыре вида:

• В контексте — история текущего диалога.
• Эпизодическая — прошлые взаимодействия в векторной БД.
• Семантическая — извлечённые факты о пользователе и домене.
• Процедурная — то, что зашито в промпт или в веса.

Мультиагентные системы. Оркестратор раздаёт подзадачи специализированным агентам. Работает, когда задача естественно распадается (например, параллельный сбор информации из разных источников). По данным разборов продовых внедрений 2026 года, основная причина сбоев мультиагентных систем — рассогласование контекста между агентами (около 37% отказов): агенты работают на разных представлениях о состоянии, и результат одного не доходит до другого. Практический вывод: чем меньше агентов и чем строже схемы промежуточных артефактов, тем стабильнее.

MCP (Model Context Protocol). Открытый стандарт подключения моделей к инструментам и данным. Решает проблему «N моделей × M интеграций»: вместо того чтобы писать коннектор под каждую пару, вы поднимаете MCP-сервер один раз, и его видит любой MCP-совместимый клиент. Сервер отдаёт три вещи: tools (действия, выбирает модель), resources (данные для чтения, подключает приложение), prompts (шаблоны, выбирает пользователь). Транспорты — stdio для локальных серверов и HTTP для удалённых.

К 2026 году это де-факто стандарт: поддержан всеми крупными провайдерами и фреймворками, передан в независимый фонд. Соотношение с RAG простое: RAG — про поиск по заранее проиндексированной базе, MCP — про живые вызовы и действия. Часто RAG выставляется наружу как один из MCP-инструментов.

Безопасность агентов (в 2026 «избыточные полномочия» поднялись на третье место в OWASP-рейтинге рисков LLM): принцип наименьших привилегий, человек в цикле для необратимых действий, бюджеты по стоимости и числу шагов, аудит всех вызовов, изоляция выполнения кода.

Вопрос: Как отлаживать агента, который иногда даёт неверный результат? — Только через трассировку: логировать каждый шаг цикла — промпт, рассуждение, выбранный инструмент, аргументы, результат, стоимость, задержку. Дальше искать, на каком шаге впервые пошло не так (LangSmith, Arize Phoenix, LangFuse). Без пошаговых трейсов агент — чёрный ящик, и отладка превращается в гадание. Плюс отдельные eval-наборы на каждый режим отказа: зацикливание, неверный выбор инструмента, взрыв стоимости.

65. Structured output

Важность на собеседовании: 7/10 ███████░░░

🔥🔥 Часто. Практический вопрос уровня «как гарантировать валидный JSON». Знание про constrained decoding сразу отличает практика.

Проблема. Просьба «верни JSON» в промпте не гарантирует валидный JSON. Модель может добавить пояснение до и после, забыть закрыть скобку, поставить лишнюю запятую. Частота отказов при чистом промптинге — единицы процентов, и на потоке в миллион запросов это тысячи разборов, падающих с ошибкой.

Уровни надёжности:

Как работает constrained decoding. На каждом шаге генерации из распределения маскируются токены, которые нарушили бы схему. Модель физически не может выдать невалидную структуру — по схеме строится конечный автомат, и допустимы только переходы по нему. Это не проверка после генерации, а ограничение во время неё.

Практика:

• Опишите схему через Pydantic (Python) или Zod (TypeScript) — это и валидация, и типы, и документация в одном месте.
• Держите схемы плоскими и простыми: глубокая вложенность и много опциональных полей заметно ухудшают качество заполнения.
• Осмысленные имена полей — они работают как подсказка модели. customer_full_name лучше, чем f1.
• Enum вместо свободной строки везде, где набор значений конечен.
• Всё равно валидируйте на своей стороне: схема гарантирует форму, но не смысл. Дата будет строкой формата даты, но может быть 31 февраля.
• Оборачивайте в try/except с ретраем и логируйте сырые ответы — это спасает при отладке.

Вопрос: Structured output гарантирует правильный ответ? — Нет. Он гарантирует правильный формат. Модель может уверенно положить в идеально валидный JSON выдуманное значение. Формат и фактическая корректность — разные вещи, и вторая всё равно требует проверок и eval'ов.

66. Evals и LLM-as-judge

Важность на собеседовании: 10/10 ██████████

🔥🔥🔥 Критично. По оценке рекрутеров — самый сильный сигнал реального опыта работы с LLM. Это тема, на которой проще всего выделиться, потому что большинство кандидатов её проваливают.

Почему это главное. Без оценки вы не инженер, а «человек, который меняет промпты и надеется». Любое изменение — модели, промпта, чанкинга, температуры — может улучшить одно и сломать другое. Заметить это можно только измерением.

Три вида метрик:

1. Детерминированные. Валидность JSON, наличие обязательных полей, длина, отсутствие запрещённых слов, точное совпадение там, где есть верный ответ, прохождение тестов для сгенерированного кода. Дёшево, быстро, надёжно — используйте везде, где применимо.
2. Метрики похожести. BLEU, ROUGE, BERTScore. Для открытых задач почти бесполезны — правильных ответов много, а они меряют совпадение с одним эталоном.
3. LLM-as-judge. Модель оценивает ответ по критериям или сравнивает два ответа.

LLM-as-judge правильно:

• Попарное сравнение надёжнее абсолютных оценок. «Какой ответ лучше — А или Б» модель делает стабильнее, чем «поставь от 1 до 10».
• Известные искажения, которые надо назвать: position bias (предпочтение первой или последней позиции — лечится перестановкой и усреднением), length bias (более длинный ответ кажется лучше), self-enhancement bias (модель выше оценивает тексты, похожие на свои), низкая самосогласованность (тот же вход, другая оценка).
• Судью надо валидировать. Размечаете 50–100 примеров людьми, сравниваете с оценками судьи, считаете корреляцию. Если корреляции нет — судья бесполезен, и все ваши «улучшения» измеряют шум. Этот шаг пропускают почти все, и упоминание его сильно поднимает оценку.
• Судье нужен чёткий промпт с критериями и, лучше, с примерами оценок. «Оцени качество» — плохой промпт судьи.
• Судья должен быть моделью не слабее оцениваемой, и желательно другого семейства.
• Там, где возможна детерминированная проверка (код, SQL, формат, арифметика) — используйте её, а не судью.

Golden dataset — как строить:

• Из реального трафика, а не выдуманных примеров.
• Включать: типичные случаи, крайние случаи, известные провалы, состязательные запросы (попытки инъекций), запросы вне домена (модель должна корректно отказать).
• Голдены отделены от прогонов: хранится вход и ожидание, а не зафиксированный ответ. Тогда один и тот же набор переиспользуется на любой новой версии.
• 50–200 примеров достаточно для старта. Лучше 50 хорошо продуманных, чем 5000 случайных.

Офлайн и онлайн:

• Офлайн — на фиксированном наборе, в CI, при каждом изменении. Быстрая обратная связь.
• Онлайн — на реальном трафике: A/B, лайки, доля эскалаций, конверсия, повторные обращения. Только это отражает реальность.

Вопрос: Вы поменяли модель на более новую. Как убедиться, что стало лучше? — Прогнать golden-набор на обеих версиях и сравнить метрики по каждой категории кейсов отдельно — суммарный балл может вырасти при просадке в важном сегменте. Отдельно проверить регрессии: кейсы, которые работали и сломались. Сравнить стоимость и задержку. Потом A/B на части трафика с продуктовой метрикой. И только потом полная раскатка, с возможностью быстрого отката.

Часть 14 из 17 конспекта для подготовки к собеседованиям на NLP/LLM-разработчика. Остальные части — в разделе «Собесы».