AI Pytanie Rekrutacyjne 2: Jak zapewnić niezawodność wywoływania narzędzi przez duży model językowy (LLM)

Jak sprawić, by duży model językowy (LLM) działał niezawodnie i kontrolowanie podczas wywoływania narzędzi, a nie tylko polegać na podpowiedziach, aby "przekonać" model. Potrzebne jest systematyczne, wielopoziomowe ramy ograniczeń.

Na przykładzie zapytania o pogodę, trzy typowe "zmyślone" zachowania modelu podczas wywoływania narzędzi:
1. Nie wywołuje narzędzia, bezpośrednio zmyśla odpowiedź.
2. Przekazuje parametry w nieprawidłowym formacie podczas wywoływania narzędzia (np. narzędzie nie obsługuje "pojutrze", a model przekazuje date="pojutrze").
3. Samowolnie konwertuje format parametrów (np. samowolnie zamienia "pojutrze" na konkretną datę), nawet jeśli narzędzie tego nie wymaga.

Źródłem problemu jest to, że dane wyjściowe modelu są z natury probabilistyczne, a podpowiedzi nakładają jedynie "miękkie ograniczenia" na rozkład prawdopodobieństwa, a nie mechanizm wymuszający ścisłe przestrzeganie przez model. W złożonych scenariuszach te "miękkie ograniczenia" łatwo zawodzą.

Aby rozwiązać ten problem, potrzebne jest wielopoziomowe rozwiązanie inżynieryjne:

1. Poziom 1: Optymalizacja podpowiedzi (miękkie ograniczenia)

   • Jest to punkt wyjścia systemu ograniczeń, ale nie koniec.
   • Należy traktować podpowiedzi jako "umowę operacyjną", jasno opisującą przeznaczenie narzędzia, typ każdego parametru, granice oraz podając przykłady nieprawidłowych wartości.
   • Należy dodać przykłady Few-shot, pokazując wzorce "poprawne wejście → poprawne wywołanie", aby wykorzystać uczenie kontekstowe do zakotwiczenia zachowania modelu.

2. Poziom 2: Wprowadzenie JSON Schema (twarde ograniczenia)

   • To kluczowy krok od "przekonywania" do "ustawiania barier".
   • Zastąpienie opisów parametrów w języku naturalnym maszynowo czytelną, weryfikowalną definicją strukturalną (JSON Schema). Można ściśle zdefiniować typy pól, wymagalność, zakres wartości wyliczeniowych, a poprzez ustawienie additionalProperties: false zabronić modelowi wyprowadzania jakichkolwiek niezdefiniowanych pól.
   • Główne platformy API obsługują takie ograniczenia strukturalnego wyprowadzania już na etapie dekodowania modelu, zapobiegając naruszeniom formatu u źródła.

3. Poziom 3: Ustanowienie pętli walidacji-naprawy-ponowienia (zabezpieczenie wykonawcze)

   • Nawet przy Schema, po otrzymaniu danych wyjściowych modelu należy przeprowadzić walidację składniową i Schema.
   • W przypadku niepowodzenia walidacji należy zaprojektować automatyczny mechanizm czyszczenia i ponawiania (z ograniczeniem), przekazując informację o błędzie z powrotem do modelu w celu korekty. Po przekroczeniu limitu ponowień potrzebny jest plan degradacji lub ręcznej obsługi.

4. Poziom architektoniczny: Separacja odpowiedzialności

   • Należy oddzielić decyzję od wykonania, tworząc trójwarstwową architekturę:
     • Warstwa modelu: Odpowiada tylko za decyzję (określenie, które narzędzie wywołać, jakie parametry wygenerować).
     • Warstwa frameworka: Odpowiada za ramy wykonawcze, w tym walidację Schema, wywoływanie narzędzi, obsługę ponowień i integrację wyników. Zapewnia to, że błędy modelu nie wpływają bezpośrednio na bezpieczeństwo narzędzi, a zmiany narzędzi nie wymagają częstego dostosowywania podpowiedzi.
     • Warstwa narzędzi: Konkretna implementacja możliwości biznesowych.
   • Frameworki takie jak LangChain, LlamaIndex właśnie wykonują taką pracę.

Ograniczenia obecnego rozwiązania: Dobrze radzi sobie z problemami formatu parametrów, ale weryfikacja semantyki parametrów (np. równoważność "Szanghaj" i "Hu") jest wciąż niewystarczająca. Będzie to wyzwanie inżynieryjne na przyszłość.

Główny wniosek: Zapewnienie niezawodnego wywoływania narzędzi przez LLM to w istocie problem inżynierii oprogramowania, wymagający systematycznego rozwiązania inżynieryjnego od miękkich ograniczeń, przez twarde ograniczenia, zabezpieczenia wykonawcze, aż po projekt architektury, a nie tylko poleganie na optymalizacji podpowiedzi.