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 е суштински софтверско-инженерски проблем, кој бара воспоставување систематско инженерско решение од меки ограничувања, тврди ограничувања, извршна заштита до архитектонски дизајн, а не само потпирање на оптимизација на промптови.