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

ప్రస్తుతం, ప్రతిదీ ఏజెంట్ అని పిలుస్తున్నారు. ఒక కండిషన్ నెరవేరే వరకు లూప్ అయ్యే స్క్రిప్ట్‌ను అకస్మాత్తుగా ఏజెంట్ అని పిలుస్తున్నారు. చివరి మూడు సందేశాలను మెమరీలో నిల్వ చేసే చాట్‌బాట్‌ను కూడా ఏజెంట్ అని పిలుస్తున్నారు. ఈ అస్పష్టమైన పదజాలం ఇంజనీరింగ్‌లో నిజమైన నష్టాన్ని కలిగిస్తుంది. ఒక సాధారణ cron job ద్వారా చేయగలిగే ఐదు అడుగుల వర్క్‌ఫ్లోను ఆటోమేట్ చేయడానికి బృందాలు భారీ ఏజెంట్ ఫ్రేమ్‌వర్క్‌ల వైపు మొగ్గు చూపుతున్నాయి. అదే సమయంలో, వారు నిజమైన సంక్లిష్టతపై తక్కువ పెట్టుబడి పెడుతున్నారు, ఎందుకంటే ఆ లేబుల్ (agent) వల్ల లార్జ్ లాంగ్వేజ్ మోడల్ మ్యాజిక్‌లా అన్ని ఎడ్జ్ కేసెస్ (edge cases) పరిష్కరిస్తుందని వారు భావిస్తున్నారు. కానీ అది జరగదు.

ఏజెంట్ అంటే నిజంగా ఏమిటి

ఏజెంట్ అనేది ఒక లక్ష్యంతో (objective) పనిచేసే వ్యవస్థ. ఇది మనిషి ఇచ్చిన ఆదేశాల క్రమాన్ని మాత్రమే అనుసరించదు. ప్రపంచ స్థితిని బట్టి తదుపరి ఏమి చేయాలో అది నిర్ణయించుకుంటుంది. ఒక టూల్ విఫలమైనా లేదా డేటా కనిపించకపోయినా అది వైఫల్యాలను ఎదుర్కోగలదు. తన లక్ష్యం పూర్తయిందని దానికి తెలుసు మరియు అది తనంతట తానుగా ఆగిపోగలదు.

మీరు నిర్మిస్తున్న దేన్నైనా అంచనా వేయడానికి ఈ మూడు నియమాలను ఉపయోగించండి:

  • ఒకవేళ మనిషి ప్రతి అడుగును చెప్పాల్సి వస్తే, అది కేవలం ఒక చాట్ ఇంటర్‌ఫేస్ మాత్రమే. ఇక్కడ మీరు డ్రైవింగ్ చేస్తున్నారు. సిస్టమ్ కేవలం ఒక మర్యాదపూర్వకమైన స్టీరింగ్ వీల్‌లా మాత్రమే ఉంది.
  • ఒకవేళ అది విఫలమైన టూల్ కాల్ నుండి కోలుకోగలిగితే, మీరు సరైన మార్గంలో ఉన్నారు. ఒక సెర్చ్ API టైమ్ అవుట్ అవ్వడం లేదా 500 ఎర్రర్‌ను రిటర్న్ చేయడం వల్ల పని ఆగిపోకూడదు. సిస్టమ్ మళ్ళీ ప్రయత్నించాలి (retry), వెనక్కి తగ్గాలి (back off), ప్రత్యామ్నాయ మూలానికి మారాలి లేదా సహాయం కోరాలి.
  • ఒకవేళ అది ఒక లక్ష్యాన్ని ఉప-పనులుగా (subtasks) విభజించి, వాటిని అప్పగిస్తే, అది నిజమైన ఏజెంట్. "Q3 కంప్లయన్స్ రిపోర్ట్‌ను సిద్ధం చేయి" వంటి కమాండ్ ఇస్తే, అది డేటా సోర్స్‌లను గుర్తిస్తుంది, డేటా సేకరణను షెడ్యూల్ చేస్తుంది, ముడి సంఖ్యలను కాలిక్యులేషన్ మాడ్యూల్‌కు పంపిస్తుంది, డ్రాఫ్ట్‌ను రివ్యూ కోసం పంపిస్తుంది మరియు ఎప్పుడు ఆగాలో దానికి తెలుసు.

మీ సిస్టమ్ ఈ పనులను చేయకపోతే, మీకు ఏజెంట్ సమస్య లేదు. మీకు స్క్రిప్టింగ్ సమస్య లేదా వర్క్‌ఫ్లో సమస్య ఉంది. దీనిని ముందుగానే గుర్తించడం వల్ల ఫ్రేమ్‌వర్క్ బ్లోట్ (framework bloat) వల్ల కలిగే వారాల కొద్దీ వృథా సమయాన్ని ఆదా చేయవచ్చు.

