AI Panayam Tanong Dalawa: Paano Tiyakin na Maaasahan ang Pagtawag ng Tool ng Malaking Modelo ng Wika (LLM)

Paano matiyak na ang malaking modelo ng wika (LLM) ay maaasahan at kontrolado kapag tumatawag ng tool, at hindi lamang umaasa sa prompt upang "kumbinsihin" ang modelo. Kailangan ng sistematikong multi-level na balangkas ng pagpigil.

Halimbawa ng pagtatanong ng panahon, tatlong karaniwang "gawa-gawa" na pag-uugali ng modelo sa pagtawag ng tool:
1. Hindi tumatawag ng tool, direktang gumagawa ng sagot.
2. Nagpapasa ng maling format na parameter kapag tumatawag ng tool (hal. hindi sinusuportahan ng tool ang "makalawa", ngunit nagpapasa ng parameter date="makalawa").
3. Sariling pagpapasyang mag-convert ng format ng parameter (hal. basta na lang ginagawang tiyak na petsa ang "makalawa"), kahit hindi ito kinakailangan ng tool.

Ang ugat ng problema ay ang output ng modelo ay probabilistiko sa kalikasan, at ang prompt ay nagbibigay lamang ng "malambot na pagpigil" sa distribusyon ng probabilidad, hindi isang mekanismong pumipilit sa modelo na mahigpit na sumunod. Sa mga kumplikadong sitwasyon, ang "malambot na pagpigil" na ito ay madaling mabigo.

Upang malutas ang problemang ito, kailangan ng isang multi-level na solusyong pang-inhinyeriya:

1. Unang Antas: Pag-optimize ng Prompt (Malambot na Pagpigil)

   • Ang posisyon ay simula ng sistema ng pagpigil, ngunit tiyak na hindi katapusan.
   • Dapat ituring ang prompt bilang "kontrata ng operasyon", malinaw na ipaliwanag ang gamit ng tool, uri ng bawat parameter, hangganan, at magbigay ng mga halimbawa ng ilegal na halaga.
   • Dapat magdagdag ng Few-shot na halimbawa, sa pamamagitan ng pagpapakita ng mga halimbawa ng "tamang input → tamang tawag", gamit ang kontekstwal na pag-aaral upang i-angkla ang pattern ng pag-uugali ng modelo.

2. Ikalawang Antas: Pagpapakilala ng JSON Schema (Matigas na Pagpigil)

   • Ito ang mahalagang hakbang mula sa "makipag-usap" hanggang sa "maglagay ng rehas".
   • Gamitin ang machine-readable at verifiable na structured na depinisyon (JSON Schema) upang palitan ang natural language na paglalarawan ng mga parameter. Maaaring mahigpit na tukuyin ang uri ng field, kung kinakailangan, saklaw ng enum, at sa pamamagitan ng pagtatakda ng additionalProperties: false ay maaaring ipagbawal ang modelo na mag-output ng anumang hindi tinukoy na field.
   • Sinusuportahan ng mga pangunahing API platform ang ganitong structured output constraint sa yugto ng pag-decode ng modelo, upang maiwasan ang paglabag sa format mula sa pinagmulan ng pagbuo.

3. Ikatlong Antas: Pagbuo ng Loop ng Pagpapatunay-Pag-aayos-Pagsubok Muli (Pagpapatupad ng Safety Net)

   • Kahit may Schema, kailangan pa ring magsagawa ng syntax at Schema validation pagkatapos makuha ang output ng modelo.
   • Kapag nabigo ang validation, dapat magdisenyo ng awtomatikong paglilinis at mekanismo ng pagsubok muli (na may limitasyon), na ibabalik ang error message sa modelo upang itama ang output. Kapag lumampas na sa bilang ng pagsubok muli, kailangan ng downgrade o manual na solusyon.

4. Antas ng Arkitektura: Paghihiwalay ng Responsibilidad

   • Dapat paghiwalayin ang desisyon at pagpapatupad, na bumubuo ng tatlong antas na arkitektura:
     • Antas ng Modelo: Responsable lamang sa desisyon (paghusga kung aling tool ang tatawagin, anong mga parameter ang bubuo).
     • Antas ng Framework: Responsable sa pagpapatupad ng framework, kabilang ang Schema validation, pagtawag ng tool, paghawak ng pagsubok muli, at pagsasama ng resulta. Tinitiyak nito na ang pagkakamali ng modelo ay hindi direktang makakaapekto sa kaligtasan ng tool, at ang pagbabago ng tool ay hindi nangangailangan ng madalas na pag-aayos ng prompt.
     • Antas ng Tool: Konkretong implementasyon ng kakayahan sa negosyo.
   • Ang mga framework tulad ng LangChain, LlamaIndex ay gumagawa ng ganitong gawain.

Limitasyon ng kasalukuyang solusyon: Mahusay na mahawakan ang format ng parameter, ngunit ang pagpapatunay sa semantika ng parameter (tulad ng pagkakatumbas ng "Shanghai" at "Hu") ay hindi pa sapat. Ito ang magiging hamon sa inhinyeriya na kailangang harapin sa hinaharap.

Pangunahing Konklusyon: Ang pagpapaaasahan ng LLM sa pagtawag ng tool ay, sa esensya, isang problema sa software engineering, na nangangailangan ng sistematikong solusyong pang-inhinyeriya mula sa malambot na pagpigil, matigas na pagpigil, pagpapatupad ng safety net, hanggang sa disenyo ng arkitektura, hindi lamang umaasa sa pag-optimize ng prompt.