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-нің құралдарды сенімді шақыруын қамтамасыз ету - бұл мәні бойынша бағдарламалық инженерия мәселесі. Жұмсақ шектеулерден, қатаң шектеулерден, орындау кепілдігінен және архитектуралық дизайннан тұратын жүйелі инженерлік шешім қажет, тек нұсқауларды оңтайландыруға сүйену жеткіліксіз.