Uzziniet, kā pārvērst vietējo lielā valodas modeļa instalāciju par funkcionālu un autonomu mākslīgā intelekta aģentu, kas spēj izmantot ārējos rīkus.
No vienkāršas tērzēšanas līdz patstāvīgai rīcībai
Pēdējo gadu laikā vietējo lielo valodas modeļu (LLM) izmantošana ir kļuvusi neticami pieejama. Pateicoties tādiem rīkiem kā Ollama un Llama.cpp, jebkurš entuziasts vai uzņēmums var palaist jaudīgus modeļus uz sava datora vai servera, nodrošinot pilnīgu datu privātumu un neatkarību no trešo pušu mākoņpakalpojumiem. Tomēr standarta valodas modelis pats par sevi ir izolēts - tas spēj tikai ģenerēt nākamo ticamāko vārdu, balstoties uz saviem vēsturiskajiem mācību datiem.
Lai pārvarētu šo ierobežojumu, nozarē strauji attīstās jauna koncepcija - rīkus izmantojoši mākslīgā intelekta aģenti (tool-using agents). Šādi aģenti spēj ne tikai atbildēt uz jautājumiem, bet arī patstāvīgi pieņemt lēmumus, kad un kādus ārējos rīkus izmantot, lai atrisinātu lietotāja uzdotos uzdevumus. Šādu sistēmu izstrādi un integrāciju biznesā atvieglo mākslīgā intelekta asistenti uzņēmumiem, kas palīdz automatizēt ikdienas procesus un savienot AI ar reāliem datiem.
Mākslīgā intelekta aģents nav vienkārši statisks modelis, kas atbild uz jautājumiem. Tas ir dinamisks dzinējs, kas spēj patstāvīgi plānot darbības, izvēlēties nepieciešamos rīkus un reaģēt uz mainīgiem apstākļiem.
Kāpēc standarta LLM nespēj atrisināt sarežģītus uzdevumus
Galvenā problēma ar pamata LLM ir to statiskā daba. Modeļiem ir tā saucamais zināšanu datuma ierobežojums (knowledge cutoff), un tie nezina neko par notikumiem pēc šī datuma. Tāpat tie nespēj piekļūt jūsu uzņēmuma iekšējiem failiem, veikt aprēķinus bez kļūdām vai nosūtīt e-pastu.
Lai atrisinātu šo problēmu, aģenta arhitektūra ievieš rīku izmantošanas ciklu. Kad lietotājs uzdod jautājumu, modelis vispirms izvērtē, vai tam ir nepieciešama papildu informācija vai darbība. Ja jā, modelis izdod strukturētu komandu (parasti JSON formātā), kas norāda, kurš rīks ir jāizpilda un ar kādiem parametriem. Ārējā lietojumprogramma izpilda šo rīku, iegūst rezultātu un nosūta to atpakaļ modelim, kas pēc tam sagatavo gala atbildi lietotājam.
| Funkcija | Standarta vietējais LLM | Rīkus izmantojošs AI aģents |
|---|---|---|
| Datu aktualitāte | Ierobežota ar modeļa apmācības datiem | Reāllaika piekļuve datiem caur API vai meklētājiem |
| Darbību veikšana | Tikai teksta un koda ģenerēšana | Spēj palaist kodu, veikt datubāzes vaicājumus un sūtīt API pieprasījumus |
| Problēmu risināšana | Viena soļa atbilde, balstoties uz minējumiem | Daudzsoļu plānošana, rezultātu izvērtēšana un pašlabošanās |
| Sistēmu integrācija | Pilnībā izolēta vide bez piekļuves ārpusei | Savienots ar uzņēmuma iekšējām sistēmām un datubāzēm |
Kā darbojas rīku izmantošanas mehānisms
Kā aprakstīts detalizētajā Towards Data Science analītiskajā materiālā, pāreja no parasta modeļa uz aģentu sastāv no vairākiem secīgiem soļiem, kurus var realizēt ar programmēšanas palīdzību. Galvenais uzdevums ir iemācīt vietējam modelim saprast pieejamos rīkus un pareizi tos izsaukt.
Process parasti sastāv no šādiem soļiem:
- Sistēmas instrukcija (System Prompt): Modelim tiek iedots precīzs apraksts par to, kādi rīki ir pieejami un kādā formātā tam ir jāpieprasa to izmantošana.
- Rīku definēšana: Katrs rīks tiek aprakstīts ar detalizētu JSON shēmu, lai modelis precīzi zinātu, kādus parametrus tam nepieciešams padot.
- Atbildes parsēšana: Izstrādātā programmatūra pārtver modeļa ģenerēto tekstu, identificē rīka izsaukšanas komandu, to izpilda vietējā vidē un atgriež rezultātu modelim.
Zemāk ir redzams vienkāršots piemērs tam, kā tiek definēta rīka shēma, kuru pēc tam saprot vietējais LLM, lai palīdzētu tam izlemt par funkcijas izsaukšanu.
{
"name": "get_current_stock_price",
"description": "Iegūst pašreizējo akciju cenu konkrētam uzņēmuma simbolam",
"parameters": {
"type": "object",
"properties": {
"ticker": {
"type": "string",
"description": "Akciju simbols, piemēram, AAPL vai TSLA"
}
},
"required": ["ticker"]
}
}Kad lietotājs vaicās "Cik šobrīd maksā Apple akcijas?", modelis sapratīs, ka tam pašam nav šo datu, un izvadīs strukturētu tekstu, pieprasot funkcijas get_current_stock_price palaišanu ar parametru ticker: "AAPL".
Ierobežojumi un drošības aspekti vietējā vidē
Lai gan autonomi aģenti izskatās daudzsološi, to ieviešanai ir savi riski un tehniskie šķēršļi, kurus nevar ignorēt, īpaši strādājot vietējās infrastruktūras ietvaros.
Ļaujot AI aģentam patstāvīgi izpildīt kodu vai veikt izmaiņas datubāzēs, pastāv nopietni drošības riski. Nekad nedodiet aģentam neierobežotu piekļuvi sistēmas komandrindai vai kritiskiem uzņēmuma datiem bez iepriekšējas pārbaudes un apstiprinājuma mehānisma.
Papildus drošībai ir jāņem vērā arī vietējo modeļu kapacitāte. Mazāki modeļi (piemēram, 7 vai 8 miljardu parametru modeļi) mēdz pieļaut kļūdas strukturētu JSON datu ģenerēšanā. Tie var sajaukt parametrus vai izdomāt neeksistējošus rīkus. Tāpēc veiksmīgai aģenta darbībai bieži ir nepieciešams izmantot rūpīgi pielāgotus modeļus, kas ir īpaši apmācīti funkciju izsaukšanai (function calling).
Secinājumi
Pāreja no vienkāršas vietējās tērzēšanas saskarnes uz rīkus izmantojošu aģentu ir milzīgs solis uz priekšu AI lietderībā. Tas ļauj pārvērst pasīvu teksta ģeneratoru par aktīvu palīgu, kas spēj integrēties ar jūsu esošajām sistēmām, datubāzēm un darba plūsmām. Lai gan izstrādes sākumposmā ir jāsaskaras ar tādām problēmām kā precīza komandu parsēšana un drošības nodrošināšana, šīs tehnoloģijas sniegtā neatkarība un efektivitāte pilnībā attaisno ieguldīto darbu.
