Kasu:
- Oskab kirjeldada LLM API päringu põhistruktuuri (lõpp-punkt, mudel, sõnumid, max_tokens)
- Mõistab süsteemi-, kasutaja- ja assistendirollide ning olekuta vestluste ajaloo erinevust
- Oskab lugeda ja tõlgendada tagastatud vastuse välju (sisuplokid, stop_reason, usage).
Eelmistes moodulites kasutasime tehisintellekti vestlusaknast. Kuid kui soovite manustada tehisintellekti oma tootesse, automatiseerimisse või töövoogu, siis vestlusliides seda ei lõika; Mudeliga tuleb ühendus luua programmiliselt, st koodi või automatiseerimistööriistaga. Selle silla nimi on API (Application Programming Interface, leping, mis võimaldab kahel tarkvaral teatud reeglitega suhelda). Kui olete selle üksuse lõpetanud, saate teada, mis kujutab endast LLM-i (Large Language Model) API päringut, mida sõnumirollid teevad ja kuidas vastust lugeda. See on vundament, millele ülejäänud moodul ehitatakse.
Kuidas API töötab?
API põhivoog on järgmine: saadate päringu kindlas vormingus; Server tagastab vastuse kindlas vormingus. LLM-ides on see tavaliselt HTTP-kõne (HTTP: standardprotokoll päringu-vastuse edastamiseks veebis) ühele aadressile (lõpp-punkt, fikseeritud aadress serveris, mis teie päringut käsitleb). Näiteks sõnumside API-s lähevad kõik päringud ühele aadressile ja kantakse kehasse JSON-ina (JavaScript Object Notation – võtme/väärtuse paaridest koosnev tekstivorming, mida saavad lugeda nii inimesed kui ka masinad).
Taotluses täpsustate vähemalt kolm asja:
- Mudel: millist mudelit kasutate (nt kiire ja odav mudel või võimas mudel).
- max_tokens: maksimaalne märkide arv (väikseim ühik, milles teksti töödeldakse, mida töödeldakse üksikasjalikult järgmises ühikus), mida mudel suudab toota; st väljundlimiit.
- sõnumid: vestluse moodustavate sõnumite loend.
Samm-sammult: kuidas taotlust seadistada
- Valmistage ette lõpp-punkt ja mandaadid. Lisate oma API võtme (salajane string, mis tõendab teie identiteeti) päringule päises. Te ei manusta kunagi võtit koodi; Ohutu ladustamise katame 9. üksuses.
- Valige mudel ja väljundlimiit. Kerge mudel + väikesed max_tokenid lihtsa ülesande jaoks; Võimas mudel + suurem limiit keerulise ülesande jaoks.
- Seadistage sõnumiloend. List the system instruction, user message, and past rounds (if any).
- Saatke päring ja analüüsige vastust. Lugege tagastatud JSON-ist tekstisisu, peatamise põhjust ja loa kasutamist.
Sõnumite rollid: süsteem, kasutaja, assistent
Vestlus koosneb sõnumitest, mis on järjestatud ja igal sõnumil on oma roll. Roll määrab, kuidas mudel seda teksti käsitleb.
Roll
Kes kirjutab
Eesmärk
süsteem
Arendaja/operaator
Püsivad juhised, isiksus ja reeglid, mis kehtivad kogu vestluse vältel
kasutaja
lõppkasutaja
Kasutaja praegune küsimus või sisend
assistent
mudel
Mudeli loodud vastus (ja varasemad vastused)
Süsteemi roll on enamiku pakkujate puhul saadaval päringu kehas eraldi süsteemiväljana; kasutaja ja assistent on kirjade loendis loetletud järjestikku. Critical point: the system instruction is the high-level instruction, the user message is the request to be answered at that moment.
{ "model": "claude-opus-4-8", "max_tokens": 1024, "system": "Olete ettevõtte tugiassistent. Vastake lühike, ametlik ja kontrollitud vastus. Ärge koostage teavet, milles te pole kindel.", "sõnumid": [ { "role": "kasutaja", "sisu": "Kuidas alustada oma tagastamisprotsessi?" } ]}
Kõne on kodakondsuseta
Siin on kõige levinum eksiarvamus: LLM API kõned on olekuta – server ei säilita kahe päringu vahel mälu. Mudel ei mäleta teie eelmist taotlust. Kui seadistate mitmevoorulise vestluse, peate iga uue taotlusega eelmised voorud uuesti saatma. Mudeli "mälu" koosneb teie saadetud sõnumite loendist.
{ "modell": "claude-opus-4-8", "max_tokens": 512, "messages": [ { "role": "user", "content": "Tere, minu nimi on Deniz." }, { "role": "assistent", "content": "Tere Deniz, kuidas saan teid aidata?" }, { "role": "user", "content": "Ma just ütlesin oma nime, kas sa mäletad?" } ]}
Kolmandale sõnumile õige vastamine sõltub sellest, kas saadate mõlemad eelmised sõnumid. Kui te seda ei saada, ei tea modell "Meri" ja vastab valesti. See mõjutab otseselt ka kulusid: mida pikem on vestlus, seda suurem on loend, iga päring kulutab rohkem märke.
Näpunäide. Pikkade vestluste puhul vähendab kogu ajaloo saatmise asemel vanade voorude (kokkuvõte + paar viimast vooru) kokkuvõtete tegemine ja teisaldamine kulusid ja säilitab kontekstiakna. Süvendame seda 6. ja 11. üksustes.
Lugege vastust
Kui mudel tagastab vastuse, saate struktureeritud objekti, mitte lihtteksti. Tüüpilised piirkonnad:
{ "id": "msg_01ABC...", "model": "claude-opus-4-8", "role": "assistant", "content": [ { "type": "text", "text": "Tagastamise algatamiseks minge oma konto lehele "Minu tellimused"..." } ], "stop_reason": "usage": "usage" "input_tokens": 47, "output_tokens": 88 }}
- sisu: vastus ise; See on sisuplokkide loend. Tekstiploki tekstiväli on tegelik vastus.
- stop_reason: miks mudel peatus. lõpp_pööre = loomulik lõpp; max_tokens = väljundlimiidi juures kinni (vastus võib olla puudulik); keeldumine = keelduti turvalisuse kaalutlustel. Teie kood peaks alati kõigepealt vaatama stop_reason.
- kasutamine: sisend- ja väljundmärgi numbrid. See on kulude ja limiidi jälgimise alus.
Tähelepanu: kui stop_reason on max_tokens, siis vastust ei lõpetata. Selle käsitlemine "eduka vastusena" ja poole teksti näitamine kasutajale on tootmises üks levinumaid vigu. Kas suurendage max_tokens või kasutage voogesitust.
Nõrk viip / Tugev viip
Sama ülesanne kahe erineva süsteemiviibaga:
# NÕRKOlete assistent. Vasta küsimustele.
# STRONG Olete ettevõtte tugiassistent. Reeglid: - tuginege ainult esitatud poliitikadokumendis sisalduvale teabele; Kui seda dokumendis pole, öelge "Mul pole seda teavet, ma suunan selle vastavasse üksusse." - Vastused ei tohi ületada 3 lauset, olema formaalsed ja selged. - Ärge küsige isikuandmeid (TC ID number, kaardi number) ja ärge korrake. - Ärge arvake, kui te pole kindel.
Võimas versioon; See määratleb ulatuse, vormi, ohutusvaru ja käitumise määramatuse korral. Mudeli väljundi järjepidevus tuleneb otseselt sellest selgusest.
Kolm miniümbrist
Juhtum 1 – tugibot (kodakondsusetuse lõks). E-kaubanduse meeskond võttis roboti otseülekande; Kui kasutaja ütles "tühista eelmine tellimus", "unustas" bot tellimuse numbri. Põhjus: nad saatsid iga päringu ainult viimase sõnumiga. Lahendus: nad lisasid sõnumiloendisse viimased 6 vooru. Tulemus: kontekst säilinud, kuid sisend päringu kohta suurenes 40 märgilt ~ 600 märgini – katame 2. üksuse kuluõpetuse.
Juhtum 2 – mittetäielik lepingu kokkuvõte. Juriidiline meeskond koostas 10-leheküljelisi lepinguid; max_tokens: 300 jäi madalaks, kokkuvõtted katkesid lause keskel. stop_reason oli max_tokens iga kord, kuid keegi ei otsinud. suurendati max_tokens 1500-ni ja lisati stop_reason check; Kärbitud koondmäär langes 18%-lt 0%-le.
3. juhtum – rollide segamine. Turundusmeeskond kirjutas kõik juhised kasutaja sõnumisse, jättes süsteemi tühjaks. Kui kasutaja sisend segatakse juhistega, järgib mudel mõnikord kasutaja käsku "unusta eelmised reeglid". Nad kolisid püsivad reeglid süsteemi; Eraldades kasutaja sisendi juhistest, vähenesid reeglite rikkumised oluliselt.
Levinud vead
- Mineviku saatmise unustamine: arvatakse, et mudel "ei mäleta"; samas kui see on kodakondsuseta. Sa kannad konteksti.
- Ei vaata 'stop_reason': vastus peatati max_tokensiga loetakse lõpetatuks.
- Juhendi manustamine jaotisesse "kasutaja": püsivad reeglid süsteemi; kiirsisend läheb kasutajale. Segamine tekitab turvaauke.
- Segib "sisu" tavalise stringiga: vastus on plokkide loend; loe esimese tekstiploki tekstivälja, kontrolli selle tüüpi enne sisu[0] hankimist pimeindeksiga.
- Võtme manustamine koodi: kasutage keskkonnamuutujat (ühik 9).
Deeper: sisuplokid ja mitmeosalised vastused
Mõistmine, miks vastuse sisuväli on loend, on hiljem ettetulevate täiustatud funktsioonide jaoks ülioluline. Mõnikord tagastab mudel mitte ühe tekstiploki, vaid mitu plokki: mõtlemisplokk, millele järgneb tekstiplokk; või tekstiplokk, millele järgneb tööriista kasutamise plokk. Seetõttu on sisu[0] pimesi arvestamine vastuseks habras. Õige lähenemine on loendi läbimine ja tüübi järgi sortimine: kogute plokkide tekstisisu, mille tüübiväli on tekst, ja käsitlete teisi tüüpe (mõtlemine, tööriist) eraldi.
Praktikas see eristus seisneb selles, et saate logida mudeli arutluskäiku (kui see on olemas) ilma seda kasutajale avaldamata, suunata tööriistakutsed eraldi loogikale ja printida ekraanile ainult tegeliku vastuse. Mooduli edenedes (eriti üksustes 4 ja 11) näete, kui kasulik on see ploki struktuur väljundi valideerimiseks ja suunamiseks.
Veel üks praktiline punkt: pääsete samale mudelile juurde erinevatelt pakkujaplatvormidelt (otsene API, pilveteenuse pakkuja kaudu). Kuigi lõpp-punkti aadress ja autentimisvorming võivad muutuda, jäävad põhimõisted, nagu sõnumirollid, olekuta olek ja vastuse struktuur, samaks. Seega kehtivad selle seadme põhitõed olenemata kasutatavast platvormist.
Kokkuvõttes
LLM API päring koosneb mudelist, väljundlimiidist ja sõnumiloendist; rollid (süsteem, kasutaja, assistent) määravad mudeli käitumise. Kõned on kodakondsuseta: iga päringuga kaasneb kontekst. Vastus on struktureeritud objekt; Sisu, stop_reason ja kasutusväljade lugemine ja tõlgendamine on tootmise vastupidavuse aluseks.
Rakenduse ülesanne
Valige oma erialalt ülesanne (nt sissetulevate e-kirjade sorteerimine, lühikokkuvõtete tegemine). Paberile: (1) kirjutage 4-5 reegliga süsteemiviip, (2) seadistage näidiskasutaja teade ja 2-ringiline ajalugu, kui see on olemas, (3) määrake max_tokensi mõistlik väärtus ja kirjutage põhjendus, (4) loetlege, milliseid stop_reason väärtusi tagastatud vastuses käsitlete ja kuidas.
kontrollnimekiri
- [ ] Oskan üles lugeda päringu kolm kohustuslikku osa (mudel, max_tokens, sõnumid).
- [ ] Oskan selgitada süsteemi-, kasutaja- ja assistendirollide erinevust.
- [ ] Ma tean, et kõned on kodakondsuseta ja mul on vaja minevikku kanda.
- Saan lugeda ja kommenteerida [ ] sisu, stop_reason ja kasutusvälju.
- [ ] Max_tokensi abil saan märgata ja käsitleda kärbitud vastust.