చాలా RAG ట్యుటోరియల్స్ ప్రొడక్షన్ (production) దశ మొదలవగానే ముగిసిపోతాయి. మీరు మీ డాక్యుమెంట్లను 512-టోకెన్ చంక్స్‌గా (chunks) విభజించి, వాటిని ఒకే ఎంబెడ్డింగ్ మోడల్ ద్వారా పంపి, సింపుల్ top-k రిట్రీవల్‌తో వెక్టర్ డేటాబేస్‌ను పిలుస్తారు. ఒక డెమోలో, ఇది చాలా నమ్మదగ్గదిగా కనిపిస్తుంది. మీ కంపెనీ లీవ్ పాలసీ గురించి బాట్‌ను అడిగితే, అది ఒక స్పష్టమైన పేరాగ్రాఫ్‌ను అందిస్తుంది. అందరూ సంతోషిస్తారు. దురదృష్టవశాత్తు, డెమోలు నిజాలను దాచిపెడతాయి.

ప్రొడక్షన్ దశలో ప్రతి షార్ట్‌కట్ కూడా బయటపడుతుంది. ఫిక్స్‌డ్ చంక్స్ (Fixed chunks) చట్టపరమైన ఒప్పందాలను (legal contracts) ఇండెమ్నిఫికేషన్ క్లాజుల (indemnification clauses) మధ్యలోనే ముక్కలు చేస్తాయి. API డాక్యుమెంటేషన్ అనేది ఒకదానికొకటి కలిసిపోయిన శబ్దంగా (noise) మారి, మీకు నిజంగా కావాల్సిన సమాచారాన్ని (signal) అణచివేస్తుంది. సమాధానం వచ్చేలోపే యూజర్లు క్వెరీని వదిలేసేంత వరకు లేటెన్సీ (latency) పెరుగుతూనే ఉంటుంది. మేము కూడా ఈ సమస్యను ఎదుర్కొని, మొత్తం వ్యవస్థను మళ్ళీ నిర్మించాల్సి వచ్చింది. మా రిట్రీవల్ లేయర్ (retrieval layer) “సెమాంటిక్ సెర్చ్ మరియు ఆశ” (semantic search and hope) నుండి ఒక కొలతలతో కూడిన, ఇన్‌స్ట్రుమెంటెడ్ పైప్‌లైన్‌గా (instrumented pipeline) మారింది. దీని ఫలితంగా 95% రీకాల్ (recall) మరియు లేటెన్సీలో 40% తగ్గుదల లభించింది. నిజంగా ఏది పనిచేసిందో ఇక్కడ చూడండి.

డాక్యుమెంట్‌కు తగిన చంకింగ్ వ్యూహాన్ని (Chunking Strategy) ఎంచుకోండి

512-టోకెన్ డీఫాల్ట్ పద్ధతి సులభంగా ఉండటం వల్ల వాడుకలో ఉంది తప్ప, అది సరైనది కాబట్టి కాదు. వేర్వేరు డాక్యుమెంట్లు వేర్వేరు అర్థాలను కలిగి ఉంటాయి, కాబట్టి మీ చంకింగ్ వ్యూహం కూడా దానికి అనుగుణంగా ఉండాలి.

లీగల్ కాంట్రాక్ట్స్ (legal contracts) కోసం, స్ట్రక్చరల్ బౌండరీలను (structural boundaries) గౌరవించే రికర్సివ్ చంకింగ్‌ను (recursive chunking) ఉపయోగించండి. చట్టపరమైన భాష అనేది ఒకదానితో ఒకటి ముడిపడి ఉంటుంది. ఒక క్లాజ్ (clause) దాని పైన ఉన్న సెక్షన్‌పై ఆధారపడి ఉంటుంది, కాబట్టి వాక్యం మధ్యలో ఫిక్స్‌డ్ కట్ చేయడం వల్ల ఆ నిబంధన యొక్క తర్కం దెబ్బతింటుంది. రికర్సివ్ చంకింగ్ అనేది టోకెన్ పరిమితిని విధించే ముందు, సహజమైన విభజన పాయింట్లపై—ముందుగా పేరాగ్రాఫ్‌లు, తర్వాత వాక్యాల ద్వారా—విభజించడానికి ప్రయత్నిస్తుంది. ఇది ఇండెమ్నిఫికేషన్ లేదా లయబిలిటీ క్లాజులను (liability clauses) సమగ్రంగా ఉంచుతుంది.

