AI интервю въпрос 2: Как да гарантираме, че големият езиков модел (LLM) извиква инструменти надеждно

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

Пример с проверка на времето: три често срещани "измислени" поведения на модела при извикване на инструменти:
1. Не извиква инструмента, а директно измисля отговор.
2. Предава параметри с грешен формат при извикване на инструмента (напр. инструментът не поддържа "вдругиден", но се предава date="вдругиден").
3. Самоволно преобразува формата на параметрите (напр. самоволно превръща "вдругиден" в конкретна дата), въпреки че инструментът не изисква това.

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

За да се реши този проблем, е необходимо многослойно инженерно решение:

1. Първи слой: Оптимизиране на подсказките (меки ограничения)
2. Ролята е отправна точка на системата за ограничения, но в никакъв случай крайна.
3. Подсказките трябва да се разглеждат като "операционен договор", който ясно описва предназначението на инструмента, типа на всеки параметър, границите и изброява примери за невалидни стойности.

4. Трябва да се добавят примери с малко примери (Few-shot), като се показват примери за "правилен вход → правилно извикване", за да се фиксира поведението на модела чрез контекстно обучение.

5. Втори слой: Въвеждане на JSON Schema (твърди ограничения)

6. Това е ключова стъпка от "обясняване" към "поставяне на парапети".
7. Използвайте машинно четими, проверими структурирани дефиниции (JSON Schema) вместо естествен език за описание на параметрите. Може стриктно да се дефинират типовете полета, задължителни ли са, диапазонът на изброените стойности и чрез задаване на additionalProperties: false да се забрани на модела да извежда неопределени полета.

8. Основните API платформи поддържат такова структурирано ограничение на изхода още на етапа на декодиране на модела, като предотвратяват форматни нарушения от самото начало.

9. Трети слой: Създаване на цикъл за проверка-корекция-повторен опит (изпълнение на резервен план)

10. Дори и със Schema, все още е необходимо след получаване на изхода от модела да се извърши синтактична и Schema проверка.

11. При неуспешна проверка трябва да се проектира механизъм за автоматично почистване и повторен опит (с горна граница), като информацията за грешката се върне на модела за коригиране на изхода. След превишаване на броя повторни опити трябва да има план за понижаване или ръчна обработка.

12. Архитектурно ниво: Разделяне на отговорностите

13. Решението и изпълнението трябва да бъдат разделени, образувайки трислойна архитектура:
    • Слой на модела: Отговаря само за вземане на решения (кой инструмент да се извика, какви параметри да се генерират).
    • Слой на рамката: Отговаря за изпълнителната рамка, включително Schema проверка, извикване на инструменти, обработка на повторни опити и интегриране на резултатите. Това гарантира, че грешките на модела не засягат директно сигурността на инструментите и промените в инструментите не изискват често коригиране на подсказките.
    • Слой на инструментите: Конкретна реализация на бизнес способностите.
14. Рамки като LangChain, LlamaIndex вършат точно тази работа.

Ограничения на текущото решение: Може добре да се справи с формата на параметрите, но покритието за проверка на семантиката на параметрите (напр. еквивалентността между "Шанхай" и "沪") все още е недостатъчно. Това ще бъде инженерно предизвикателство в бъдеще.

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