విజేతగా నిలిచే బృందాలు నిజంగా దేనికి ప్రాధాన్యత ఇస్తాయి

నమ్మదగిన సిస్టమ్‌లను రూపొందించే బృందాలు, కేవలం బెంచ్‌మార్క్‌లో కొన్ని పాయింట్ల కోసం తాజా మోడల్ రిలీజ్‌లను మార్చుతూ రోజులు గడపవు. వారు మూడు బోరింగ్ మరియు అధిక ప్రభావం చూపే అంశాలపై దృష్టి పెడతారు.

టూల్ డిజైన్ (Tool design). మీరు ఇచ్చే టూల్స్ ఎంత బాగుంటే, మీ ఏజెంట్ అంత బాగా పనిచేస్తుంది. ఒక సెర్చ్ ఫంక్షన్ అస్థిరమైన ఫీల్డ్ పేర్లతో కూడిన నెస్టెడ్ JSONను రిటర్న్ చేస్తే, మోడల్ కంటెంట్‌పై ఆలోచించే బదులు ఆ స్ట్రక్చర్‌ను అర్థం చేసుకోవడానికే తన విలువైన కాంటెక్స్ట్ విండోను వృథా చేస్తుంది. టూల్ వివరణలు అస్పష్టంగా ఉంటే, మోడల్ తప్పుడు ఆర్గ్యుమెంట్లను సృష్టించడం (hallucinate) చేస్తుంది. టూల్ ఇంటర్‌ఫేస్‌లను, క్లీన్ ఇన్‌పుట్‌లు, ఊహించదగిన అవుట్‌పుట్‌లు మరియు స్పష్టమైన ఎర్రర్ స్టేట్‌లు అవసరమయ్యే ఒక చాలా సీరియస్ జూనియర్ డెవలపర్‌కు ఇచ్చే APIలలాగా పరిగణించండి.

ఫెయిల్యూర్ హ్యాండ్లింగ్ (Failure handling). ఒక రిట్రీవల్ స్టెప్ ఏమీ రిటర్న్ చేయనప్పుడు ఏం జరుగుతుంది? చాలా పైప్‌లైన్‌లు ఖాళీ కాంటెక్స్ట్‌ను సైలెంట్‌గా ప్రాంప్ట్‌లోకి నెట్టివేసి, మోడల్ తన ట్రైనింగ్ డేటా నుండి తప్పుడు సమాచారాన్ని సృష్టించేలా (hallucinate) చేస్తాయి. అది ఫీచర్ కాదు; అది ఎప్పుడైనా జరగగల ఒక ప్రొడక్షన్ ఇన్సిడెంట్. సరైన సిస్టమ్ ఆ ఖాళీని గుర్తిస్తుంది. అది మరింత విస్తృతమైన క్వెరీతో మళ్ళీ ప్రయత్నిస్తుంది. అది మనిషికి ఎస్కేలేట్ చేస్తుంది లేదా స్పష్టమైన వివరణతో ఆగిపోతుంది. దానికి ఏమీ దొరకనప్పుడు, ఏదో దొరికినట్లుగా ఎప్పుడూ నటించదు.

అబ్జర్వబిలిటీ (Observability). ఏజెంట్ ఒక నిర్దిష్ట నిర్ణయాన్ని ఎందుకు తీసుకుందో మీరు చూడాలి. కేవలం చివరి అవుట్‌పుట్ మాత్రమే కాదు—చైన్ ఆఫ్ థాట్ (chain of thought), టూల్ సెలక్షన్, రిట్రీవ్ చేయబడిన చంక్స్ మరియు హ్యాండోఫ్ లాగ్స్ కూడా చూడాలి. ఆ ట్రేస్ (trace) లేకపోతే, డీబగ్గింగ్ అనేది కేవలం ఊహల మీద ఆధారపడటం అవుతుంది. వచ్చే వారం ఒక యూజర్ తప్పు సమాధానం గురించి ఫిర్యాదు చేసినప్పుడు, ఏ రిట్రీవల్ స్టెప్ తప్పుడు సమాచారాన్ని ఇచ్చింది మరియు ఎందుకు ఇచ్చింది అనేది మీరు ఖచ్చితంగా తెలుసుకోగలిగేలా ఉండాలి.

ఫ్రేమ్‌వర్క్‌ల కంటే ఎక్కువ కాలం నిలిచే ఆర్కిటెక్చర్ ప్యాటర్న్స్