API డాక్యుమెంటేషన్ కోసం, ఫంక్షన్-అవేర్ చంకింగ్‌ను (function-aware chunking) ఉపయోగించండి. డెవలపర్లు యాదృచ్ఛిక పేరాగ్రాఫ్‌ల కోసం వెతకరు; వారు ఎండ్‌పాయింట్లు (endpoints), పారామీటర్లు (parameters) మరియు ఎర్రర్ సిగ్నేచర్‌ల (error signatures) కోసం వెతుకుతారు. ఒక చంక్ అనేది పూర్తి ఫంక్షన్ సిగ్నేచర్, దాని వివరణ మరియు రిటర్న్ స్కీమాను ఒకే లాజికల్ యూనిట్‌గా కలిగి ఉండాలి. మీరు ఆ బ్లాక్‌ను సగానికి విభజిస్తే, రిట్రీవల్ సిస్టమ్ సగం కాంటెక్స్ట్‌ను మాత్రమే అందిస్తుంది మరియు జనరేషన్ మోడల్ మిగిలిన దాని గురించి తప్పుడు సమాచారాన్ని (hallucinates) సృష్టిస్తుంది.

సపోర్ట్ టికెట్స్ (support tickets) కోసం, సంభాషణ క్రమాన్ని (conversation turns) అనుసరించే సెమాంటిక్ చంకింగ్‌పై ఆధారపడండి. సపోర్ట్ థ్రెడ్‌లు లీనియర్‌గా మరియు పునరావృతమయ్యేలా ఉంటాయి. కస్టమర్ సమస్యను మళ్ళీ చెబుతారు, ఏజెంట్ లాగ్స్ (logs) అడుగుతారు, కస్టమర్ వాటిని జత చేస్తారు. ప్రతి టర్న్ (turn) దాని స్వంత సెమాంటిక్ యూనిట్. టర్న్ల ద్వారా చంకింగ్ చేయడం వల్ల ఎవరు, ఏమి, ఎప్పుడు అన్నది స్పష్టంగా ఉంటుంది. యూజర్ “మంగళవారం ఏజెంట్ ఏమి సూచించారు?” అని అడిగినప్పుడు ఇది చాలా కీలకం.

ఇంటర్నల్ వికీల (internal wikis) కోసం, ఏజెంటిక్ చంకింగ్‌ను (agentic chunking) ప్రయత్నించండి. ఒక సెక్షన్‌ను LLMకి ఇచ్చి, ఒక టాపిక్ ఎక్కడ ముగిసిందో మరియు మరొకటి ఎక్కడ మొదలైందో నిర్ణయించమని అడగండి. దీనికి ఇంగెస్ట్ టైమ్‌లో (ingest time) ఎక్కువ ఖర్చు అవుతుంది, కానీ వికీలు చాలా గందరగోళంగా ఉంటాయి. పేజీలలో వేర్వేరు టీమ్‌ల నుండి సంబంధం లేని అప్‌డేట్‌లు ఉంటాయి, మరియు మనుషులు నిర్ణయించిన బౌండరీలు అక్కడ అంతగా ఉపయోగపడవు. టాపిక్ మార్పుల ఆధారంగా మోడల్‌ను బౌండరీలను గీయనివ్వడం వల్ల నాయిస్ (noise) గణనీయంగా తగ్గుతుంది.

ఒకే పైప్‌లైన్‌లో బహుళ వ్యూహాలను అమలు చేయడానికి, ఇంగెస్ట్ సమయంలో డాక్యుమెంట్లను వాటి రకాన్ని బట్టి ట్యాగ్ చేయాలి. ఆ చిన్న స్కీమా క్రమశిక్షణ (schema discipline) వెంటనే ఫలితాలను ఇస్తుంది.

సెర్చ్ పద్ధతులను కలపండి, ఏదో ఒకటి మాత్రమే ఎంచుకోకండి

