AI elkarrizketa-galdera 2: Nola bermatu Hizkuntza Eredu Handi (LLM) batek tresnak fidagarritasunez deitzen dituela

Nola bermatu Hizkuntza Eredu Handi (LLM) batek tresnak deitzerakoan fidagarri eta kontrolagarri funtzionatzen duela, eta ez soilik prompt-etan oinarritzea eredua "konbentzitzeko". Maila anitzeko murrizketa-esparru bat ematen da sistematikoki.

Adibidez, eguraldia kontsultatzean, ereduak tresnak deitzerakoan ohikoak diren hiru "asmatze" jokabide:
1. Tresna deitu gabe, zuzenean erantzun asmatua ematea.
2. Tresna deitzerakoan formatu okerreko parametroak pasatzea (adibidez, tresnak "etzi" onartzen ez badu, date="etzi" pasatzea).
3. Parametroen formatua bere kabuz aldatzea (adibidez, "etzi" data zehatz batera bihurtzea), tresnak hori eskatzen ez badu ere.

Arazoaren sustraia ereduaren irteera probabilistikoa dela da funtsean, eta prompt-ek probabilitate-banaketaren gainean "murrizketa bigunak" baino ez dituzte ezartzen, eta ez dute bermatzen ereduak zorrotz beteko dituenik. Eszenatoki konplexuetan, "murrizketa bigun" horiek erraz huts egiten dute.

Arazo hau konpontzeko, maila anitzeko irtenbide ingeniaritzako bat behar da:

1. Lehen maila: Prompt-ak optimizatzea (murrizketa bigunak)

   • Murrizketa-sistemaren abiapuntua da, baina ez da inola ere amaiera.
   • Prompt-ak "eragiketa-kontratu" gisa tratatu behar dira, tresnaren helburua, parametro bakoitzaren mota, mugak eta balio ez-legaleen adibideak argi adieraziz.
   • Few-shot adibideak gehitu behar dira, "sarrera zuzena → deialdi zuzena" ereduak erakutsiz, testuinguruko ikaskuntzaren bidez ereduaren jokabide-eredua ainguratzeko.

2. Bigarren maila: JSON Schema sartzea (murrizketa gogorrak)

   • Hau da "arrazoitze"tik "hesiak jartze"rako pauso gakoa.
   • Parametroen deskribapen naturala ordezkatu egitura definitu, makinaz irakurgarri eta egiaztagarri batekin (JSON Schema). Eremu motak, derrigortasuna, balio posibleen barrutiak zehatz defini daitezke, eta additionalProperties: false ezarriz ereduak definitu gabeko eremurik ez irteeratzeko.
   • API plataforma nagusiek deskodetze fasean bertan egitura horretako irteera murrizketa onartzen dute, formatu-urraketak jatorritik saihestuz.

3. Hirugarren maila: Egiaztapen-konponketa-saiakera begizta bat ezartzea (exekuzio-bermea)

   • Schema izan arren, ereduaren irteera jaso ondoren, sintaxi eta Schema egiaztapena egin behar da.
   • Egiaztapenak huts egiten badu, garbiketa eta saiakera mekanismo automatiko bat diseinatu behar da (goi-mugarekin), errore-mezua ereduari itzuliz irteera zuzentzeko. Saiakera kopurua gaindituz gero, beherapen edo esku-hartze plan bat behar da.

4. Arkitektura mailan: Eginkizunen bereizketa

   • Erabakia eta exekuzioa bereizi behar dira, hiru mailako arkitektura osatuz:
     • Eredu maila: Erabakia hartzeaz soilik arduratzen da (zein tresna deitu eta zein parametro sortu erabakitzea).
     • Marko maila: Exekuzio-markoaz arduratzen da, Schema egiaztapena, tresna deialdia, saiakera kudeaketa eta emaitzen integrazioa barne. Honek bermatzen du ereduaren akatsek ez dutela zuzenean eragiten tresnaren segurtasunean, eta tresna aldaketek ez dutela prompt-ak maiz egokitzea eskatzen.
     • Tresna maila: Gaitasun negozio zehatzen inplementazioa.
   • LangChain, LlamaIndex bezalako markoak horretan ari dira lanean.

Uneko irtenbidearen mugak: parametroen formatua ondo kudeatzen du, baina parametroen semantikaren egiaztapena (adibidez, "Shanghai" eta "Hu" baliokidetasuna) oraindik ez da nahikoa. Hori etorkizuneko ingeniaritza-erronka izango da.

Ondorio nagusia: LLM batek tresnak fidagarritasunez deitzea, funtsean, software ingeniaritzako arazo bat da. Murrizketa bigunetatik, murrizketa gogorretara, exekuzio-bermera eta arkitektura-diseinura doan irtenbide sistematiko bat eraiki behar da, eta ez soilik prompt-ak optimizatzean oinarritu.