చాలా RAG ట్యుటోరియల్స్ డెమోతోనే ముగిసిపోతాయి. మీరు టోకెన్ కౌంట్ ఆధారంగా చంకింగ్ (chunking) చేసి, అన్నింటినీ ఒక వెక్టర్ డేటాబేస్‌లోకి నెట్టివేసి, పని పూర్తి చేసినట్లు అనుకుంటారు. ఒక యూజర్ క్లీన్ FAQలో "రిటర్న్ పాలసీ ఏమిటి?" అని అడిగినప్పుడు ఇది పనిచేస్తుంది. కానీ ఎవరైనా ఒక ఒప్పందంలోని (contract) సగం భాగాన్ని పేస్ట్ చేసి, మూడవ క్లాజ్ (clause three) గురించి అడిగినప్పుడు, లేదా ఒక డెవలపర్ డాక్యుమెంటేషన్ సెర్చ్‌లో ఏదైనా అస్పష్టమైన ఎర్రర్ కోడ్‌ను టైప్ చేసినప్పుడు ఇది విఫలమవుతుంది.

ఫిక్స్‌డ్ టోకెన్ విండోస్ (Fixed token windows) చట్టపరమైన ఒప్పందాలను వాక్యం మధ్యలోనే కత్తిరిస్తాయి. పెద్ద చంక్స్ (Large chunks) API రిఫరెన్స్‌లను అనవసరమైన సమాచారంతో ముంచెత్తుతాయి. అన్నిటికంటే దారుణమైన విషయం ఏమిటంటే, నెమ్మదైన రిట్రీవల్ (slow retrieval) వల్ల మోడల్ సమాధానం ఇవ్వడం ప్రారంభించకముందే యూజర్లు క్వెరీని వదిలేస్తారు. మేము దీనిని కష్టపడి నేర్చుకున్నాము. మా రిట్రీవల్ లేయర్‌ను కేవలం అంచనాల నుండి కొలమానాల (measurement) వైపు మార్చినప్పుడు, మేము లేటెన్సీని (latency) నలభై శాతం తగ్గించాము మరియు రీకాల్ (recall) ను తొంభై ఐదు శాతానికి పెంచాము. మేము చేసిన మార్పులు ఇవే.

స్మార్ట్ చంకింగ్ (Smart Chunking)

చంక్ సైజును ఒక మ్యాజిక్ నంబర్‌గా చూడటం ఆపండి. ఒకే క్లాజ్ (clause) బహుళ పేరాగ్రాఫ్‌ల వరకు విస్తరించి ఉండే లీగల్ డాక్యుమెంట్‌కు 512-టోకెన్ విండో ఏమాత్రం ఉపయోగపడదు. అలాగే, ఒక ఫంక్షన్ సిగ్నేచర్ (function signature) మరియు దాని రెండు లైన్ల వివరణ కలిసి ఉండాల్సిన API డాక్యుమెంటేషన్‌కు కూడా ఇది పనికిరాదు. అందుకే మేము స్ట్రక్చర్-అవేర్ స్ప్లిటింగ్ (structure-aware splitting) వైపు మళ్ళాము.

లీగల్ టెక్స్ట్ కోసం, రికర్సివ్ చంకింగ్ (recursive chunking) డాక్యుమెంట్ యొక్క క్రమానుగత శ్రేణిని (hierarchy) గౌరవిస్తుంది. దీనివల్ల క్లాజులు (clauses) విడిపోకుండా ఉంటాయి. API డాక్యుమెంటేషన్ కోసం, మేము ఫంక్షన్-అవేర్ స్ప్లిటింగ్ (function-aware splitting) ఉపయోగిస్తాము, ఇది సిగ్నేచర్‌లు, పారామీటర్లు మరియు ఉదాహరణలను ఒకే యూనిట్‌గా ఉంచుతుంది. సపోర్ట్ టికెట్లు మరియు సంభాషణాత్మక డేటాకు (conversational data) సెమాంటిక్ బౌండరీస్ (semantic boundaries) అవసరం; అంటే ఏదైనా ఒక నిర్దిష్ట క్యారెక్టర్ కౌంట్ వద్ద కాకుండా, టాపిక్ మారే చోట విడగొట్టాలి. దీని ఫలితంగా, ప్రతి చంక్ ఉపయోగపడేంత కాంటెక్స్ట్‌ను కలిగి ఉంటుంది, కానీ సమాచారాన్ని మసకబార్చేంత ఎక్కువగా ఉండదు. మీ ఎంబెడ్డింగ్ మోడల్‌కు (embedding model) పరిమితమైన అటెన్షన్ బడ్జెట్ ఉంటుంది. దానిని తెలివిగా ఉపయోగించండి.

హైబ్రిడ్ రిట్రీవల్ (Hybrid Retrieval)

