AI Вопрос на собеседовании 2: Как обеспечить надежность вызова инструментов большой языковой моделью (LLM)

Как обеспечить, чтобы большая языковая модель (LLM) при вызове инструментов работала надежно и контролируемо, а не просто полагалась на подсказки для "убеждения" модели. Необходимо систематически предоставить многоуровневую структуру ограничений.

На примере запроса погоды, три распространенных "выдуманных" поведения модели при вызове инструментов:
1. Не вызывать инструмент, а напрямую выдумывать ответ.
2. Передавать параметры с неправильным форматом при вызове инструмента (например, инструмент не поддерживает "послезавтра", но передается параметр date="послезавтра").
3. Самовольно преобразовывать формат параметров (например, самостоятельно преобразовывать "послезавтра" в конкретную дату), даже если инструмент этого не требует.

Корень проблемы в том, что вывод модели по своей сути вероятностный, а подсказки накладывают лишь "мягкие ограничения" на распределение вероятностей, а не являются принудительным механизмом, обеспечивающим строгое соблюдение моделью. В сложных сценариях такие "мягкие ограничения" легко нарушаются.

Для решения этой проблемы необходимо многоуровневое инженерное решение:

1. Первый уровень: Оптимизация подсказок (мягкие ограничения)

   • Позиционируется как отправная точка системы ограничений, но ни в коем случае не конечная.
   • Подсказки следует рассматривать как "контракт на операции", четко объясняющий назначение инструмента, тип каждого параметра, границы и примеры недопустимых значений.
   • Следует добавить Few-shot примеры, демонстрируя образцы "правильный ввод → правильный вызов", используя контекстное обучение для закрепления поведенческой модели.

2. Второй уровень: Введение JSON Schema (жесткие ограничения)

   • Это ключевой шаг от "убеждения" к "установке барьеров".
   • Заменить описание параметров на естественном языке машиночитаемым, верифицируемым структурированным определением (JSON Schema). Можно строго определить типы полей, обязательность, диапазон перечисляемых значений, а также запретить модели выводить любые неопределенные поля с помощью установки additionalProperties: false.
   • Основные API-платформы поддерживают такие ограничения структурированного вывода на этапе декодирования модели, избегая нарушений формата на этапе генерации.

3. Третий уровень: Создание цикла проверка-исправление-повтор (исполнение как запасной вариант)

   • Даже при наличии Schema, после получения вывода модели необходимо проводить синтаксическую и Schema-проверку.
   • При неудачной проверке следует разработать механизм автоматической очистки и повторных попыток (с ограничением), передавая сообщение об ошибке модели для исправления вывода. После превышения числа попыток необходимо иметь план понижения уровня или ручной обработки.

4. Архитектурный уровень: Разделение ответственности

   • Следует разделить принятие решений и исполнение, создав трехуровневую архитектуру:
     • Уровень модели: Отвечает только за принятие решений (определение, какой инструмент вызвать, какие параметры сгенерировать).
     • Уровень фреймворка: Отвечает за выполнение фреймворка, включая проверку Schema, вызов инструмента, обработку повторных попыток и интеграцию результатов. Это гарантирует, что ошибки модели не повлияют напрямую на безопасность инструмента, а изменения инструмента не потребуют частой корректировки подсказок.
     • Уровень инструмента: Реализация конкретных бизнес-возможностей.
   • Фреймворки, такие как LangChain, LlamaIndex, как раз выполняют эту работу.

Ограничения текущего подхода: Хорошо обрабатывает формат параметров, но проверка семантики параметров (например, эквивалентность "Шанхай" и "Ху") все еще недостаточна. Это будет инженерной задачей в будущем.

Основной вывод: Обеспечение надежного вызова инструментов LLM по сути является проблемой программной инженерии, требующей создания системного инженерного решения, от мягких ограничений, жестких ограничений, исполнения как запасного варианта до архитектурного проектирования, а не просто полагаться на оптимизацию подсказок.