AI చర్చల్లో విస్మరించబడుతున్న కీలక అంశం

ప్రతి ఒక్కరూ AI ఏజెంట్ల (AI agents) గురించి మాట్లాడుతున్నారు. మీరు ఏదైనా టెక్ ఫీడ్‌ని స్క్రోల్ చేస్తే, ఒక లార్జ్ లాంగ్వేజ్ మోడల్ (LLM) విమాన టిక్కెట్లు బుక్ చేయడం, కోడ్ రాయడం లేదా సపోర్ట్ టిక్కెట్లకు సమాధానం ఇవ్వడం వంటి అద్భుతమైన పనులను చేస్తున్న డెమోలు కనిపిస్తాయి. దీని వెనుక ఉన్న సందేశం స్పష్టంగా కనిపిస్తోంది: మీరు ఒక యూజర్‌ను LLMతో అనుసంధానిస్తే, అద్భుతాలు జరుగుతాయి.

ఆ భ్రమ ఐదు నిమిషాల డెమోకు చాలా బాగా పనిచేస్తుంది. కానీ నిజమైన వినియోగదారులు, నిజమైన డేటా మరియు నిజమైన డబ్బు ప్రవేశించిన మరుక్షణమే అది కుప్పకూలిపోతుంది. ప్రొడక్షన్ (production) స్థాయిలో, సంబంధం కేవలం యూజర్ ↔ LLM మాత్రమే కాదు. అది యూజర్ ↔ LLMని కలిగి ఉన్న ఒక సంక్లిష్ట వ్యవస్థ. ఆ వ్యవస్థ గురించి ఎవరూ మాట్లాడని భాగమే 'హార్నెస్' (harness)—అంటే మోడల్ చుట్టూ ఉన్న ప్రతి అంశాన్ని ఎంపిక చేసే, రూట్ చేసే, రక్షించే మరియు సమన్వయం చేసే ఒక మద్దతు వ్యవస్థ (scaffolding). ఇది లేకుండా, మీకు ఒక ఉత్పత్తి (product) ఉండదు; కేవలం ఒక ప్రోటోటైప్ మాత్రమే ఉంటుంది.

సాధారణ లూప్ ఎందుకు విఫలమవుతుంది

డెమో అనేది ఒక నియంత్రిత వాతావరణం. అక్కడ ప్రశ్నలు చిన్నవిగా ఉంటాయి, సందర్భం (context) పరిమితంగా ఉంటుంది మరియు రిస్క్ తక్కువగా ఉంటుంది. డెవలపర్ ఒకే ఒక API కాల్ చేస్తారు, వెంటనే స్పష్టమైన సమాధానం వస్తుంది, ప్రేక్షకులు చప్పట్లు కొడతారు. కానీ ప్రొడక్షన్ అనేది గందరగోళంగా ఉంటుంది. వినియోగదారులు అస్పష్టమైన అనుబంధ ప్రశ్నలు అడుగుతారు. థర్డ్-పార్టీ APIలు టైమ్ అవుట్ అవుతాయి. నిన్నటి వరకు పర్ఫెక్ట్ JSONను జనరేట్ చేసిన మోడల్, ఈరోజు అకస్మాత్తుగా మార్క్‌డౌన్ (markdown)ను ఇస్తుంది. కాంటెక్స్ట్ విండోలు నిండిపోతాయి. ఖర్చు పెరిగినప్పుడు లేదా అత్యంత అవసరమైన సమయంలో రేట్ లిమిట్స్ (rate limits) అడ్డుపడతాయి.

