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