వెక్టర్ సెర్చ్ ఉద్దేశ్యాన్ని (intent) అర్థం చేసుకుంటుంది, కానీ ఖచ్చితమైన మ్యాచ్‌ల (exact matches) విషయంలో ఇది తరచుగా విఫలమవుతుంది. ERR_CONNECTION_REFUSED వంటి ఎర్రర్ కోడ్ లేదా ఒక నిర్దిష్ట SKU కోసం అడిగినప్పుడు, డెన్స్ ఎంబెడ్డింగ్‌లు (dense embeddings) తరచుగా భావజాలపరంగా సారూప్యంగా ఉన్నా, వాస్తవపరంగా తప్పుగా ఉన్న ఫలితాలను ఇస్తాయి. BM25 అనేది క్లాసిక్ కీవర్డ్ స్పార్స్ రిట్రీవల్ (keyword sparse retrieval) పద్ధతి, ఇది ఖచ్చితమైన స్ట్రింగ్స్‌ను అద్భుతంగా హ్యాండిల్ చేస్తుంది కానీ సెమాంటిక్ సూక్ష్మతను (semantic nuance) గుర్తించలేదు. మీకు ఈ రెండూ అవసరం.

హైబ్రిడ్ రిట్రీవల్‌ను (hybrid retrieval) ఉపయోగించండి. వెక్టర్ సెర్చ్ మరియు BM25లను సమాంతరంగా (parallel) నడపండి. ఆపై వాటిని Reciprocal Rank Fusion (RRF)తో కలపండి. RRF రెండు పద్ధతులు కూడా సంబంధితమైనవని అంగీకరించే డాక్యుమెంట్లకు ప్రాధాన్యత ఇస్తుంది, అదే సమయంలో ఏదైనా ఒక పద్ధతి నుండి బలమైన అభ్యర్థులను కూడా చూపిస్తుంది. దీని గణితం సరళమైనది మరియు ఫలితం స్థిరంగా ఉంటుంది: ఏ ఒక్క రిట్రీవల్ పద్ధతి కూడా ఫైనల్ ర్యాంకింగ్‌ను శాసించదు.

ఫ్యూజన్ తర్వాత, ఒక cross-encoder rerankerను జోడించండి. మొదటి దశ — వెక్టర్ ప్లస్ స్పార్స్ రిట్రీవల్ — వేగంగా మరియు విస్తృతంగా ఉంటుంది. ఆపై cross-encoder ప్రతి క్వెరీ-డాక్యుమెంట్ జంటను పూర్తి అటెన్షన్‌తో స్కోర్ చేస్తుంది, అంటే అది అసలు ప్రశ్నతో పోల్చి అభ్యర్థిని చదువుతుంది. అవును, ఇది లేటెన్సీని పెంచుతుంది. మా విషయంలో, సుమారు యాభై నుండి వంద మిల్లీ సెకన్ల వరకు. కానీ దీనివల్ల లభించే ప్రిసిషన్ (precision) ఎంత ఎక్కువగా ఉంటుందంటే, ఈ చిన్న లేటెన్సీని భరించడం లాభదాయకం. మీకు రీకాల్ (recall) ముఖ్యం అనుకుంటే, దీనిని వదిలివేయలేరు.

ఇండెక్స్‌ను సరిచేయడానికి ముందే క్వెరీని సరిచేయండి

యూజర్లు మీ సెర్చ్ ఇంజిన్ కోసం క్వెరీలను రాయరు. వారు మనుషుల కోసం రాస్తారు. “ఇది పనిచేయడం లేదు” అనేది ఒక సాధారణ సపోర్ట్ క్వెరీ. అస్పష్టమైన ఫీచర్ వివరణ అనేది సాధారణ ఇంటర్నల్ వికీ సెర్చ్. మీరు ఆ ముడి ఇన్‌పుట్‌తో (raw input) ఇండెక్స్‌ను వెతికితే, మీకు చెత్త సమాచారమే (garbage) వస్తుంది.

క్వెరీ రిట్రీవర్‌కు చేరుకోకముందే దానిని మార్చండి (Transform).

వినియోగదారు అడిగే ప్రశ్న యొక్క బహుళ వెర్షన్లను రూపొందించడానికి query expansion ఉపయోగించండి. ఎవరైనా “server down” అని టైప్ చేస్తే, మీ సిస్టమ్ “service unavailable,” “502 error,” మరియు “connection timeout” కోసం కూడా వెతకాలి. ఈ ఇంటెంట్ వేరియంట్‌లను (intent variants) కవర్ చేయడం వల్ల మా రీకాల్ (recall) 78% నుండి 96%కి పెరిగింది. ఇది ఒకే ఒక దశ, మరియు దీని వల్ల కలిగే లాభంతో పోలిస్తే దీని ఖర్చు దాదాపు సున్నా.