ఒక ముడి ప్రాంప్ట్-రెస్పాన్స్ లూప్‌కు (raw prompt-response loop) వీటన్నింటికీ సమాధానం తెలియదు. ఏ టాస్క్‌ను ఏ మోడల్ వేరియంట్ నిర్వహించాలో దానికి తెలియదు. మూడు టర్న్ల క్రితం ఏం జరిగిందో దానికి గుర్తుండదు. విఫలమైన కాల్‌ను మళ్ళీ ప్రయత్నించడం (retry), ఖర్చులు పెరిగినప్పుడు రిక్వెస్ట్‌లను నియంత్రించడం (throttle), లేదా మీ డేటాబేస్‌లోకి వెళ్లే ముందు అవుట్‌పుట్‌ను శుద్ధి చేయడం (sanitize) వంటివి అది చేయలేదు. ఇవి కేవలం అరుదైన సందర్భాలు (edge cases) మాత్రమే కాదు; ఇవి నిజ ప్రపంచ సాఫ్ట్‌వేర్‌కు ఉండే ప్రాథమిక లక్షణాలు. వీటిని నిర్వహించడమే హార్నెస్ యొక్క పని.

హార్నెస్ (Harness) నిజంగా ఏం చేస్తుంది

హార్నెస్ అనేది ఒక లాంగ్వేజ్ మోడల్‌ను కేవలం తెలివైన టెక్స్ట్ జనరేటర్ నుండి నమ్మదగిన సర్వీస్ కాంపోనెంట్‌గా మార్చే ఇంజనీరింగ్ లేయర్ అని అనుకోండి. దీని బాధ్యతలు చాలా స్పష్టమైనవి మరియు ఆకర్షణీయంగా లేనివి, అందుకే వీటిని తరచుగా విస్మరిస్తారు.

చేయాల్సిన టాస్క్ కోసం మోడల్ ఎంపిక. ప్రతి ఇంటరాక్షన్‌కు అందుబాటులో ఉన్న అత్యంత శక్తివంతమైన ఫౌండేషన్ మోడల్ అవసరం లేదు. కొన్ని పనులకు అపారమైన రీజనింగ్ పవర్ (reasoning power) కావాలి; మరికొన్నింటికి కేవలం వేగం మరియు తక్కువ ఖర్చు సరిపోతాయి. బాగా నిర్మించబడిన హార్నెస్ రిక్వెస్ట్‌లను తెలివిగా రూట్ చేస్తుంది. ఉదాహరణకు, ఒక కస్టమర్ సపోర్ట్ ఏజెంట్ వచ్చే సందేశం యొక్క ఉద్దేశాన్ని (intent) వర్గీకరించడానికి—అంటే అది రీఫండ్ అభ్యర్థనా లేదా షిప్పింగ్ ప్రశ్ననా అని తెలుసుకోవడానికి—వేగవంతమైన, తక్కువ ఖర్చుతో కూడిన మోడల్‌ను ఉపయోగించవచ్చు. ఒకవేళ ఆ ఉద్దేశం సంక్లిష్టమైన పాలసీ వివాదానికి సంబంధించినదైతే, హార్నెస్ ఆ టాస్క్‌ను మరింత శక్తివంతమైన రీజనింగ్ మోడల్‌కు పంపుతుంది. వినియోగదారుడు కేవలం ట్రాకింగ్ లింక్ కోరుకుంటే, లైట్‌వెయిట్ మోడల్ వెంటనే సమాధానం ఇస్తుంది, తద్వారా మీ ఖర్చు (burn rate) అదుపులో ఉంటుంది.

డేటా ఫ్లోను నిర్వహించడం. నిజమైన అప్లికేషన్లు శూన్యంలో పనిచేయవు. ఒక AI ఏజెంట్‌కు తరచుగా వెక్టర్ స్టోర్ (vector store) నుండి డాక్యుమెంట్లను తీసుకోవడం, CRMని క్వరీ చేయడం, ఇటీవలి యూజర్ యాక్టివిటీని చదవడం మరియు వాటన్నింటినీ ఒక సమగ్రమైన సమాధానంగా మార్చడం అవసరమవుతుంది. హార్నెస్ ఆ డేటా సేకరణను (ingestion) నిర్వహిస్తుంది. ఇది సరైన కాంటెక్స్ట్ చంక్స్‌ను సేకరిస్తుంది, అవి సందర్భాన్ని కోల్పోకుండా టోకెన్ పరిమితుల్లో ఉన్నాయో లేదో తనిఖీ చేస్తుంది, వాటిని మోడల్ కోసం సిద్ధం చేస్తుంది మరియు ఫలితాన్ని తదుపరి సిస్టమ్‌కు పంపుతుంది. ఈ సమన్వయం (orchestration) లేకపోతే, మోడల్‌కు కాంటెక్స్ట్ అందక పోవచ్చు లేదా అనవసరమైన సమాచారంతో గందరగోళం ఏర్పడవచ్చు.