కాన్సెప్చువల్‌గా సారూప్యంగా ఉన్న కంటెంట్‌ను కనుగొనడంలో వెక్టర్ సెర్చ్ (Vector search) అద్భుతంగా పనిచేస్తుంది. నెమ్మదైన డేటాబేస్ క్వెరీల గురించి అడిగితే, అది పెర్ఫార్మెన్స్ ట్యూనింగ్ గైడ్‌లను చూపిస్తుంది. కానీ "Error 0x80070057" అని అడిగితే, డెన్స్ ఎంబెడ్డింగ్‌లు (dense embeddings) ఖచ్చితమైన మ్యాచ్‌లను సరిగ్గా గుర్తించలేవు కాబట్టి, సెమాంటిక్ సెర్చ్ సంబంధం లేని అంశాల వైపు వెళ్ళిపోతుంది. మరోవైపు, BM25 ఖచ్చితమైన స్ట్రింగ్స్ మరియు అరుదైన పదాలను కచ్చితంగా గుర్తిస్తుంది, కానీ "latency" మరియు "slow response time" రెండూ ఒకటే అని దానికి తెలియదు.

మేము ఈ రెండింటినీ సమాంతరంగా (parallel) నడుపుతూ, Reciprocal Rank Fusion (RRF) ద్వారా విలీనం చేస్తాము. RRF అనేది సరళమైనది మరియు ప్రభావవంతమైనది. ఇది ప్రతి పద్ధతి నుండి వచ్చిన ర్యాంక్ లిస్ట్‌లను తీసుకుని, వాటి స్థానాన్ని బట్టి డాక్యుమెంట్‌లకు స్కోర్‌లను ఇస్తుంది, తద్వారా ఏదైనా సిస్టమ్ నుండి వచ్చిన బలమైన అభ్యర్థనలకు (candidates) సమాన అవకాశం లభిస్తుంది. విలీనం చేసిన తర్వాత, మేము కలిపి వచ్చిన ఫలితాలపై cross-encoder rerankerని రన్ చేసి, కేవలం టాప్ ఫైవ్ ఫలితాలను మాత్రమే తిరిగి ఇస్తాము. ఈ reranker సుమారు యాభై మిల్లీ సెకన్ల లేటెన్సీని పెంచినప్పటికీ, మా రీకాల్‌ను పదిహేను శాతం మెరుగుపరిచింది. జనరేషన్ క్వాలిటీ పరంగా చూస్తే, ఈ చిన్న లాభం చాలా పెద్ద ఫలితాన్ని ఇస్తుంది.

క్వెరీ ఎక్స్‌పాన్షన్ (Query Expansion)

యూజర్లు క్వెరీలను అడగడంలో అంత నైపుణ్యం కలిగి ఉండరు. వారు పదాలను సంక్షిప్తీకరించడం (abbreviate), తప్పుగా స్పెల్లింగ్ చేయడం లేదా మూడు ప్రశ్నలను ఒకే సుదీర్ఘమైన వాక్యంలో అడగడం వంటివి చేస్తారు. వారు టైప్ చేసిన దానిని యథాతథంగా సెర్చ్ చేస్తే, వారికి నిజంగా అవసరమైన డాక్యుమెంట్‌లను మీరు కోల్పోతారు.

ఇప్పుడు మేము ప్రతి క్వెరీ ఇండెక్స్‌కు వెళ్లే ముందే దానిని మారుస్తాము (transform). మొదటిది, పర్యాయపదాలు (synonyms) మరియు ప్రత్యామ్నాయ పదజాలాన్ని కవర్ చేయడానికి అసలు ప్రశ్న యొక్క వివిధ వెర్షన్లను రూపొందిస్తాము. రెండవది, సంక్లిష్టమైన ప్రశ్నలను చిన్న చిన్న ఉప-ప్రశ్నలుగా (sub-questions) విడగొడతాము. "అంతర్జాతీయ కస్టమర్లకు రీఫండ్ ఎందుకు ఫెయిల్ అవుతోంది మరియు నేను దానిని ఎలా సరిచేయాలి?" అనే క్వెరీ రెండు వేర్వేరు సెర్చ్‌లుగా మారుతుంది: ఒకటి అంతర్జాతీయ రీఫండ్ వైఫల్యాల గురించి, మరొకటి పరిష్కార మార్గాల గురించి. క్వెరీ ఎక్స్‌పాన్షన్ ద్వారా మాత్రమే మా రీకాల్ 78 శాతం నుండి 94 శాతానికి పెరిగింది. దీని నుండి నేర్చుకోవాల్సిన పాఠం స్పష్టంగా ఉంది: యూజర్ అడిగిన మొదటి డ్రాఫ్ట్‌ను మాత్రమే నమ్మకండి. వారికి సహాయం చేయండి.

ఊహించడం ఆపండి, వెతకడం ప్రారంభించండి (Stop Guessing, Start Searching)