LangChain, CrewAI మరియు రాబోయే ఆరు నెలల్లో వచ్చే తదుపరి హాట్ ఫ్రేమ్‌వర్క్ అన్నీ కేవలం స్కాఫోల్డింగ్ (scaffolding) మాత్రమే. ఆర్కిటెక్చర్ అనేది అసలైన భవనం. మీ డిజైన్ బలహీనంగా ఉంటే, ఏ ఫ్రేమ్‌వర్క్ కూడా దానిని కాపాడలేదు. నిలకడగా నిలిచిన ప్యాటర్న్స్‌కు కట్టుబడి ఉండండి:

  • ముందుగా ప్రణాళిక సిద్ధం చేయండి, ఆపై అమలు చేయండి. మోడల్ ఒకేసారి ఆలోచించడం మరియు పనిచేయడం చేయనివ్వకండి. మొదట, ఒక ప్రణాళికను రూపొందించండి. ఆపై ఆ దశలను అమలు చేయండి. ఏదైనా తప్పు జరిగినప్పుడు, మీరు అమలు నుండి స్వతంత్రంగా ప్రణాళికను పరిశీలించవచ్చు. దీనివల్ల టూల్ కాల్స్ (tool calls) మరియు ఆలోచనా ప్రక్రియల (stream-of-consciousness reasoning) మధ్య చిక్కుపడి సమయాన్ని వృథా చేయాల్సిన అవసరం ఉండదు.
  • రిట్రీవల్ (retrieval) మరియు రీజనింగ్‌ను (reasoning) వేరు చేయండి. కాంటెక్స్ట్‌ను సేకరించడం అనేది ఒక I/O పని. ఆ కాంటెక్స్ట్‌ను ఉపయోగించడం అనేది రీజనింగ్ పని. ఈ రెండింటినీ కలిపేస్తే, మీ రిట్రీవర్ మోడల్ యొక్క టోకెన్ పరిమితులకు లోబడి ఉంటుంది మరియు మీ మోడల్ అనవసరమైన సమాచారంతో (retrieval noise) కలుషితం అవుతుంది. రిట్రీవల్ లేయర్ వేగంగా సమాచారాన్ని సేకరించనివ్వండి. రీజనింగ్ లేయర్ దానికి వచ్చిన సమాచారాన్ని విశ్లేషించేలా చూడండి.
  • స్పష్టమైన హ్యాండ్‌ఆఫ్స్ (handoffs) ఉపయోగించండి. ఒక పనిని బహుళ ఏజెంట్లు చేస్తున్నట్లయితే, ఆ పనిని ఒకరి నుండి ఒకరికి బదిలీ చేసే విధానాన్ని క్రమబద్ధీకరించండి. స్పష్టమైన అవుట్‌పుట్ స్కీమాలు (output schemas), యాజమాన్య పరిధులు (ownership boundaries) మరియు హ్యాండ్‌ఆఫ్ లాగ్‌లను నిర్వచించండి. ఏజెంట్ల మధ్య జరిగే అస్పష్టమైన సంభాషణలు పనుల విఫలం కావడానికి, అనవసరమైన లూప్‌లకు లేదా ఒకే పనిని మళ్లీ మళ్లీ చేయడం వంటి సమస్యలకు దారితీస్తాయి. ఏజెంట్-టు-ఏజెంట్ కమ్యూనికేషన్‌ను ఒక గ్రూప్ చాట్‌లా కాకుండా, స్పష్టంగా నిర్వచించబడిన API కాంట్రాక్ట్‌లా పరిగణించండి.

మీ RAG ఎందుకు తప్పుడు సమాచారాన్ని (garbage) ఇస్తుందో అసలు కారణం

మీ రిట్రీవల్-ఆగ్మెంటెడ్ జనరేషన్ (RAG) పైప్‌లైన్ నిరంతరం పనికిరాని ఫలితాలను ఇస్తుంటే, ఎంబెడ్డింగ్ మోడల్‌ను ట్యూన్ చేయడం ఆపివేసి, మీ చంకింగ్ (chunking) వ్యూహాన్ని పరిశీలించండి. RAG సిస్టమ్స్‌లో అత్యధికంగా విస్మరించబడే వైఫల్య అంశం ఇదే.

మీరు డాక్యుమెంట్లను కఠినమైన నిర్ణీత పరిమాణపు చంక్స్‌గా (fixed-size chunks) విభజించినప్పుడు, తరచుగా కొన్ని ఆలోచనలు లేదా భావాలు విడిపోతాయి. ఉదాహరణకు, “అయితే, ఈ విధానం నియంత్రణ మార్పులను పరిగణనలోకి తీసుకోవడంలో విఫలమైంది” అని ప్రారంభమయ్యే పేరాగ్రాఫ్, ఆ విధానం ఏమిటో తెలిపే మునుపటి పేరాగ్రాఫ్ లేకుండా అర్థం కాదు. అటువంటి విడిపోయిన భాగాన్ని మోడల్‌కు ఇస్తే, మోడల్ తనకు కావాల్సిన కాంటెక్స్ట్‌ను తనే సృష్టించుకుంటుంది. అది రిట్రీవల్ కాదు; అది ఒక హాలూసినేషన్ ఫ్యాక్టరీ (hallucination factory).

