Kaip pridėti DI funkcijas prie savo programėlės

Norėdami pridėti DI funkcijas prie programėlės, iš serverio kvieskite didelio kalbos modelio (LLM) API: siųskite jam aiškias instrukcijas ir atitinkamus duomenis bei panaudokite grįžusį rezultatą. Daugelis naudingų funkcijų priklauso vienam iš keturių modelių – santraukai, pokalbiui, struktūrizuotų duomenų išgavimui ir klasifikavimui – o kiekvienas jų – keliasdešimties eilučių kodas, kurį DI programėlių kūrimo įrankis gali parašyti už jus. Darbas, lemiantis, ar funkcija yra verta, slypi aplink tą iškvietimą: API raktą laikyti serveryje, kontroliuoti išlaidas vienam naudotojui ir patikrinti rezultatą prieš jam pasitikint.

Keturi modeliai, kuriais grindžiama dauguma DI funkcijų

Išgavimas ir klasifikavimas dažnai yra vertingiausi ir mažiausiai matomi. Jie tyliai sutaupo kiekvieno įrašo kelias minutes, o kadangi rezultatas turi fiksuotą formą, jį galima automatiškai patikrinti. Pokalbis yra labiausiai matomas, bet sunkiausiai įgyvendinamas, ir jam skirtas atskiras gidas: kaip sukurti DI pokalbių roboto programėlę.

Kaip tai įsilieja į programėlę

Kiekvienas modelis turi tą pačią struktūrą:

1. Naudotojas veikia – spaudžia „Apibendrinti“, įkelia failą, siunčia žinutę.
2. Jūsų priekinė dalis kreipiasi į jūsų serverį, o ne į DI tiekėją.
3. Jūsų serveris sudaro užklausą: sisteminės instrukcijos, naudotojo įvestis ir visi modeliui reikalingi duomenys iš jūsų duomenų bazės – tik tie, kuriuos šis naudotojas gali matyti.
4. Jūsų serveris kreipiasi į LLM API naudodamas raktą, saugomą aplinkos kintamajame.
5. Jūsų serveris patikrina atsakymą – galiojantis JSON, žinoma etiketė, protinga ilgis – ir jį išsaugo arba grąžina.
6. Priekinė dalis jį parodo, ilgesniems atsakymams rodydama tekstą, kai jis ateina.

Raktas serveryje, 4 žingsnyje, ir niekada nepasiekia naršyklės. Jei API sąvoka nauja, trumpą įvadą rasite kas yra API, o kaip naudoti LLM API išsamiau aprašo žetonus, modelius ir raktus.

Tiekėjo ir modelio pasirinkimas

Pagrindiniai tiekėjai – OpenAI, Anthropic, Google ir kiti – siūlo teksto API su panašia struktūra. Renkantis naudingi klausimai:

• Kokybė jūsų užduočiai. Išbandykite keletą tikrų savo programėlės pavyzdžių dviejuose ar trijuose modeliuose. Skirtumai dažnai aiškesni jūsų duomenyse nei bendruose etalonuose.
• Dydis ir kaina. Tiekėjai siūlo didesnius, galingesnius modelius ir mažesnius, pigesnius, greitesnius. Klasifikavimas ir paprastas išgavimas dažnai gerai veikia mažame modelyje; ilgam samprotavimui ar subtiliam rašymui gali prireikti didesnio.
• Struktūrizuotas rezultatas. Išgavimui ir klasifikavimui rinkitės API funkciją, kuri verčia modelį grąžinti JSON pagal jūsų pateiktą schemą, o ne analizuoti laisvo teksto atsakymą.
• Duomenų tvarkymas. Perskaitykite tiekėjo sąlygas dėl to, ar API įvestys saugomos arba naudojamos mokymui, ir ar tai tinka duomenims, kuriuos jums pateikia naudotojai.
• Limitai. Naujos paskyros dažnai turi žemesnius užklausų limitus; patikrinkite juos prieš paleidimą.

Modelių pavadinimai ir kainos dažnai keičiasi, todėl kodas turėtų nuskaityti modelio pavadinimą iš konfigūracijos, o ne jį kietai įrašyti keliose vietose.

Funkcijos pridėjimas žingsnis po žingsnio