చంక్ సైజు, ఓవర్‌ల్యాప్ శాతం (overlap percentage), top-k కటాఫ్ మరియు reranker డెప్ธ์ వంటివి చేతితో ట్యూన్ చేయడం అసాధ్యమైన రీతిలో పరస్పరం ప్రభావితం అవుతాయి. మేము 256 టోకెన్లు 512 కంటే మెరుగ్గా ఉన్నాయా లేదా అని చర్చించడానికే చాలా సమయం వృథా చేశాము, కానీ అసలు కోహెరెన్స్ (coherence)ను దెబ్బతీస్తున్న ఓవర్‌ల్యాప్ సెట్టింగ్‌ను మాత్రం పట్టించుకోలేదు.

మేము ఇంట్యూషన్ (intuition) స్థానంలో బేసియన్ ఆప్టిమైజేషన్ (Bayesian optimization)ను ఉపయోగించాము. స్పష్టంగా తప్పుగా ఉన్న ప్రాంతాలపై కంప్యూట్ వనరులను వృథా చేసే గ్రిడ్ సెర్చ్ (grid search)కు బదులుగా, బేసియన్ పద్ధతులు ఏది పనిచేస్తుందో ఒక ప్రాబబిలిస్టిక్ మోడల్‌ను నిర్మిస్తాయి మరియు లేటెన్సీని తగ్గించేలా రీకాల్‌ను గరిష్టీకరించే పరేటో ఫ్రాంటియర్ (Pareto frontier)ను వెతుకుతాయి. మా స్టాక్ (stack) కోసం, దీని అర్థం లేటెన్సీ బడ్జెట్‌ను పెంచకుండా 95 శాతం రీకాల్ ఇచ్చే చంక్ సైజు, ఓవర్‌ల్యాప్ మరియు top-k యొక్క నిర్దిష్ట కలయికను కనుగొనడం. వివిధ యూజ్ కేస్‌లు ఆ ఫ్రాంటియర్‌లోని వేర్వేరు పాయింట్ల వద్ద ఉన్నాయి. కస్టమర్-ఫేసింగ్ చాట్‌బాట్‌లు వేగానికి ప్రాధాన్యత ఇచ్చాయి. అంతర్గత లీగల్ రీసెర్చ్ రీకాల్‌కు ప్రాధాన్యత ఇచ్చింది. ఆటోమేటెడ్ ఆప్టిమైజేషన్ వల్ల కాన్ఫిగరేషన్ ఫైల్‌లను మాన్యువల్‌గా కాపీ-పేస్ట్ చేయకుండానే మేము రెండింటినీ అందించగలిగాము.

ఫలితాలు (The Results)

అంకెలు స్పష్టంగా చెబుతున్నాయి. మా Recall@10 డెబ్బై ఎనిమిది శాతం నుండి తొంభై ఐదు శాతానికి పెరిగింది. p95 latency 850 మిల్లీసెకన్ల నుండి 320 మిల్లీసెకన్లకు తగ్గింది. మోడల్‌కు అనవసరమైన సమాచారం (noise) బదులుగా చివరకు సంబంధిత సందర్భం (relevant context) అందడం వల్ల, hallucination రేటు పన్నెండు శాతం నుండి మూడు శాతానికి పడిపోయింది. మెరుగైన రిట్రీవల్ సమాధానాలను వేగంగా చేయడమే కాకుండా, వాటిని ఖచ్చితమైనవిగా మారుస్తుంది.

తదుపరి ఏమి చేయాలి

మీరు మీ రిట్రీవల్ లేయర్‌ను (retrieval layer) మళ్లీ నిర్మిస్తుంటే, ఇక్కడి నుండి ప్రారంభించండి:

  • టోకెన్ కౌంట్‌తో కాకుండా, డాక్యుమెంట్ స్ట్రక్చర్ ఆధారంగా చంక్ (chunk) చేయండి. మీ స్ప్లిటింగ్ స్ట్రాటజీని మీ డేటా ఆకృతికి అనుగుణంగా మార్చుకోండి.
  • హైబ్రిడ్ రిట్రీవల్‌ను (hybrid retrieval) ఉపయోగించండి. వెక్టర్ సెర్చ్ (vector search) మరియు BM25లను కలిపి, Reciprocal Rank Fusionతో విలీనం చేసి, జనరేట్ చేసే ముందు రీ-ర్యాంక్ (rerank) చేయండి.
  • మెరుగైన కవరేజ్ కోసం క్వెరీలను (queries) విస్తరించండి. సెర్చ్ ప్రారంభం కావడానికి ముందే వాటిని తిరిగి రాయండి (rephrase) మరియు విడగొట్టండి (decompose).
  • టెస్టింగ్ కోసం గోల్డెన్ డేటాసెట్‌ను (golden dataset) రూపొందించండి. మీరు కొలవలేని దాన్ని ఆప్టిమైజ్ చేయలేరు.
  • ఆటోమేటెడ్ టూల్స్‌తో పారామీటర్లను ఆప్టిమైజ్ చేయండి. మీ అంతర్ దృష్టి (gut feeling) కంటే బేసియన్ సెర్చ్ (Bayesian search) మెరుగైన సెట్టింగ్‌లను కనుగొంటుంది.

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

ఐచ్ఛిక లెర్నింగ్ కమ్యూనిటీ: GyaanSetu AI