సంక్లిష్టమైన ప్రశ్నల కోసం query decomposition ఉపయోగించండి. ఒక వినియోగదారు “How do I migrate from the legacy billing API to the new one and what breaking changes affect enterprise accounts?” వంటి ప్రశ్న అడిగినప్పుడు, దానిని ఉప-ప్రశ్నలుగా (sub-questions) విభజించండి. ఒక ఉప-ప్రశ్న మైగ్రేషన్ దశలను లక్ష్యంగా చేసుకుంటే, మరొకటి ఎంటర్‌ప్రైజ్-నిర్దిష్ట బ్రేకింగ్ చేంజ్‌లను (breaking changes) లక్ష్యంగా చేసుకుంటుంది. ప్రతిదీ ఇండెక్స్‌లోని వేర్వేరు భాగాలను చేరుకుంటుంది. దీనివల్ల డౌన్‌స్ట్రీమ్ లాంగ్వేజ్ మోడల్ (downstream language model), నాయిసీ కాంటెక్స్ట్ విండో (noisy context window) ద్వారా ఊహించే బదులు, సరిగ్గా రిట్రీవ్ చేయబడిన చంక్స్ (chunks) నుండి తుది సమాధానాన్ని రూపొందిస్తుంది.

హైపర్ పారామీటర్లను ఊహించడం ఆపండి

మీరు బహుళ చంకింగ్ వ్యూహాలు (chunking strategies), హైబ్రిడ్ రిట్రీవల్ (hybrid retrieval) మరియు క్వరీ ట్రాన్స్‌ఫర్మేషన్ (query transformation) కలిగి ఉన్నప్పుడు, మీరు ఒక కాంబినేటోరియల్ సమస్యను (combinatorial problem) ఎదుర్కొంటారు. చంక్ సైజ్ (chunk size), ఓవర్‌ల్యాప్ (overlap), ఫ్యూజన్ వెయిట్స్ (fusion weights), రీర్యాంకర్ డెప్త్ (reranker depth) మరియు ఎక్స్‌పాన్షన్ కౌంట్ (expansion count) అన్నీ ఒకదానితో ఒకటి పరస్పరం ప్రభావితమవుతాయి. ఒక దానిని విడిగా మార్చడం వల్ల మరొకటి దెబ్బతింటుంది. ఈ స్పేస్‌లో గ్రిడ్ సెర్చ్ (Grid search) చేయడం వృథా మరియు నెమ్మదిగా ఉంటుంది.

దానికి బదులుగా Bayesian optimization ఉపయోగించండి. దీనిని ఒక మెషిన్ లెర్నింగ్ ట్యూనింగ్ జాబ్ లాగా పరిగణించండి. మీ లక్ష్యాన్ని స్పష్టంగా నిర్వచించండి: లేటెన్సీ (latency) ఒక పరిమితి లోపు ఉంచుతూ రీకాల్‌ను గరిష్టీకరించండి. ఒక 'గోల్డెన్ డేటాసెట్' (golden dataset) నిర్మించండి — ఏ చంక్స్ రిట్రీవ్ అవ్వాలో మీకు ఖచ్చితంగా తెలిసిన కొన్ని వందల ప్రాతినిధ్య ప్రశ్నలు అందులో ఉండాలి. ఆ తర్వాత Bayesian సెర్చ్ కాన్ఫిగరేషన్ స్పేస్‌ను సమర్థవంతంగా అన్వేషించనివ్వండి. ఇది ఏది పనిచేస్తుందో ఒక ప్రాబబిలిస్టిక్ మోడల్‌ను (probabilistic model) నిర్మిస్తుంది మరియు తదుపరి అత్యంత ఆశాజనకమైన ప్రాంతాలను పరీక్షిస్తుంది.

ప్రతి కాండిడేట్ కాన్ఫిగరేషన్ స్టేజింగ్ (staging) కి చేరుకోకముందే గోల్డెన్ డేటాసెట్‌ను ఉత్తీర్ణత సాధించాలి. ఒకవేళ కొత్త చంక్ సైజ్ రీకాల్‌ను తగ్గిస్తే లేదా భారీ రీర్యాంకర్ లేటెన్సీ బడ్జెట్‌ను మించివేస్తే, ఆప్టిమైజేషన్ దానిని ఆటోమేటిక్‌గా గుర్తిస్తుంది. ఇది చర్చల్లో వ్యక్తిగత అభిప్రాయాలను తొలగిస్తుంది. 256 లేదా 512 టోకెన్లు ఏది “మెరుగైనది” అనే చర్చలు ఆపివేసి, మీరు ఫలితాలను చూడటం ప్రారంభిస్తారు.