ఎర్రర్లను నిర్వహించడం. సాంప్రదాయ సర్వీసుల కంటే LLMలు భిన్నమైన రీతిలో విఫలమవుతాయి. అవి స్ట్రక్చర్డ్ అవుట్‌పుట్‌లను హాలూసినేట్ (hallucinate) చేస్తాయి. ఖాళీ సమాధానాలను ఇస్తాయి. మోడల్ వెర్షన్ స్వల్పంగా మారిన వెంటనే ఫార్మాటింగ్ సూచనలను ఉల్లంఘిస్తాయి. హార్నెస్ ఈ వైఫల్యాలను ఆశ్చర్యకరమైన సంఘటనలుగా కాకుండా, ఊహించదగిన ప్రవర్తనలుగా పరిగణిస్తుంది. ఇది స్కీమాలను (schemas) ధృవీకరిస్తుంది, తప్పుగా ఉన్న రెస్పాన్స్‌లను గుర్తిస్తుంది, ఎక్స్‌పోనెన్షియల్ బ్యాక్-ఆఫ్ (exponential backoff)తో రీట్రై లాజిక్‌ను వర్తింపజేస్తుంది మరియు ప్రైమరీ ఎండ్‌పాయింట్ విఫలమైనప్పుడు సెకండరీ ప్రొవైడర్‌కు లేదా క్యాష్ చేసిన ఫలితానికి మారుతుంది. అంతా విఫలమైనప్పుడు, పేయింగ్ కస్టమర్‌కు అర్థం లేని సమాచారాన్ని ఇచ్చే బదులు, ఇది మానవ ఆపరేటర్‌కు సమస్యను అప్పగిస్తుంది.

సిస్టమ్ విశ్వసనీయతను నిర్ధారించడం. ప్రొడక్షన్ అంటే ఏకకాలంలో ఉపయోగించే వినియోగదారులు (concurrent users), ఖర్చు పరిమితులు మరియు ఊహించలేని లాటెన్సీ (latency). హార్నెస్ రేట్ లిమిట్‌లను అమలు చేస్తుంది, కనెక్షన్ పూలింగ్‌ను నిర్వహిస్తుంది మరియు సర్క్యూట్ బ్రేకర్లను (circuit breakers) అమలు చేస్తుంది, తద్వారా ఒక నెమ్మదైన మోడల్ ప్రొవైడర్ మీ మొత్తం అప్లికేషన్‌ను నిలిపివేయకుండా చూస్తుంది. ప్రతి ఇంటరాక్షన్‌ను ఇది లాగ్ చేస్తుంది, తద్వారా ఒక నిర్దిష్ట సెషన్ ఎందుకు విఫలమైందో మీరు తెలుసుకోవచ్చు. అలాగే, మీ ప్రాంప్ట్‌లను వెర్షన్ చేస్తుంది, తద్వారా డిప్లాయ్‌మెంట్ సమయంలో ఆడిట్ ట్రయల్స్ లేకుండా మీ ఏజెంట్ వ్యక్తిత్వం అనుకోకుండా మారిపోకుండా ఉంటుంది.

ఒకే మోడల్, పూర్తిగా భిన్నమైన ఫలితాలు

ఇది అనేక ప్రొడక్ట్ టీమ్‌లను అయోమయానికి గురిచేసే ఒక దృగ్విషయాన్ని వివరిస్తుంది. రెండు కంపెనీలు ఒకే రకమైన ఫౌండేషన్ మోడల్‌తో—అదే వెయిట్స్, అదే కాంటెక్స్ట్ విండో, అదే ట్రైనింగ్ కటాఫ్—ప్రారంభించవచ్చు, కానీ వాటి అనుభవాలు (experiences) ప్రపంచానికి భిన్నంగా ఉంటాయి. ఒకటి అస్థిరంగా, నెమ్మదిగా మరియు వింతగా మర్చిపోయేలా అనిపిస్తుంది. మరొకటి వేగంగా, స్థిరంగా మరియు నమ్మదగినదిగా అనిపిస్తుంది.

