లాభాలు:
- LLM API అభ్యర్థన యొక్క ప్రాథమిక నిర్మాణాన్ని వివరించవచ్చు (ముగింపు, మోడల్, సందేశాలు, max_tokens)
- సిస్టమ్, వినియోగదారు మరియు సహాయక పాత్రలు మరియు స్థితిలేని సంభాషణ చరిత్ర మధ్య వ్యత్యాసాన్ని అర్థం చేసుకుంటుంది
- తిరిగి వచ్చిన ప్రతిస్పందన యొక్క ఫీల్డ్లను (కంటెంట్ బ్లాక్లు, stop_reason, యూసేజ్) చదవవచ్చు మరియు అర్థం చేసుకోవచ్చు
మునుపటి మాడ్యూల్స్లో, మేము చాట్ విండో నుండి కృత్రిమ మేధస్సును ఉపయోగించాము. కానీ మీరు AIని మీ స్వంత ఉత్పత్తి, ఆటోమేషన్ లేదా వర్క్ఫ్లోలో పొందుపరచాలనుకుంటే, చాట్ ఇంటర్ఫేస్ దానిని తగ్గించదు; మీరు ప్రోగ్రామాటిక్గా మోడల్కి కనెక్ట్ చేయాలి, అంటే కోడ్ లేదా ఆటోమేషన్ సాధనంతో. ఈ వంతెన పేరు API (అప్లికేషన్ ప్రోగ్రామింగ్ ఇంటర్ఫేస్, రెండు సాఫ్ట్వేర్లను కొన్ని నిబంధనలతో మాట్లాడటానికి అనుమతించే ఒప్పందం). మీరు ఈ యూనిట్ని పూర్తి చేసినప్పుడు, LLM (లార్జ్ లాంగ్వేజ్ మోడల్) API అభ్యర్థన అంటే ఏమిటి, సందేశ పాత్రలు ఏమి చేస్తాయి మరియు ప్రతిస్పందనను ఎలా చదవాలి అని మీకు తెలుస్తుంది. మిగిలిన మాడ్యూల్ నిర్మించబడే పునాది ఇది.
API ఎలా పని చేస్తుంది?
APIలో ప్రాథమిక ప్రవాహం ఇది: మీరు ఒక నిర్దిష్ట ఆకృతిలో అభ్యర్థనను పంపుతారు; సర్వర్ నిర్దిష్ట ఆకృతిలో ప్రతిస్పందనను అందిస్తుంది. LLMలలో, ఇది సాధారణంగా HTTP కాల్ (HTTP: వెబ్లో అభ్యర్థన-ప్రతిస్పందనను తీసుకువెళ్లడానికి ప్రామాణిక ప్రోటోకాల్) ఒకే చిరునామాకు (ఎండ్ పాయింట్, మీ అభ్యర్థనను నిర్వహించే సర్వర్లోని స్థిర చిరునామా). ఉదాహరణకు, మెసేజింగ్ APIలో, అన్ని అభ్యర్థనలు ఒకే చిరునామాకు వెళ్తాయి మరియు JSON (జావాస్క్రిప్ట్ ఆబ్జెక్ట్ సంజ్ఞామానం — మానవులు మరియు యంత్రాలు ఇద్దరూ చదవగలిగే కీ/విలువ జతలతో కూడిన టెక్స్ట్ ఫార్మాట్) వలె శరీరంలోకి తీసుకువెళతారు.
అభ్యర్థనలో, మీరు కనీసం ఈ మూడు విషయాలను పేర్కొనండి:
- మోడల్: మీరు ఉపయోగించే మోడల్ (ఉదా. వేగవంతమైన మరియు చౌక మోడల్ లేదా శక్తివంతమైన మోడల్).
- max_tokens: మోడల్ ఉత్పత్తి చేయగల గరిష్ట సంఖ్య టోకెన్లు (టెక్స్ట్ ప్రాసెస్ చేయబడిన అతి చిన్న యూనిట్, తదుపరి యూనిట్లో వివరంగా ప్రాసెస్ చేయబడుతుంది); అంటే అవుట్పుట్ పరిమితి.
- సందేశాలు: సంభాషణను రూపొందించే సందేశాల జాబితా.
దశల వారీగా: అభ్యర్థనను ఎలా సెటప్ చేయాలి
- ముగింపు పాయింట్ మరియు ఆధారాలను సిద్ధం చేయండి. మీరు హెడర్లోని అభ్యర్థనకు మీ API కీని (మీ గుర్తింపును నిరూపించే రహస్య స్ట్రింగ్) జోడిస్తారు. మీరు ఎప్పుడూ కోడ్లో కీని పొందుపరచలేదు; మేము యూనిట్ 9లో సురక్షిత నిల్వను కవర్ చేస్తాము.
- మోడల్ మరియు అవుట్పుట్ పరిమితిని ఎంచుకోండి. తేలికైన మోడల్ + ఒక సాధారణ పని కోసం చిన్న max_tokens; క్లిష్టమైన పని కోసం శక్తివంతమైన మోడల్ + పెద్ద పరిమితి.
- సందేశాల జాబితాను సెటప్ చేయండి. List the system instruction, user message, and past rounds (if any).
- అభ్యర్థనను పంపండి మరియు ప్రతిస్పందనను అన్వయించండి. తిరిగి వచ్చిన JSON నుండి టెక్స్ట్ కంటెంట్ చదవండి, కారణం ఆపండి మరియు టోకెన్ వినియోగాన్ని.
సందేశ పాత్రలు: సిస్టమ్, వినియోగదారు, సహాయకుడు
సంభాషణ ఒక క్రమంలో అమర్చబడిన సందేశాలను కలిగి ఉంటుంది మరియు ప్రతి సందేశానికి ఒక పాత్ర ఉంటుంది. మోడల్ ఆ వచనాన్ని ఎలా పరిగణిస్తుందో పాత్ర నిర్ణయిస్తుంది.
పాత్ర
ఎవరు వ్రాస్తారు
ప్రయోజనం
వ్యవస్థ
డెవలపర్/ఆపరేటర్
మొత్తం సంభాషణ అంతటా వర్తించే శాశ్వత సూచనలు, వ్యక్తిత్వం మరియు నియమాలు
వినియోగదారు
తుది వినియోగదారు
వినియోగదారు ప్రస్తుత ప్రశ్న లేదా ఇన్పుట్
సహాయకుడు
మోడల్
మోడల్ ద్వారా రూపొందించబడిన ప్రతిస్పందన (మరియు మునుపటి ప్రతిస్పందనలు)
సిస్టమ్ పాత్ర చాలా మంది ప్రొవైడర్లలో అభ్యర్థన బాడీలో ప్రత్యేక సిస్టమ్ ఫీల్డ్గా అందుబాటులో ఉంది; సందేశాల జాబితాలో వినియోగదారు మరియు సహాయకుడు వరుసగా జాబితా చేయబడ్డారు. 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": "మీరు ఒక కార్పొరేట్ సపోర్ట్ అసిస్టెంట్. సంక్షిప్త, అధికారిక మరియు ధృవీకరించబడిన ప్రతిస్పందనను ఇవ్వండి. మీకు ఖచ్చితంగా తెలియని సమాచారాన్ని రూపొందించవద్దు.", "messages": [ { "role": "user": "నేను తిరిగి ప్రారంభించాలా?" } ]}
వాక్కు స్థితిలేనిది
ఇక్కడ అత్యంత సాధారణ అపోహ ఉంది: LLM API కాల్లు స్థితి లేనివి — సర్వర్ రెండు అభ్యర్థనల మధ్య మెమరీని కలిగి ఉండదు. మోడల్ మీ మునుపటి అభ్యర్థనను గుర్తుంచుకోలేదు. మీరు బహుళ-రౌండ్ చాట్ని సెటప్ చేస్తుంటే, మీరు ప్రతి కొత్త అభ్యర్థనతో గత రౌండ్లను మళ్లీ పంపాలి. మోడల్ యొక్క "మెమరీ" మీరు పంపిన సందేశాల జాబితాను కలిగి ఉంటుంది.
{ "model": "claude-opus-4-8", "max_tokens": 512, "messages": [ { "role": "user", "content": "హలో, నా పేరు డెనిజ్." }, { "పాత్ర": "అసిస్టెంట్", "కంటెంట్": "హలో డెనిజ్, నేను మీకు ఎలా సహాయం చేయగలను?" }, { "role": "user", "content": "నేను నా పేరు చెప్పాను, మీకు గుర్తుందా?" } ]}
మూడవ సందేశానికి సరిగ్గా సమాధానం ఇవ్వడం మీరు మునుపటి రెండు సందేశాలను పంపడంపై ఆధారపడి ఉంటుంది. మీరు దీన్ని పంపకపోతే, మోడల్కు "సముద్రం" తెలియదు మరియు తప్పుగా సమాధానం ఇస్తుంది. ఇది నేరుగా ఖర్చును కూడా ప్రభావితం చేస్తుంది: సంభాషణ ఎక్కువ, జాబితా పెద్దది, ప్రతి అభ్యర్థన మరిన్ని టోకెన్లను వినియోగిస్తుంది.
చిట్కా: సుదీర్ఘ సంభాషణలలో, మొత్తం చరిత్రను పంపడానికి బదులుగా పాత రౌండ్లను (సారాంశం + చివరి కొన్ని రౌండ్లు) సంగ్రహించడం మరియు తరలించడం ఖర్చును తగ్గిస్తుంది మరియు సందర్భ విండోను భద్రపరుస్తుంది. మేము దీనిని యూనిట్లు 6 మరియు 11లో లోతుగా చేస్తాము.
జవాబు చదవండి
మోడల్ ప్రతిస్పందనను అందించినప్పుడు, మీరు సాధారణ వచనాన్ని కాకుండా నిర్మాణాత్మక వస్తువును అందుకుంటారు. సాధారణ ప్రాంతాలు:
{ "id": "msg_01ABC...", "model": "claude-opus-4-8", "role": "assistant", "content": [ { "type": "text", "text": "రిటర్న్ని ప్రారంభించడానికి, మీ ఖాతాలోని 'నా ఆర్డర్లు' పేజీకి వెళ్లండి..." {{101}} . "input_tokens": 47, "output_tokens": 88 }}
- కంటెంట్: ప్రతిస్పందన కూడా; ఇది కంటెంట్ బ్లాక్ల జాబితా. టెక్స్ట్ బ్లాక్ యొక్క టెక్స్ట్ ఫీల్డ్ అసలు సమాధానం.
- stop_reason: మోడల్ ఎందుకు ఆగిపోయింది. ముగింపు_టర్న్ = సహజ ముగింపు; max_tokens = అవుట్పుట్ పరిమితి వద్ద నిలిచిపోయింది (ప్రతిస్పందన అసంపూర్ణంగా ఉండవచ్చు); refusal = భద్రతా కారణాల దృష్ట్యా నిరాకరించిన. మీ కోడ్ ఎల్లప్పుడూ ముందుగా stop_reasonని చూడాలి.
- వినియోగం: ఇన్పుట్ మరియు అవుట్పుట్ టోకెన్ నంబర్లు. ఇది ఖర్చు మరియు పరిమితి ట్రాకింగ్ యొక్క ఆధారం.
శ్రద్ధ: stop_reason max_tokens అయితే, ప్రతిస్పందన పూర్తి కాలేదు. దీనిని "విజయవంతమైన ప్రతిస్పందన"గా పరిగణించడం మరియు వినియోగదారుకు సగం వచనాన్ని చూపడం అనేది ఉత్పత్తిలో అత్యంత సాధారణ తప్పులలో ఒకటి. max_tokens పెంచండి లేదా స్ట్రీమింగ్ని ఉపయోగించండి.
బలహీనమైన ప్రాంప్ట్ / బలమైన ప్రాంప్ట్
రెండు వేర్వేరు సిస్టమ్ ప్రాంప్ట్లతో ఒకే పని:
# వీక్ మీరు సహాయకుడు. ప్రశ్నలకు సమాధానమివ్వండి.
# STRONGమీరు కార్పొరేట్ సపోర్ట్ అసిస్టెంట్. నియమాలు:- అందించిన పాలసీ డాక్యుమెంట్లోని సమాచారంపై మాత్రమే ఆధారపడండి; ఇది పత్రంలో లేకుంటే, "నా దగ్గర ఈ సమాచారం లేదు, నేను దానిని సంబంధిత యూనిట్కి పంపుతున్నాను" అని చెప్పండి. - సమాధానాలు 3 వాక్యాలను మించకూడదు, అధికారికంగా మరియు స్పష్టంగా ఉండాలి. - వ్యక్తిగత డేటా (TC ID నంబర్, కార్డ్ నంబర్) కోసం అడగవద్దు మరియు పునరావృతం చేయవద్దు. - మీకు ఖచ్చితంగా తెలియనప్పుడు ఊహించవద్దు.
శక్తివంతమైన వెర్షన్; ఇది స్కోప్, రూపం, భద్రత మార్జిన్ మరియు అనిశ్చితిలో ప్రవర్తనను నిర్వచిస్తుంది. మోడల్ అవుట్పుట్ యొక్క స్థిరత్వం ఈ స్పష్టత నుండి నేరుగా వస్తుంది.
మూడు మినీ కేసులు
కేస్ 1 — సపోర్ట్ బాట్ (స్టేట్లెస్నెస్ ట్రాప్). ఒక ఇ-కామర్స్ బృందం బాట్ను ప్రత్యక్ష ప్రసారం చేసింది; వినియోగదారు "మునుపటి ఆర్డర్ను రద్దు చేయి" అని చెప్పినప్పుడు, బోట్ ఆర్డర్ నంబర్ను "మర్చిపోయింది". కారణం: వారు ప్రతి అభ్యర్థనను చివరి సందేశంతో మాత్రమే పంపుతున్నారు. పరిష్కారం: వారు సందేశాల జాబితాకు చివరి 6 రౌండ్లను జోడించారు. ఫలితం: సందర్భం సంరక్షించబడింది, కానీ ప్రతి అభ్యర్థనకు ఇన్పుట్ 40 టోకెన్ల నుండి ~600 టోకెన్లకు పెరిగింది — మేము యూనిట్ 2లో ఖర్చు పాఠాన్ని కవర్ చేస్తాము.
కేస్ 2 — అసంపూర్ణమైన ఒప్పంద సారాంశం. ఒక న్యాయ బృందం 10-పేజీల ఒప్పందాలను వివరించింది; max_tokens: 300 తక్కువగా ఉన్నాయి, సారాంశాలు మధ్య వాక్యాన్ని కత్తిరించాయి. stop_reason ప్రతిసారీ max_tokens ఉంది కానీ ఎవరూ చూడటం లేదు. max_tokens 1500కి పెంచబడింది మరియు stop_reason చెక్ జోడించబడింది; కత్తిరించబడిన సారాంశం రేటు 18% నుండి 0%కి తగ్గింది.
కేస్ 3 - మిక్సింగ్ పాత్రలు. ఒక మార్కెటింగ్ బృందం వినియోగదారు సందేశంలో అన్ని సూచనలను వ్రాసి, సిస్టమ్ను ఖాళీగా ఉంచింది. వినియోగదారు ఇన్పుట్ సూచనలతో కలిపినప్పుడు, మోడల్ కొన్నిసార్లు "మునుపటి నియమాలను మరచిపో" అనే వినియోగదారు ఆదేశానికి అనుగుణంగా ఉంటుంది. వారు వ్యవస్థకు శాశ్వత నియమాలను తరలించారు; సూచనల నుండి వినియోగదారు ఇన్పుట్ను వేరు చేయడం ద్వారా, నియమ ఉల్లంఘనలు గణనీయంగా తగ్గాయి.
సాధారణ తప్పులు
- గతాన్ని పంపడం మర్చిపోవడం: మోడల్ "గుర్తు లేదు" అని భావించబడుతుంది; అయితే అది స్థితిలేనిది. మీరు సందర్భాన్ని తీసుకువెళ్లండి.
- `stop_reason`ని చూడడం లేదు: max_tokensతో ఆపివేయబడిన ప్రతిస్పందన పూర్తయినట్లుగా పరిగణించబడుతుంది.
- `వినియోగదారు`లో సూచనలను పొందుపరచడం: సిస్టమ్లో స్థిరమైన నియమాలు; తక్షణ ఇన్పుట్ వినియోగదారుకు వెళుతుంది. మిక్సింగ్ భద్రతా లోపాలను సృష్టిస్తుంది.
- సాదా స్ట్రింగ్ కోసం `కంటెంట్` తప్పుగా ఉంది: సమాధానం బ్లాక్ల జాబితా; మొదటి టెక్స్ట్ బ్లాక్ యొక్క టెక్స్ట్ ఫీల్డ్ను చదవండి, బ్లైండ్ ఇండెక్స్తో కంటెంట్[0] పొందే ముందు దాని రకాన్ని ధృవీకరించండి.
- కోడ్లో కీని పొందుపరచడం: ఎన్విరాన్మెంట్ వేరియబుల్ (యూనిట్ 9) ఉపయోగించండి.
లోతైన: కంటెంట్ బ్లాక్లు మరియు బహుళ-భాగాల సమాధానాలు
ప్రతిస్పందనలోని కంటెంట్ ఫీల్డ్ ఎందుకు జాబితాగా ఉందో అర్థం చేసుకోవడం మీరు తర్వాత ఎదుర్కొనే అధునాతన ఫీచర్లకు ప్రాథమికమైనది. కొన్నిసార్లు మోడల్ టెక్స్ట్ యొక్క ఒక బ్లాక్ను కాదు, అనేక బ్లాక్లను అందిస్తుంది: ఆలోచన యొక్క బ్లాక్, తర్వాత టెక్స్ట్ యొక్క బ్లాక్; లేదా టెక్స్ట్ యొక్క బ్లాక్ తర్వాత టూల్ యూజ్ బ్లాక్. అందుకే గుడ్డిగా కంటెంట్[0]ని "సమాధానం"గా లెక్కించడం పెళుసుగా ఉంటుంది. జాబితా ద్వారా వెళ్లి దానిని రకం ద్వారా క్రమబద్ధీకరించడం సరైన విధానం: మీరు టెక్స్ట్ టైప్ ఫీల్డ్ ఉన్న బ్లాక్ల యొక్క టెక్స్ట్ కంటెంట్ను సేకరిస్తారు మరియు ఇతర రకాలను (ఆలోచించడం, సాధనం) విడిగా పరిగణించండి.
ఆచరణలో ఈ వ్యత్యాసం ఏమిటంటే, మీరు మోడల్ యొక్క తార్కికతను వినియోగదారుకు బహిర్గతం చేయకుండా (ఏదైనా ఉంటే) లాగ్ చేయవచ్చు, ప్రత్యేక లాజిక్కు టూల్ కాల్లను దారి మళ్లించవచ్చు మరియు స్క్రీన్పై అసలు సమాధానాన్ని మాత్రమే ముద్రించవచ్చు. మాడ్యూల్ పురోగమిస్తున్నప్పుడు (ముఖ్యంగా యూనిట్లు 4 మరియు 11లో) ఈ బ్లాక్ నిర్మాణం అవుట్పుట్ని ధృవీకరించడానికి మరియు నిర్దేశించడానికి ఎంత ఉపయోగకరంగా ఉందో మీరు చూస్తారు.
మరొక ఆచరణాత్మక అంశం: మీరు వివిధ ప్రొవైడర్ ప్లాట్ఫారమ్ల నుండి ఒకే మోడల్ను యాక్సెస్ చేయవచ్చు (డైరెక్ట్ API, క్లౌడ్ ప్రొవైడర్ ద్వారా). ఎండ్పాయింట్ చిరునామా మరియు ప్రామాణీకరణ ఆకృతి మారినప్పటికీ, సందేశ పాత్రలు, స్థితిలేనితనం మరియు ప్రతిస్పందన నిర్మాణం వంటి ప్రాథమిక అంశాలు అలాగే ఉంటాయి. కాబట్టి మీరు ఏ ప్లాట్ఫారమ్ని ఉపయోగించినా ఈ యూనిట్లోని ప్రాథమిక అంశాలు వర్తిస్తాయి.
సారాంశంలో
LLM API అభ్యర్థన మోడల్, అవుట్పుట్ పరిమితి మరియు సందేశ జాబితాను కలిగి ఉంటుంది; పాత్రలు (సిస్టమ్, యూజర్, అసిస్టెంట్) మోడల్ యొక్క ప్రవర్తనను నిర్ణయిస్తాయి. కాల్లు స్థితి లేనివి: మీరు ప్రతి అభ్యర్థనతో సందర్భాన్ని కలిగి ఉంటారు. ప్రతిస్పందన నిర్మాణాత్మక వస్తువు; కంటెంట్, stop_reason మరియు వినియోగ ఫీల్డ్లను చదవడం మరియు వివరించడం అనేది ఉత్పత్తిలో మన్నికకు ఆధారం.
అప్లికేషన్ టాస్క్
మీ స్వంత వృత్తి నుండి ఒక పనిని ఎంచుకోండి (ఉదా. ఇన్కమింగ్ ఇ-మెయిల్ను క్రమబద్ధీకరించడం, సంక్షిప్త సారాంశాలను సృష్టించడం). కాగితంపై: (1) సిస్టమ్ ప్రాంప్ట్ను 4-5 నియమాలతో వ్రాయండి, (2) నమూనా వినియోగదారు సందేశాన్ని మరియు ఏదైనా ఉంటే 2-రౌండ్ హిస్టరీని సెటప్ చేయండి, (3) max_tokens కోసం సహేతుకమైన విలువను నిర్ణయించండి మరియు జస్టిఫికేషన్ను వ్రాయండి, (4) మీరు తిరిగి వచ్చిన ప్రతిస్పందనలో ఏ stop_reason విలువలను నిర్వహించాలో మరియు ఎలా చేయాలో జాబితా చేయండి.
చెక్లిస్ట్
- [ ] నేను అభ్యర్థన యొక్క మూడు తప్పనిసరి భాగాలను లెక్కించగలను (model, max_tokens, messages).
- [ ] నేను సిస్టమ్, వినియోగదారు మరియు సహాయక పాత్రల మధ్య వ్యత్యాసాన్ని వివరించగలను.
- [ ] కాల్లు స్థితిలేనివని మరియు నేను గతాన్ని తీసుకువెళ్లాలని నాకు తెలుసు.
- నేను [ ] కంటెంట్, stop_reason మరియు వినియోగ ఫీల్డ్లను చదవగలను మరియు వ్యాఖ్యానించగలను.
- [ ] max_tokensతో నేను కత్తిరించబడిన ప్రతిస్పందనను గమనించగలను మరియు నిర్వహించగలను.