ఫలితం

పైప్‌లైన్ మార్పులు మేము ఆశించిన విధంగానే ఫలితాలను ఇచ్చాయి.

  • Recall@10 78% నుండి 95%కి పెరిగింది.
  • P95 latency 850 ms నుండి 320 msకి తగ్గింది.
  • Hallucination rate 12% నుండి 3%కి తగ్గింది.
  • Cost per query 38% తగ్గింది, దీనికి ప్రధాన కారణం మెరుగైన రిట్రీవల్ వల్ల మేము చిన్న జనరేషన్ మోడల్‌ను మరియు తక్కువ ప్రాంప్ట్ టోకెన్లను ఉపయోగించగలిగాము.

లేటెన్సీ తగ్గడం టీమ్‌లోని కొందరిని ఆశ్చర్యపరిచింది. రీర్యాంకర్లు మరియు క్వరీ ఎక్స్‌పాన్షన్‌ను జోడించడం వల్ల వేగం తగ్గుతుందని అనిపించవచ్చు. కానీ రిట్రీవల్ నాణ్యత మెరుగుపడటం వల్ల, జనరేషన్ మోడల్‌కు తక్కువ ప్రాంప్టింగ్, తక్కువ ఊహలు (speculation) మరియు తక్కువ రీట్రైలు అవసరమయ్యాయి. మంచి రిట్రీవల్ వల్ల డౌన్‌స్ట్రీమ్ ప్రక్రియ అంతా చౌకగా మారుతుంది.

రిట్రీవల్‌ను ఇన్‌ఫ్రాస్ట్రక్చర్‌లా పరిగణించండి

రిట్రీవల్ అనేది మీరు ఒకసారి రన్ చేసి మర్చిపోయే నోట్‌బుక్ కాదు. ఇది ఒక ఇన్‌ఫ్రాస్ట్రక్చర్, మరియు దీనిని కోడ్ లాగా నిర్వహించాలి. మీ చంకింగ్ వ్యూహాలకు వెర్షన్లు (version) ఇవ్వండి. లీగల్ టీమ్ కొత్త కాంట్రాక్ట్ టెంప్లేట్‌ను విడుదల చేసినప్పుడు, అది ప్రొడక్షన్‌కు చేరుకోకముందే మీ రికర్సివ్ స్ప్లిటర్‌ను (recursive splitter) పరీక్షించండి. మీ గోల్డెన్ డేటాసెట్‌ను గత త్రైమాసికానికి చెందిన స్టాటిక్ CSV లాగా కాకుండా, నిరంతరం అప్‌డేట్ అయ్యే డాక్యుమెంట్‌లుగా (living documents) నిర్వహించండి. మీ ఎవాల్యుయేషన్లను CIలో ఆటోమేట్ చేయండి, తద్వారా ఎంబెడ్డింగ్ మోడల్ లేదా ఫ్యూజన్ వెయిట్‌ను సవరించే పుల్ రిక్వెస్ట్ (pull request) మానవ సమీక్షకు రాకముందే రీకాల్ మరియు లేటెన్సీ నంబర్లతో కూడిన కామెంట్‌ను పొందుతుంది.

మీరు ఏ ఎంబెడ్డింగ్ మోడల్‌ను ఉపయోగిస్తున్నారో మీ వినియోగదారులు ఎప్పుడూ అడగరు. మీ చంకింగ్ హ్యూరిస్టిక్ (chunking heuristic) లేదా మీ రీర్యాంకర్ ఆర్కిటెక్చర్ గురించి వారు పట్టించుకోరు. సమాధానం సరైనదా, అది వేగంగా వస్తుందా మరియు దానిని వారు నమ్మవచ్చా అనే దానిపైనే వారు దృష్టి పెడతారు. ఆ నమ్మకాన్ని సంపాదించే పైప్‌లైన్‌ను నిర్మించండి, దానిని నిజాయితీగా కొలవండి మరియు రిట్రీవల్‌ను ఒక అదనపు ఆలోచనలా (afterthought) చూడటం ఆపండి.

Source: Optimizing RAG At Scale
Join the discussion: GyaanSetu AI Community