తేడా ఎప్పుడూ మోడల్‌లో ఉండదు. అది దాని చుట్టూ ఉన్న సిస్టమ్‌లో ఉంటుంది. ఒక టీమ్ మోడల్‌ను మొత్తం ప్రొడక్ట్‌గా పరిగణించింది. మరొక టీమ్ దానిని క్రమబద్ధమైన ఆర్కిటెక్చర్‌లోని ఒక భాగం (component)గా పరిగణించింది. ఆ క్రమశిక్షణ అనేది ఆ హార్నెస్ (harness)లోనే ఉంటుంది.

ప్రాంప్ట్‌ల నుండి ఆర్కిటెక్చర్‌కు మారడం

ప్రారంభ AI అభివృద్ధిలో ప్రాంప్ట్ ఇంజనీరింగ్‌కు అత్యంత ప్రాధాన్యత ఇచ్చారు. పదజాలాన్ని మార్చడం, ఉదాహరణలు జోడించడం మరియు రోల్-ప్లే సూచనలను చేర్చడం ద్వారా అవుట్‌పుట్ నాణ్యతను గణనీయంగా మెరుగుపరచవచ్చు. ఆ నైపుణ్యం ఇప్పటికీ ముఖ్యం, కానీ పోటీపరంగా అది తక్కువ ఫలితాలను ఇస్తోంది (diminishing returns). ఒక రిట్రై పాలసీ (retry policy) లేకపోయినా లేదా ప్రైవేట్ కాంటెక్స్ట్‌ను పబ్లిక్ రెస్పాన్స్‌లోకి లీక్ చేసే డేటా పైప్‌లైన్ ఉన్నా, కేవలం ప్రాంప్ట్‌లతో వాటిని సరిదిద్దలేరు.

ప్రస్తుతం జరుగుతున్న అసలైన మార్పు సాఫ్ట్‌వేర్ ఆర్కిటెక్చర్ వైపు సాగుతోంది. ఇంజనీర్లు స్టేట్ మెషీన్స్‌ను రూపొందిస్తున్నారు, మోడల్ లేయర్ మరియు అప్లికేషన్ లాజిక్ మధ్య కఠినమైన ఇంటర్‌ఫేస్‌లను నిర్వచిస్తున్నారు, మరియు నాన్-డిటర్మినిజం (non-determinism)ను ఒక ముఖ్యమైన ఇంజనీరింగ్ అంశంగా పరిగణిస్తున్నారు. వారు డిస్ట్రిబ్యూటెడ్ సిస్టమ్స్ (distributed systems)కు సంబంధించిన ప్రశ్నలు అడుగుతున్నారు: మల్టీ-టర్న్ సంభాషణలో స్టేట్ ఎలా నిలిచి ఉంటుంది? డౌన్‌స్ట్రీమ్ టూల్ అందుబాటులో లేనప్పుడు ఏమవుతుంది? ప్రాబబిలిస్టిక్ (probabilistic) అంశం కలిగిన సిస్టమ్‌ను మేము ఎలా పరీక్షించగలం? ఒక బొమ్మను (toy) ఒక సాధనంగా (tool) మార్చేవి ఈ ప్రశ్నలే.

ప్రొడక్షన్ కోసం నిర్మించడం: అబ్జర్వబిలిటీ మరియు కంట్రోల్

మీరు ప్రొడక్షన్‌లోకి తీసుకురావడంలో సీరియస్‌గా ఉంటే, హార్నెస్ అన్నింటికంటే ముఖ్యంగా రెండు లక్షణాలను కోరుకుంటుంది: అబ్జర్వబిలిటీ (observability) మరియు ఆర్కెస్ట్రేషన్ (orchestration).