ఈ పరిష్కారాలను ప్రయత్నించండి:

  • ఓవర్‌లాపింగ్ విండోస్ (Overlapping windows). పక్కపక్కన ఉన్న చంక్స్‌ల మధ్య సరిహద్దుల్లో ఒకటి లేదా రెండు వాక్యాలను పంచుకునేలా చేయండి, తద్వారా భావాలు మధ్యలోనే ఆగిపోకుండా ఉంటాయి.
  • సెమాంటిక్ చంకింగ్ (Semantic chunking). క్యారెక్టర్ల సంఖ్య ఆధారంగా కాకుండా, సహజమైన సరిహద్దుల వద్ద—పేరాగ్రాఫ్ ముగింపులు, సెక్షన్ హెడర్లు లేదా అంశాల మార్పుల వద్ద—విభజించండి.
  • పేరెంట్-డాక్యుమెంట్ రిట్రీవల్ (Parent-document retrieval). సెమాంటిక్ మ్యాచింగ్ కోసం చిన్న, ఖచ్చితమైన చంక్స్‌ను రిట్రీవ్ చేయండి, కానీ భాషా నమూనాకు (language model) పూర్తి పేరెంట్ సెక్షన్ లేదా డాక్యుమెంట్‌ను అందించండి, తద్వారా అది సమాచారాన్ని రూపొందించేటప్పుడు చుట్టుపక్కల ఉన్న కాంటెక్స్ట్‌ను కలిగి ఉంటుంది.
  • రా (raw) టెక్స్ట్‌కు బదులుగా స్ట్రక్చర్డ్ డేటాను నిల్వ చేయండి. టేబులర్ డేటా, కీ-వాల్యూ జంటలు (key-value pairs) మరియు సంబంధాలు తరచుగా వచన రూపంలో (prose) ఉన్నప్పుడు సరిగ్గా ఎంబెడ్ అవ్వవు. మీ మూల సమాచారం స్ట్రక్చర్డ్ రూపంలో ఉంటే, దానిని గ్రాఫ్ డేటాబేస్ లేదా రిలేషనల్ స్టోర్‌లో స్ట్రక్చర్డ్ రూపంలోనే ఉంచండి. అప్పుడు ఏజెంట్ టెక్స్ట్ ముక్కల నుండి ఊహించే బదులు, దానిని స్పష్టంగా క్వెరీ చేసేలా చేయండి.

మీరు నమ్మగలిగే వ్యవస్థలను నిర్మించండి

బెంచ్‌మార్క్‌ల వెంట పడటం ఆపండి. లీడర్‌బోర్డ్ స్కోరు అనేది కేవలం ప్రయోగశాల పరిస్థితులకు మాత్రమే పరిమితం. కానీ ప్రొడక్షన్ (production) అనేది గందరగోళంగా, సవాలుగా మరియు అసమకాలికంగా (async) ఉంటుంది. మీరు నిద్రపోతున్నప్పుడు, అప్‌స్ట్రీమ్ API సరిగ్గా పనిచేయనప్పుడు మరియు శిక్షణ డేటాలో లేని ప్రశ్నను వినియోగదారుడు అడిగినప్పుడు మీ సిస్టమ్ సరిగ్గా పనిచేస్తుందా లేదా అన్నదే ముఖ్యం.

సిస్టమ్స్ డిజైన్‌పై దృష్టి పెట్టండి. రిట్రీవల్ మరియు రీజనింగ్ మధ్య స్పష్టమైన సరిహద్దులను నిర్మించండి. వైఫల్యం చెందినప్పుడు స్పష్టంగా తెలియజేసే మరియు సులభంగా కోలుకునే (recover) టూల్స్‌ను రూపొందించండి. మీరు నిర్ణయాలను ఆడిట్ చేయగలిగేలా వాటిని లాగ్ (log) చేయండి. కాంటెక్స్ట్ దెబ్బతినకుండా ఉండటానికి మీ డాక్యుమెంట్లను చంక్స్‌గా విభజించండి. అలా చేస్తే, మీరు కేవలం డెమోలకే పరిమితం కాకుండా, వాస్తవ పరిస్థితుల్లో కూడా నమ్మదగిన పైప్‌లైన్‌లను నిర్మించగలరు.

మూలం: The Overlooked Reason Your RAG Pipeline Keeps Returning Garbage

నేర్చుకునే కమ్యూనిటీలో చేరండి: GyaanSetu AI on Telegram