Fitimet:
- Mund të përshkruajë strukturën bazë të një kërkese LLM API (pika fundore, modeli, mesazhet, max_tokens)
- Kupton ndryshimin midis roleve të sistemit, përdoruesve dhe ndihmësve dhe historisë së bisedave pa shtetësi
- Mund të lexojë dhe interpretojë fushat (blloqet e përmbajtjes, stop_arsyeja, përdorimi) të përgjigjes së kthyer
Në modulet e mëparshme, ne përdorëm inteligjencën artificiale nga një dritare bisede. Por nëse doni të futni AI në produktin tuaj, automatizimin ose rrjedhën e punës, një ndërfaqe chat nuk do ta shkurtojë atë; Ju duhet të lidheni me modelin në mënyrë programore, domethënë me kod ose një mjet automatizimi. Emri i kësaj ure është API (Application Programming Interface, kontrata që lejon dy softuer të flasin me rregulla të caktuara). Kur të përfundoni këtë njësi, do të dini se çfarë përbën një kërkesë API LLM (Large Language Model), çfarë bëjnë rolet e mesazheve dhe si ta lexoni përgjigjen. Ky është themeli mbi të cilin do të ndërtohet pjesa tjetër e modulit.
Si funksionon API?
Rrjedha bazë në API është kjo: ju dërgoni një kërkesë në një format të caktuar; Serveri kthen një përgjigje në një format specifik. Në LLM, kjo është zakonisht një thirrje HTTP (HTTP: protokoll standard për bartjen e përgjigjes së kërkesës në ueb) në një adresë të vetme (pikë fundore, adresa fikse në serverin që trajton kërkesën tuaj). Për shembull, në një API të mesazheve, të gjitha kërkesat shkojnë në një adresë të vetme dhe mbahen në trup si JSON (JavaScript Object Notation - një format teksti i përbërë nga çifte çelësi/vlerash që mund të lexohen si nga njerëzit ashtu edhe nga makinat).
Në një kërkesë, ju specifikoni të paktën këto tre gjëra:
- Modeli: Cilin model do të përdorni (p.sh. një model i shpejtë dhe i lirë ose një model i fuqishëm).
- max_tokens: Numri maksimal i shenjave (njësia më e vogël në të cilën përpunohet teksti, e cila do të përpunohet në detaje në njësinë tjetër) që modeli mund të prodhojë; dmth kufiri i daljes.
- mesazhet: Lista e mesazheve që përbëjnë bisedën.
Hap pas hapi: Si të vendosni një kërkesë
- Përgatitni pikën përfundimtare dhe kredencialet. Ju shtoni çelësin tuaj API (vargun sekret që vërteton identitetin tuaj) në kërkesë në një kokë. Ju kurrë nuk e futni çelësin në kod; Ne do të mbulojmë ruajtjen e sigurt në njësinë 9.
- Zgjidhni modelin dhe kufirin e prodhimit. Model i lehtë + max_tokens të vegjël për një detyrë të thjeshtë; Model i fuqishëm + limit më i madh për një detyrë komplekse.
- Vendosni listën e mesazheve. List the system instruction, user message, and past rounds (if any).
- Dërgoni kërkesën dhe analizoni përgjigjen. Lexoni përmbajtjen e tekstit, ndaloni përdorimin e arsyes dhe tokenit nga JSON i kthyer.
Rolet e mesazhit: sistemi, përdoruesi, asistenti
Një bisedë përbëhet nga mesazhe të renditura në një sekuencë, dhe çdo mesazh ka një rol. Roli përcakton se si modeli e trajton atë tekst.
Roli
Kush shkruan
Qëllimi
sistemi
Zhvillues/operator
Udhëzime të përhershme, personalitet dhe rregulla që zbatohen gjatë gjithë bisedës
përdorues
përdoruesi përfundimtar
Pyetja ose hyrja aktuale e përdoruesit
asistent
model
Përgjigja e prodhuar nga modeli (dhe përgjigjet e mëparshme)
Roli i sistemit është i disponueshëm si një fushë e veçantë e sistemit në trupin e kërkesës në shumicën e ofruesve; përdoruesi dhe ndihmësi renditen në mënyrë sekuenciale në listën e mesazheve. 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": "Ju jeni një asistent mbështetës i korporatës. Jepni një përgjigje të shkurtër, zyrtare dhe të verifikuar. Mos krijoni informacione për të cilat nuk jeni të sigurt.", "mesazhe": [ { "role": "përdoruesi", "How do të kthej procesin tim?": } ]}
Fjalimi është pa shtetësi
Këtu është keqkuptimi më i zakonshëm: Thirrjet LLM API janë pa shtetësi - serveri nuk ruan memorie midis dy kërkesave. Modeli nuk e mban mend kërkesën tuaj të mëparshme. Nëse po konfiguroni një bisedë me shumë raunde, do t'ju duhet të ridërgoni raundet e kaluara me çdo kërkesë të re. "Kujtesa" e modelit përbëhet nga një listë e mesazheve që keni dërguar.
{ "model": "claude-opus-4-8", "max_tokens": 512, "messages": [ { "role": "user", "content": "Përshëndetje, emri im është Deniz." }, { "role": "assistant", "content": "Përshëndetje Deniz, si mund të të ndihmoj?" }, { "role": "user", "content": "Sapo thashë emrin tim, a ju kujtohet?" } ]}
Përgjigja e saktë e mesazhit të tretë varet nga dërgimi i të dy mesazheve të mëparshme. Nëse nuk e dërgoni, modelja nuk do ta dijë "Det" dhe do të përgjigjet gabim. Kjo gjithashtu ndikon drejtpërdrejt në kosto: sa më e gjatë të jetë biseda, aq më e madhe është lista, çdo kërkesë konsumon më shumë token.
Këshillë: Në biseda të gjata, përmbledhja dhe lëvizja e raundeve të vjetra (përmbledhje + raundet e fundit) në vend të dërgimit të të gjithë historikut ul koston dhe ruan dritaren e kontekstit. Këtë do ta thellojmë në njësitë 6 dhe 11.
Lexoni Përgjigjen
Kur modeli kthen një përgjigje, ju merrni një objekt të strukturuar, jo tekst të thjeshtë. Zonat tipike:
{ "id": "msg_01ABC...", "model": "claude-opus-4-8", "role": "asistent", "përmbajtje": [ { "type": "tekst", "tekst": "Për të inicuar një kthim, shko te faqja "Porositë e mia" në llogarinë tënde..." } ] ], "stop": "input_tokens": 47, "output_tokens": 88 }}
- përmbajtja: Vetë përgjigja; Është një listë e blloqeve të përmbajtjes. Fusha e tekstit të bllokut të tekstit është përgjigjja aktuale.
- stop_reason: Pse modeli u ndal. fund_kthesë = fund natyral; max_tokens = mbërthyer në kufirin e daljes (përgjigja mund të jetë e paplotë); refuzim = refuzohet për arsye sigurie. Kodi juaj duhet të shikojë gjithmonë stop_reason së pari.
- përdorimi: Numrat e shenjave hyrëse dhe dalëse. Është baza e ndjekjes së kostos dhe kufirit.
Kujdes: Nëse stop_reason është max_tokens, përgjigja nuk përfundon. Trajtimi i kësaj si një "përgjigje e suksesshme" dhe shfaqja e gjysmës së tekstit tek përdoruesi është një nga gabimet më të zakonshme në prodhim. Ose rrit max_tokens ose përdor transmetimin.
Prompt i dobët / Prompt i fortë
E njëjta detyrë me dy kërkesa të ndryshme të sistemit:
# I DOBËT Ju jeni një asistent. Përgjigjuni pyetjeve.
# STRONGJu jeni një asistent mbështetës i korporatës. Rregullat: - Mbështetuni vetëm në informacionin në dokumentin e politikave të ofruar; Nëse nuk është në dokument, thuaj "Nuk e kam këtë informacion, po e drejtoj në njësinë përkatëse". - Përgjigjet nuk duhet të kalojnë 3 fjali, të jenë formale dhe të qarta. - Mos kërkoni të dhëna personale (numrin e ID të TC, numrin e kartës) dhe mos përsëritni. - Mos merr me mend kur nuk je i sigurt.
Version i fuqishëm; Ai përcakton qëllimin, formën, kufirin e sigurisë dhe sjelljen në pasiguri. Konsistenca e prodhimit të modelit vjen drejtpërdrejt nga kjo qartësi.
Tre Mini Rastet
Rasti 1 — Mbështetja bot (kurthi i pashtetësisë). Një ekip i tregtisë elektronike e mori bot drejtpërdrejt; Kur përdoruesi tha "anuloni porosinë e mëparshme", roboti "harroi" numrin e porosisë. Arsyeja: ata po dërgonin çdo kërkesë vetëm me mesazhin e fundit. Zgjidhja: ata shtuan 6 raundet e fundit në listën e mesazheve. Rezultati: konteksti u ruajt, por hyrja për kërkesë u rrit nga 40 argumente në ~ 600 argumente - ne do të mbulojmë mësimin e kostos në njësinë 2.
Rasti 2 — Përmbledhje e pakompletuar e kontratës. Një ekip ligjor kishte të përvijuara kontrata 10 faqesh; max_tokens: 300 mbetën të ulëta, përmbledhjet po e ndërprenë fjalinë në mes. stop_reason ishte max_tokens çdo herë, por askush nuk po shikonte. rriti max_tokens në 1500 dhe shtoi kontrollin stop_reason; Shkalla e përmbledhur e shkurtuar u ul nga 18% në 0%.
Rasti 3 - Përzierja e roleve. Një ekip marketingu po shkruante të gjitha udhëzimet në mesazhin e përdoruesit, duke e lënë sistemin bosh. Kur të dhënat e përdoruesit përzihen me udhëzimet, modeli ndonjëherë do të përputhet me komandën e përdoruesit për të "harruar rregullat e mëparshme". Ata zhvendosën rregulla të përhershme në sistem; Duke ndarë të dhënat e përdoruesit nga udhëzimet, shkeljet e rregullave u ulën ndjeshëm.
Gabimet e zakonshme
- Harron të dërgosh të shkuarën: Modelja mendohet se “nuk e mban mend”; kurse është pa shtetësi. Ju mbani kontekstin.
- Nuk shikon `stop_reason`: Përgjigja e ndaluar me max_tokens konsiderohet e plotë.
- Përfshirja e instruksionit në 'përdorues': Rregulla të vazhdueshme në sistem; hyrja e menjëhershme shkon te përdoruesi. Përzierja krijon dobësi sigurie.
- Gabimi i 'përmbajtjes' për një varg të thjeshtë: Përgjigja është një listë blloqesh; lexoni fushën e tekstit të bllokut të parë të tekstit, verifikoni llojin e tij përpara se të merrni përmbajtje[0] me një indeks të verbër.
- Futja e çelësit në kod: Përdorni një variabël mjedisi (njësia 9).
Më të thella: Blloqe të përmbajtjes dhe përgjigje me shumë pjesë
Të kuptuarit pse fusha e përmbajtjes në përgjigje është një listë është thelbësore për veçoritë e avancuara që do të hasni më vonë. Ndonjëherë modeli nuk kthen një bllok të vetëm teksti, por disa blloqe: një bllok të të menduarit, i ndjekur nga një bllok teksti; ose një bllok teksti i ndjekur nga një bllok përdorimi i veglave. Kjo është arsyeja pse numërimi i verbër i përmbajtjes[0] si një "përgjigje" është i brishtë. Qasja e saktë është të kaloni nëpër listë dhe ta renditni atë sipas llojit: ju mbledhni përmbajtjen e tekstit të blloqeve, fusha e llojit të të cilave është tekst dhe trajtoni llojet e tjera (të menduarit, mjeti) veçmas.
Ajo që bën ky dallim në praktikë është që ju mund të regjistroni arsyetimin e modelit (nëse ka) pa ia zbuluar atë përdoruesit, të ridrejtoni thirrjet e veglave në logjikë të veçantë dhe të printoni vetëm përgjigjen aktuale në ekran. Ndërsa moduli përparon (veçanërisht në njësitë 4 dhe 11) do të shihni se sa e dobishme është kjo strukturë blloku për vërtetimin dhe drejtimin e prodhimit.
Një pikë tjetër praktike: mund të përdorni të njëjtin model nga platforma të ndryshme ofruesish (API direkte, nëpërmjet një ofruesi cloud). Megjithëse adresa e pikës fundore dhe formati i vërtetimit mund të ndryshojnë, konceptet bazë si rolet e mesazhit, pashtetësia dhe struktura e përgjigjes mbeten të njëjta. Pra, bazat në këtë njësi zbatohen pavarësisht se çfarë platforme përdorni.
Në përmbledhje
Një kërkesë LLM API përbëhet nga modeli, kufiri i daljes dhe lista e mesazheve; rolet (sistemi, përdoruesi, asistenti) përcaktojnë sjelljen e modelit. Thirrjet janë pa shtetësi: ju mbani kontekstin me çdo kërkesë. Përgjigja është një objekt i strukturuar; Leximi dhe interpretimi i përmbajtjes, stop_arsyes dhe fushave të përdorimit është baza e qëndrueshmërisë në prodhim.
Detyra e aplikimit
Zgjidhni një detyrë nga profesioni juaj (p.sh. renditja e postës elektronike në hyrje, krijimi i përmbledhjeve të shkurtra). Në një copë letër: (1) shkruani kërkesën e sistemit me 4-5 rregulla, (2) konfiguroni një shembull të mesazhit të përdoruesit dhe një histori 2 raundesh nëse ka, (3) përcaktoni një vlerë të arsyeshme për max_tokens dhe shkruani justifikimin, (4) listoni cilat vlera stop_reason do të trajtoni në përgjigjen e kthyer dhe si.
listë kontrolli
- [ ] Mund të numëroj tre pjesët e detyrueshme të një kërkese (model, max_tokens, mesazhe).
- [ ] Mund të shpjegoj ndryshimin midis roleve të sistemit, përdoruesit dhe asistentit.
- [ ] E di që telefonatat janë pa shtetësi dhe se më duhet të mbaj të kaluarën.
- Unë mund të lexoj dhe komentoj në përmbajtjen [ ], stop_arsyeja dhe fushat e përdorimit.
- [ ] Me max_tokens mund të vërej dhe të trajtoj përgjigjen e cunguar.