ఒక Jupyter notebook నుండి Retrieval-Augmented Generation (RAG) పైప్లైన్ను లైవ్ సర్వీస్లోకి తీసుకురావడానికి నాలుగు నెలల సమయం పట్టింది. ఒక ప్రదర్శన కోసం చేసిన డెమోను, వినియోగదారులు నిజంగా నమ్మదగిన వ్యవస్థగా మార్చిన ఐదు కీలకమైన ఎంపికలను రచయిత గుర్తించారు. ఈ మార్పుల ప్రభావం గణాంకాల్లో కనిపిస్తుంది: టెక్స్ట్ను విభజించే విధానంలో చేసిన చిన్న మార్పు వల్ల రిట్రీవల్ హిట్ రేట్ 61% నుండి 83%కి పెరిగింది, మరియు 200 నిజమైన క్వెరీలతో కూడిన చిన్న ఎవాల్యుయేషన్ సెట్ వల్ల కస్టమర్లకు చేరకముందే చాలా రిగ్రెషన్లను గుర్తించగలుగుతున్నాము.
Why it matters
RAG డెమోలు ఆకట్టుకునేలా ఉంటాయి – అవి సెకన్లలో ఒక పేరాను వెతికి, సరైన సమాధానాన్ని ఇస్తాయి. కానీ ప్రొడక్షన్లో, అదే విధానం తరచుగా పాతబడిన వాస్తవాలను, తప్పుగా ఉన్న ఎర్రర్ కోడ్లను లేదా విచ్ఛిన్నమైన వాక్యాలను అందిస్తుంది, దీనివల్ల వినియోగదారుల నమ్మకం తగ్గుతుంది. ఇక్కడ సమస్య భాషా నమూనా (language model) లో ఉండదు; కంటెంట్ను ఎలా తీసుకుంటున్నారు (ingested), ఇండెక్స్ చేస్తున్నారు మరియు అందిస్తున్నారు అనే దానిలోనే అసలు సమస్య ఉంటుంది. పైప్లైన్ను సరిగ్గా రూపొందించడం అనేది విలువను జోడించే ఉత్పత్తికి మరియు నష్టాన్ని కలిగించే ఉత్పత్తికి మధ్య ఉన్న తేడాను నిర్ణయిస్తుంది.
1. Stop using fixed-size chunks
చాలా ప్రోటోటైప్లు ప్రతి డాక్యుమెంట్ను 512-టోకెన్ బ్లాక్లుగా ముక్కలు చేస్తాయి. ఇది చిన్న టెక్స్ట్లకు పని చేస్తుంది కానీ టెక్నికల్ మాన్యువల్స్, సపోర్ట్ థ్రెడ్లు మరియు కోడ్ స్నిప్పెట్లను దెబ్బతీస్తుంది. వాక్యాలు విడిపోతాయి, హెడ్డింగ్లు మాయమవుతాయి మరియు రిట్రీవల్ ఇంజిన్ వినియోగదారుడు ఆశించే సందర్భాన్ని (context) సరిగ్గా గుర్తించలేదు.
స్ట్రక్చర్-అవేర్ చంకింగ్కు (structure-aware chunking) మారండి—అంటే హెడ్డింగ్లు, సంభాషణల సరిహద్దులు లేదా కోడ్ ఫెన్సెస్ వద్ద విభజించడం ద్వారా అర్థవంతమైన యూనిట్లను (semantic units) కాపాడండి. రచయిత యొక్క సిస్టమ్లో, దీనివల్ల మాత్రమే సంబంధిత సమాచారాన్ని కనుగొనే క్వెరీల శాతం 61% నుండి 83%కి పెరిగింది. ఈ మెరుగుదల డేటా ఫార్మాట్ మార్పు వల్ల వచ్చింది; ప్రాథమిక మోడల్ మారలేదు.
2. Use hybrid search
ప్యూర్ వెక్టర్ సెర్చ్ (embedding-based similarity) ఒకే అర్థం ఉన్న పేజీలను వెతకడంలో అద్భుతంగా పనిచేస్తుంది, కానీ ఎర్రర్ కోడ్లు, వెర్షన్ నంబర్లు లేదా ప్రత్యేక సాంకేతిక పదాల వంటి ఖచ్చితమైన గుర్తింపుల (exact identifiers) విషయంలో అది విఫలమవుతుంది. "ERR-XXXX" వంటి ఎర్రర్ కోడ్ కోసం వెతికే వినియోగదారుడికి, ఆ కోడ్ లేని కానీ అర్థవంతంగా ఉండే ఒక పేరా దొరకవచ్చు.
హైబ్రిడ్ సెర్చ్ అనేది డెన్స్ వెక్టర్ ఇండెక్స్ను సాంప్రదాయ BM25 ఇండెక్స్తో (term-frequency ఆధారితం) కలుపుతుంది. ఈ రెండు స్కోర్లను బ్యాలెన్స్ చేయడం ద్వారా, సిస్టమ్ అర్థవంతంగా దగ్గరగా ఉండి, వినియోగదారుడు టైప్ చేసిన ఖచ్చితమైన పదాలను కలిగి ఉన్న అంశాలను వెలికితీస్తుంది. ప్రొడక్షన్ కోసం, హైబ్రిడ్ సెర్చ్ అనేది ఒక అవసరమైన ప్రాథమిక అంశం (baseline requirement), కేవలం అదనపు ఫీచర్ కాదు.
3. Handle stale data
పాతబడిన ధరల పట్టికలు, పాలసీ పత్రాలు లేదా ఫర్మ్వేర్ రిలీజ్ నోట్స్ సిస్టమ్ యొక్క విశ్వసనీయతను త్వరగా దెబ్బతీస్తాయి. ఇండెక్స్ను తాజాగా ఉంచడానికి మూడు ఆచరణాత్మక దశలు:
- ప్రతి డాక్యుమెంట్కు వెర్షన్ స్టాంప్ లేదా టైమ్స్టాంప్ను జోడించండి.
- స్కోరింగ్ సమయంలో recency boostని ఉపయోగించండి, తద్వారా కొత్త అంశాలు పాత వాటి కంటే ముందు కనిపిస్తాయి.
- సోర్స్ సిస్టమ్స్ నుండి మార్పులను తీసుకోవడానికి ప్రతి రాత్రి ఇన్క్రిమెంటల్ రీ-ఇండెక్సింగ్ (incremental re-indexing) చేయండి.
ఈ జాగ్రత్తలు సిస్టమ్ గత త్రైమాసికంలో చెల్లుబాటు అయ్యే ధరను లేదా ఇప్పటికే రద్దయిన పాలసీని చూపించకుండా నిరోధిస్తాయి.
4. Rerank instead of upgrading models
ఎంబెడ్డింగ్ మోడల్ను అప్గ్రేడ్ చేయడం వల్ల నాణ్యతలో స్వల్ప పెరుగుదల మాత్రమే ఉంటుంది, కానీ క్రాస్-ఎన్కోడర్ రీర్యాంకర్ (cross-encoder reranker) జోడించడం వల్ల తక్కువ ఖర్చుతో చాలా ఎక్కువ మెరుగుదల లభిస్తుంది.
ప్రొడక్షన్ ఫ్లో హైబ్రిడ్ సెర్చ్ ఉపయోగించి 20 చౌకైన అభ్యర్థులను (candidates) సేకరిస్తుంది, ఆపై వాటిని రీర్యాంకర్ ద్వారా పంపి టాప్ ఐదును ఎంపిక చేస్తుంది. ఈ రెండు దశల విధానం, పూర్తి మోడల్ అప్గ్రేడ్ ఖర్చులో చాలా తక్కువ ఖర్చుతో ఎక్కువ నాణ్యతను అందిస్తుంది.
5. Build a real evaluation set
మీరు కొలవలేని దాన్ని మెరుగుపరచలేరు. రచయిత 200 అసలైన యూజర్ క్వెరీలతో కూడిన టెస్ట్ సూట్ను రూపొందించారు, ప్రతి క్వెరీకి నిపుణులచే రూపొందించబడిన సమాధానం జత చేయబడింది. ప్రతి కోడ్ మార్పు ఈ సూట్పై పరీక్షించబడుతుంది; ఏదైనా రిగ్రెషన్ ఉంటే డిప్లాయ్మెంట్ కంటే ముందే దొరికిపోతుంది.
వినియోగదారుడు తప్పు సమాధానం గురించి ఫిర్యాదు చేసినప్పుడు, ఆ క్వెరీని వెంటనే ఎవాల్యుయేషన్ సెట్కు జోడించండి, తద్వారా నిజ ప్రపంచ వైఫల్యాలను భవిష్యత్తు రక్షణ కవచాలుగా మార్చుకోండి. ప్రతి జనరేట్ చేయబడిన సమాధానాన్ని నిరంతరం లాగ్ చేయడం వల్ల ఎవాల్యుయేషన్ లూప్ మెరుగుపడుతుంది, తద్వారా సిస్టమ్ వాస్తవ వినియోగానికి అనుగుణంగా ఉంటుంది.
The production pipeline in practice
- Ingest: స్ట్రక్చర్-అవేర్ చంకింగ్ హెడ్డింగ్లు, కోడ్ బ్లాక్లు మరియు సంభాషణలను కాపాడుతుంది.
- Index: డెన్స్ ఎంబెడ్డింగ్లు మరియు BM25 టర్మ్ స్టాటిస్టిక్స్ రెండింటినీ నిల్వ చేస్తుంది.
- Retrieve: హైబ్రిడ్ సెర్చ్ అర్థవంతమైన సారూప్యత మరియు ఖచ్చితమైన పదాల సరిపోలికను బ్యాలెన్స్ చేస్తూ 20 అభ్యర్థులను అందిస్తుంది.
- Rerank: క్రాస్-ఎన్కోడర్ జాబితాను అత్యంత ఆశాజనకమైన ఐదు పేరాలకు తగ్గిస్తుంది.
- Generate: LLM ఈ టాప్ చంక్స్ను మరియు వాటి మెటాడేటాను స్వీకరించి తుది సమాధానాన్ని రూపొందిస్తుంది.
- Evaluate: ప్రతి ప్రతిస్పందన లాగ్ చేయబడుతుంది; వైఫల్యాలను తిరిగి 200-క్వెరీ టెస్ట్ సెట్లోకి పంపిస్తారు.
Stakes and trade-offs
ఒక చక్కగా సర్దుబాటు చేయబడిన పైప్లైన్ హాలూసినేషన్లను (hallucinations) తగ్గిస్తుంది, సమాధానాల సంబంధితతను మెరుగుపరుస్తుంది మరియు అవసరానికి మించి ఉపయోగించే మోడళ్ల ఖర్చును తగ్గిస్తుంది. దీని వల్ల వినియోగదారుల సంతృప్తి పెరుగుతుంది మరియు సపోర్ట్ ఖర్చులు తగ్గుతాయి. ఈ దశలను విస్మరిస్తే, అది బ్రాండ్ నమ్మకాన్ని దెబ్బతీసే మరియు ఖరీదైన అత్యవసర సమస్యల పరిష్కారానికి (firefighting) దారితీసే బలహీనమైన సేవలను అందిస్తుంది.
తదుపరి గమనించవలసినవి
ఓపెన్-సోర్స్ embeddings మరియు vector databases పరిణతి చెందుతున్న కొద్దీ, “dense” మరియు “sparse” retrieval మధ్య వ్యత్యాసం తగ్గుతుంది, కానీ semantic మరియు exact matchingలను కలిపే సూత్రం అలాగే ఉంటుంది.
ముఖ్యాంశం: ఒక RAG సిస్టమ్లో, language model అనేది అరుదుగా choke point గా మారుతుంది. అసలైన పని అనేది మీరు ప్రాథమిక కంటెంట్ను ఎలా విభజించి (slice), ఇండెక్స్ చేసి, మరియు ప్రదర్శిస్తారు (surface) అనే దానిపై ఆధారపడి ఉంటుంది. ఈ నిర్ణయాలను సరిగ్గా తీసుకోవడం ద్వారా, ఒక ఆకర్షణీయమైన demoను నమ్మదగిన ఉత్పత్తిగా మార్చవచ్చు.