Imkime konkretų pavyzdį: nedidelį CRM, kur kiekvienas kontaktas turi ilgą pastabų istoriją.

1. Išsaugokite raktą. Sukurkite raktą tiekėjo valdymo skydelyje ir įrašykite jį kaip serverio pusės paslaptį, pavyzdžiui, OPENAI_API_KEY arba ANTHROPIC_API_KEY.

2. Paprašykite vienos siauros funkcijos:

Pridėk mygtuką „Apibendrinti“ kontakto puslapyje. Serveryje siųsk paskutines 20 kontakto pastabų tiekėjui [PROVIDER], naudodamas paslaptį [ENV_NAME], su instrukcija parašyti tris punktus: dabartinė būsena, atviri klausimai, kitas žingsnis. Įtrauk tik tas pastabas, kurias prisijungęs naudotojas gali matyti. Rodyk įkrovimo būseną, išsaugok santrauką su laiko žyma ir rodyk „Šiuo metu nepavyko apibendrinti“, jei užklausa nepavyksta. Niekada nesiųski rakto į naršyklę.

3. Pridėkite išgavimą ten, kur jis sutaupo rašymo:

Kai naudotojas įklijuoja el. laiško parašą į lauką „Greitas pridėjimas“, kvieskite [PROVIDER] serveryje ir grąžinkite JSON su vardu, įmone, pareigomis, el. paštu ir telefonu, naudodami tiekėjo struktūrizuoto rezultato funkciją. Serveryje patikrinkite JSON, įrašykite jį į naujo kontakto formą ir leiskite naudotojui redaguoti prieš išsaugant. Palikite laukus tuščius, o ne spėkite.

Svarbiausia čia – „leisti naudotojui redaguoti prieš išsaugant“: modelis siūlo, žmogus sprendžia.

4. Klasifikuokite fone:

Kai atkeliauja nauja palaikymo užklausa, klasifikuok ją tiksliai į vieną iš: sąskaitos, klaida, funkcijos užklausa, prieigos prie paskyros, kita. Naudok mažą, pigų modelį. Jei atsakymas nėra viena iš tų etikečių, įrašyk „kita“. Rodyk etiketę kaip redaguojamą žymę.

5. Išbandykite su netvarkingais tikrais duomenimis – ilgos pastabos, tuščios pastabos, kitomis kalbomis, parašas be telefono numerio – ir prieš paleidžiant peržiūrėkite dvidešimt rezultatų greta.

Veiksmingų instrukcijų rašymas

Instrukcijos, kurias siunčiate su kiekviena užklausa (dažnai vadinamos sistemine užklausa), yra vieta, kur atsiranda kokybė.

• Pasakykite, kam tai skirta ir kas yra gerai. „Santraukas per 10 sekundžių prieš skambutį perskaito pardavėjas“ suteikia modeliui tikslą.
• Nustatykite formatą. Tikslus punktų skaičius, ilgio riba, laukai, etiketės.
• Pasakykite, ką daryti, kai neaišku. „Jei pastabose nėra kito žingsnio, parašyk „Kitas žingsnis neįrašytas““. Tai sumažina išgalvotų atsakymų skaičių.
• Pateikite dviejus ar tris pavyzdžius gerų įvesčių ir išvesčių išgavimui ir klasifikavimui.
• Laikykite instrukcijas atskirai nuo naudotojo turinio ir aiškiai pažymėkite naudotojo turinį, kad modelis galėtų jas atskirti.

Laikykite užklausas failuose savo kodo bazėje, kad jos būtų versijuojamos ir peržiūrimos kaip bet kuris kitas kodas.

Išlaidų kontrolė

LLM API mokama už žetonus – nedidelius teksto gabalėlius – tiek už tai, ką siunčiate, tiek už tai, kas grįžta. Išlaidos auga, kai konteksto kiekis vienai užklausai dauginamas iš to, kaip dažnai ji vykdoma. Praktinės kontrolės priemonės:

• Siųskite tik tai, kas reikalinga. Paskutines 20 pastabų, o ne visą istoriją. Ilgus dokumentus sutrumpinkite arba suskaidykite.
• Naudokite mažiausią modelį, kuris atlieka darbą. Prieš pasirinkdami didžiausią, išbandykite.
• Apribokite išvesties ilgį API maksimalaus žetonų nustatymu.
• Talpinkite rezultatus į podėlį. Saugokite santrauką ir generuokite ją iš naujo tik pasikeitus šaltiniui, o ne kiekvieno puslapio peržiūros metu.
• Ribokite vienam naudotojui. Dienos limitas pagal paskyrą ar planą sustabdo vieną intensyvų naudotoją ar vieną scenarijų nuo sąskaitos padidinimo.
• Ribokite užklausų dažnį galiniam taškui kaip bet kuriam kitam brangiam maršrutui.
• Nustatykite biudžetą ar įspėjimą tiekėjo valdymo skydelyje ir po paleidimo tikrinkite naudojimą kas savaitę.
• Registruokite žetonų naudojimą pagal funkciją, kad žinotumėte, kiek kainuoja kiekviena.

Jei DI funkcijos yra jūsų produkto esmė, įtraukite jų veikimo kainą į kainodarą, o ne ją absorbuokite.

Saugumas ir pasitikėjimas

DI rezultatas yra tikimybinis. Jis gali būti klaidingas, skambėdamas įtikinamai, ir jį gali paveikti tekstas, kurį jis skaito. Kurkite atsižvelgdami į tai:

• Laikykite rezultatą nepatikimu įvedimu. Patikrinkite struktūrą, prieš atvaizduodami HTML išvalykite, ir niekada nevykdykite jo kaip kodo ar duomenų bazės užklausų.
• Palikite žmogų į procesą bet kam, kas turi pasekmių – el. laiško siuntimui, įrašo keitimui, mokėjimo grąžinimui. Modelis parengia juodraštį; žmogus patvirtina.
• Saugokitės užklausos injekcijos. Dokumente ar žinutėje gali būti tokio teksto kaip „ignoruok savo instrukcijas“. Apribokite, ką modelis gali matyti, iki to, ką dabartinis naudotojas gali matyti, ir neduokite jam įrankių, kurie gali atlikti jautrius veiksmus, kol jūsų kodas nepatikrino leidimų.
• Pažymėkite DI turinį, kad naudotojai žinotų, jog santrauka ar pasiūlymas buvo sugeneruoti, ir galėtų jį patikrinti.
• Tinkamai tvarkykite klaidas. Tiekėjai turi gedimų ir užklausų limitų. Nustatykite laiko limitą, rodykite aiškų pranešimą ir leiskite likusiai programėlei veikti toliau.
• Stebėkite, ką siunčia naudotojai. Laisvo teksto įvestims apsvarstykite moderavimo žingsnį ir privatumo politikoje aiškiai nurodykite, kad turinį tvarko trečiosios šalies DI tiekėjas.

Platesnis patikrinimų sąrašas pateiktas saugumo kontroliniame sąraše DI kuriamoms programėlėms.

Dažnos klaidos

• Pradėti nuo bendro pokalbių roboto, kai vienas mygtukas „Apibendrinti“ ar „Kategorizuoti“ padėtų daugiau žmonių.
• Raktas priekinio kodo viduje arba viešoje saugykloje.
• Visos duomenų bazės siuntimas kaip kontekstas – tai lėta, brangu ir gali atskleisti kitų naudotojų duomenis.
• Pasitikėjimas laisvo teksto rezultatu, kai schema ar fiksuotas etikečių rinkinys leistų jį patikrinti.
• Nėra limitų vienam naudotojui, o tai paaiškėja, kai ateina pirmoji sąskaita.

DI funkcijų pridėjimas su Mythex

Mythex DI pridedate į savo programėlę pokalbyje, naudodami savo tiekėjo raktą. Laikykite raktą kaip projekto paslaptį – kai agentui jo reikia, Mythex pokalbyje parodo paslapčių kortelę, todėl raktą į pokalbį įklijuoti nereikia – o agentas parašo serverio maršrutą, užklausas ir sąsają. Jūsų programėlės DI naudojimą apmoka jūsų tiekėjas, atskirai nuo Mythex kreditų, kuriuos išleidžiate kurdami. Pradinę užklausą rasite dokumentacijoje: pridėkite DI funkcijas su savo API raktais.

Klausimai