AI intervijas jautājums 2: Kā nodrošināt, ka lielo valodu modeļu (LLM) rīku izsaukšana ir uzticama

Kā nodrošināt, ka lielo valodu modelis (LLM) rīku izsaukšanas laikā darbojas uzticami un kontrolējami, nevis tikai paļaujoties uz uzvednes frāzēm, lai "pārliecinātu" modeli. Nepieciešams sistemātiski izveidot daudzlīmeņu ierobežojumu sistēmu.

Piemēram, laikapstākļu vaicājuma gadījumā modelis rīku izsaukšanā bieži pieļauj trīs veidu "izdomāšanas" uzvedību:
1. Neizsaukt rīku, tieši izdomāt atbildi.
2. Izsaukt rīku ar formāta kļūdām parametros (piemēram, rīks neatbalsta "parīt", bet tiek nodots parametrs date="parīt").
3. Patvaļīgi pārveidot parametru formātu (piemēram, patvaļīgi pārvērst "parīt" konkrētā datumā), pat ja rīks to neprasa.

Problēmas sakne ir tā, ka modeļa izvade pēc būtības ir varbūtības rakstura, un uzvednes frāzes tikai uzliek "mīkstus ierobežojumus" varbūtību sadalījumam, nevis nodrošina stingru mehānismu, kas liek modelim stingri ievērot noteikumus. Sarežģītos scenārijos šie "mīkstie ierobežojumi" viegli zaudē spēku.

Lai atrisinātu šo problēmu, nepieciešams daudzlīmeņu inženiertehnisks risinājums:

1. Pirmais līmenis: Uzvednes frāžu optimizācija (mīkstie ierobežojumi)

   • Pozicionēšana ir ierobežojumu sistēmas sākumpunkts, bet nekādā gadījumā ne beigu punkts.
   • Uzvednes frāzes jāuzskata par "darbības līgumu", skaidri norādot rīka mērķi, katra parametra veidu, robežas un uzskaitot nelikumīgu vērtību piemērus.
   • Jāpievieno Few-shot piemēri, demonstrējot "pareiza ievade → pareiza izsaukšana" paraugus, izmantojot konteksta mācīšanos, lai nostiprinātu modeļa uzvedības modeli.

2. Otrais līmenis: JSON Schema ieviešana (stingrie ierobežojumi)

   • Tas ir izšķirošs solis no "pārliecināšanas" uz "barjeru uzstādīšanu".
   • Dabisko valodu parametru aprakstu aizstāj ar mašīnlasāmu, pārbaudāmu strukturētu definīciju (JSON Schema). Var stingri definēt lauku tipus, obligātos laukus, uzskaitījuma vērtību diapazonus un iestatīt additionalProperties: false, lai aizliegtu modelim izvadīt jebkādus nedefinētus laukus.
   • Populāras API platformas atbalsta šādu strukturētu izvades ierobežojumu modeļa dekodēšanas fāzē, tādējādi novēršot formāta pārkāpumus jau izcelsmē.

3. Trešais līmenis: Validācijas-labojuma-atkārtojuma cikla izveide (izpildes drošības tīkls)

   • Pat ar Schema, pēc modeļa izvades saņemšanas jāveic sintakses un Schema validācija.
   • Ja validācija neizdodas, jāizstrādā automātiskas tīrīšanas un atkārtojuma mehānisms (ar ierobežojumu), atgriežot kļūdas informāciju modelim, lai labotu izvadi. Pēc atkārtojumu skaita pārsniegšanas jābūt pazemināšanas vai manuālas apstrādes plānam.

4. Arhitektūras līmenis: Atbildību sadale

   • Jānošķir lēmumu pieņemšana no izpildes, veidojot trīs slāņu arhitektūru:
     • Modeļa slānis: Atbild tikai par lēmumu pieņemšanu (izlemt, kuru rīku izsaukt, kādus parametrus ģenerēt).
     • Ietvara slānis: Atbild par izpildes ietvaru, ieskaitot Schema validāciju, rīka izsaukšanu, atkārtojumu apstrādi un rezultātu integrāciju. Tas nodrošina, ka modeļa kļūdas tieši neietekmē rīka drošību un rīka izmaiņas neprasa biežu uzvednes frāžu pielāgošanu.
     • Rīka slānis: Konkrētas biznesa spēju realizācija.
   • LangChain, LlamaIndex un citi ietvari veic tieši šādu darbu.

Pašreizējā risinājuma ierobežojumi: Tas labi tiek galā ar parametru formāta problēmām, bet parametru semantikas (piemēram, "Šanhaja" un "Hu" ekvivalence) validācijas pārklājums joprojām ir nepietiekams. Tas būs nākotnes inženiertehnisks izaicinājums.

Galvenais secinājums: Lai LLM uzticami izsauktu rīkus, būtībā tas ir programmatūras inženierijas jautājums, kas prasa izveidot sistemātisku inženiertehnisku risinājumu no mīkstajiem ierobežojumiem, stingrajiem ierobežojumiem, izpildes drošības tīkla līdz arhitektūras dizainam, nevis tikai paļauties uz uzvednes frāžu optimizāciju.