అబ్జర్వబిలిటీ అంటే మోడల్‌కు ఏమి అందింది, అది ఏమి తిరిగి ఇచ్చింది మరియు ప్రతి దశకు ఎంత సమయం పట్టింది అనేది మీరు చూడగలగడం. అంటే, ఒక ఏజెంట్ యొక్క నిర్ణయ ప్రక్రియను (decision loop) పద్నాలుగు టూల్ కాల్స్ అంతటా ట్రాక్ చేయడం మరియు అది ఎక్కడ లూప్‌లో చిక్కుకుపోయిందో లేదా లక్ష్యం నుండి తప్పుకుందో ఖచ్చితంగా గుర్తించడం. ఆ విజిబిలిటీ లేకపోతే, AI సిస్టమ్‌ను డీబగ్ చేయడం అనేది చీకటిలో కారు ఇంజిన్‌ను రిపేర్ చేయడం వంటిది.

ఆర్కెస్ట్రేషన్ అంటే మీ బిజినెస్ లాజిక్ మీ మోడల్ ఇంటరాక్షన్ లేయర్ నుండి వేరుగా ఉండటం. అంటే మీరు కోడ్‌ను వెర్షన్ చేసినట్లుగానే ప్రాంప్ట్‌లను కూడా వెర్షన్ చేయడం, తద్వారా కొత్త డిప్లాయ్‌మెంట్ వల్ల ప్రవర్తన (behavior) మారుకుండా ఉంటుంది. అంటే ఫెయిల్యూర్ మోడ్స్‌ను (failure modes) కావాలని పరీక్షించడం—అంటే ఒక API రిక్వెస్ట్ మధ్యలో ఆగిపోవడం, తప్పుగా ఉన్న టూల్ రిజల్ట్స్ ఇవ్వడం, కాంటెక్స్ట్ విండో ఓవర్‌ఫ్లోను సిమ్యులేట్ చేయడం—సిస్టమ్ స్థిరంగా ఉందో లేదో చూడటం. ఫ్రేమ్‌వర్క్‌లు వస్తుంటాయి పోతుంటాయి, మీరు ఒక రెడీమేడ్ ఆర్కెస్ట్రేషన్ లైబ్రరీని వాడినా లేదా మీ స్వంతదాన్ని నిర్మించినా, బ్రాండ్ పేరు కంటే క్రమశిక్షణే ముఖ్యం.

అసలైన సారాంశం

ఫౌండేషన్ మోడల్స్ నిరంతరం మెరుగుపడుతూనే ఉంటాయి. అవి మరింత వేగంగా, చౌకగా మరియు సామర్థ్యవంతంగా మారుతాయి. కానీ శక్తివంతమైన ఇంజిన్ అనేది విరిగిపోయిన ఛాసిస్‌ను (chassis) సరిచేయలేదు. రాబోయే కొన్ని సంవత్సరాలలో విజేతలు ఎవరో అంటే, అత్యంత అధునాతన మోడల్ యాక్సెస్ ఉన్నవారు కాదు. నమ్మదగిన, అబ్జర్వబుల్ మరియు చక్కగా ఆర్కెస్ట్రేట్ చేయబడిన హార్నెస్‌ను నిర్మించిన వారే విజేతలు. వారు తమ అప్లికేషన్‌లను తిరిగి రాయకుండానే మోడల్‌లను మార్చుకోగలరు. హార్నెస్ ప్రతి టోకెన్‌ను నియంత్రించడం వల్ల వారు ఖర్చులను అదుపులో ఉంచుకోగలరు. వారి సిస్టమ్స్ విఫలమైనప్పుడు కూడా క్రమబద్ధంగా (gracefully) పనిచేస్తాయి కాబట్టి వారు ప్రశాంతంగా నిద్రపోగలరు.

కేవలం మోడల్ గురించి మాత్రమే ఆలోచించడం ఆపండి. దానిని నడిపించే సిస్టమ్ గురించి ఆలోచించడం ప్రారంభించండి. స్మార్ట్ మోడల్స్ చుట్టూ స్మార్ట్ సిస్టమ్స్‌ను నిర్మించే ఇంజనీర్లదే భవిష్యత్తు.


This article draws on ideas originally discussed by Abdulaziz Zos in "Beyond The Model".

For more discussions on AI engineering and system design, check out the GyaanSetu learning community.