చాలా RAG డెమోలు లాప్టాప్లో అద్భుతంగా కనిపిస్తాయి. ఒక ఇరవై పేజీల PDF ని ఇచ్చి, ఒక ప్రశ్న అడిగితే, అది సరైన పేరాగ్రాఫ్ను చూపిస్తుంది. కానీ అదే పైప్లైన్ను ప్రొడక్షన్లోకి తీసుకెళ్లడం అనేది అసలైన సవాలు. లీగల్ డాక్యుమెంట్లు సెంటెన్స్ లెవల్లో విడిపోతాయి. భారీ API రిఫరెన్స్లు ముఖ్యమైన సమాచారాన్ని కప్పివేసి అనవసరమైన సమాచారంతో నింపేస్తాయి. లేటెన్సీ పెరుగుతుంది. యూజర్లు వేచి చూడలేక వెళ్ళిపోతారు. మేము ఈ సమస్యను తీవ్రంగా ఎదుర్కొన్నాము. అందుకే మేము రిట్రీవల్ లేయర్ను పూర్తిగా మార్చి, ఒక మెజరబుల్, ట్యూనబుల్ సిస్టమ్గా మళ్ళీ నిర్మించాము. దీని ఫలితంగా, యూజర్ ఎక్స్పీరియన్స్ను దెబ్బతీయకుండా 95% రీకాల్ సాధించే పైప్లైన్ సిద్ధమైంది.
ప్రొడక్షన్లో RAG డెమోలు ఎందుకు విఫలమవుతాయి
హాబీ ప్రాజెక్ట్లు మరియు ప్రారంభ దశ ఉత్పత్తులలో స్టాండర్డ్ స్టాక్ ఆశ్చర్యకరంగా ఒకేలా ఉంటుంది: ఫిక్స్డ్ టోకెన్ చంక్స్, ఆఫ్-ది-షెల్ఫ్ ఎంబెడ్డింగ్స్ మరియు ఒకే వెక్టర్ సెర్చ్ కాల్. మీ కార్పస్ క్లీన్గా, చిన్నదిగా మరియు ప్రిడిక్టబుల్గా ఉన్నప్పుడు ఈ సరళత బాగా పనిచేస్తుంది. కానీ ప్రొడక్షన్ డేటా అలా ఉండదు. 512 టోకెన్ల ఫిక్స్డ్ చంక్ అనేది ఒక SaaS కాంట్రాక్ట్లోని ఇండెమ్నిఫికేషన్ క్లాజ్ను మధ్యలోనే కత్తిరించవచ్చు. అప్పుడు మీ రిట్రీవల్ లేయర్ లీగల్ అబ్లిగేషన్ను సగం మాత్రమే మోడల్కు అందిస్తుంది మరియు ఒక లయబిలిటీ ప్రశ్నను అడుగుతుంది. సందర్భం (context) సరిగ్గా లేకపోవడం వల్ల మోడల్ హాలూసినేట్ (hallucinate) చేస్తుంది.
పెద్ద టెక్నికల్ డాక్యుమెంట్లు ఈ సమస్యను మరింత పెంచుతాయి. API డాక్యుమెంటేషన్లో ఫంక్షన్ సిగ్నేచర్లు, టేబుల్స్ మరియు కోడ్ బ్లాక్స్ ఉంటాయి. ఒక ఫిక్స్డ్ విండో ఒక TypeScript ఇంటర్ఫేస్ను మధ్యలో క్యాప్చర్ చేయవచ్చు కానీ దాని పైన ఉన్న ఫంక్షన్ పేరును లేదా కింద ఉన్న యూసేజ్ ఎగ్జాంపుల్ను మిస్ చేయవచ్చు. దీనివల్ల ఎంబెడ్డింగ్ వెక్టర్ యూజర్ అడిగిన సామర్థ్యాన్ని కాకుండా, కేవలం సింటాక్స్ ఫ్రాగ్మెంట్లను మాత్రమే సూచిస్తుంది. తప్పుడు సమాచారం ఇస్తే, తప్పుడు ఫలితాలే వస్తాయి (Garbage in, hallucination out).
టోకెన్ కౌంట్తో కాకుండా, స్ట్రక్చర్ ఆధారంగా చంకింగ్ చేయండి
మేము చేసిన మొదటి మార్పు ఏమిటంటే, చంక్స్ను కేవలం టోకెన్ల సముదాయాలుగా చూడటం మానేయడం. చంక్స్ అనేవి సెమాంటిక్ యూనిట్లు. మీరు దేనిని ఇండెక్స్ చేస్తున్నారనే దానిపై సరైన వ్యూహం ఆధారపడి ఉంటుంది.
లీగల్ డాక్యుమెంట్ల కోసం, మేము డాక్యుమెంట్ హైరార్కీని గౌరవించే రికర్సివ్ చంకింగ్కు మారాము. ఇది సెక్షన్స్, సబ్-సెక్షన్స్ మరియు క్లాజులను బౌండరీలుగా పరిగణిస్తుంది. ఒక క్లాజ్ అనేది అర్థవంతమైన యూనిట్ కాబట్టి అది విడిపోకుండా ఉంటుంది. ఒకవేళ దానిని మధ్యలో కత్తిరిస్తే, లీగల్ లాజిక్ దెబ్బతింటుంది.
API డాక్స్ కోసం, స్ట్రక్చర్-అవేర్ చంకింగ్ ఫంక్షన్లు, క్లాస్లు మరియు ఎండ్పాయింట్లను అటామిక్గా పరిగణిస్తుంది. ఒక చంక్లో ఫంక్షన్ సిగ్నేచర్, దాని ఆర్గ్యుమెంట్స్ మరియు దాని డాక్స్ట్రింగ్ ఉండవచ్చు. టోకెన్ కౌంటర్ పెరిగినంత మాత్రాన అది తదుపరి ఫంక్షన్లోకి వెళ్ళదు. ఇది ఎంబెడ్డింగ్ ఒక నిర్దిష్ట సామర్థ్యంపై దృష్టి పెట్టేలా చేస్తుంది.
సపోర్ట్ టికెట్లు మరింత క్లిష్టంగా ఉంటాయి. అవి సంభాషణల రూపంలో, థ్రెడ్ల రూపంలో మరియు నాన్-లీనియర్గా ఉంటాయి. ఫిక్స్డ్ చంక్స్ ఒక ఇంజనీర్ ఇచ్చిన స్టేటస్ అప్డేట్ను మరియు అదే థ్రెడ్లోని కస్టమర్ ఫిర్యాదును కలిపి ఒకే యూనిట్గా చూపించవచ్చు. మేము సెమాంటిక్ చంకింగ్కు మారాము, అంటే టోకెన్ బడ్జెట్ అయిపోయినప్పుడు కాకుండా, టాపిక్ లేదా స్పీకర్ మారినప్పుడు విభజించడం జరుగుతుంది.
సంస్థలలో ఇంటర్నల్ వికీలు తరచుగా అస్తవ్యస్తంగా ఉంటాయి. ఫార్మాటింగ్ సరిగ్గా ఉండదు, హెడర్లు ఉండవు మరియు సెక్షన్లు కలిసిపోయి ఉంటాయి. వీటి కోసం, మేము LLM-ఆధారిత చంకింగ్ను ఉపయోగిస్తాము. ఒక చిన్న మోడల్ ఎంబెడ్డింగ్ను రూపొందించే ముందే లాజికల్ బౌండరీలను గుర్తిస్తుంది. ఇది క్యారెక్టర్ స్ప్లిట్ కంటే ఎక్కువ ఖర్చుతో కూడుకున్నదే కానీ, రిట్రీవల్ క్వాలిటీ వల్ల వెంటనే లాభం చేకూరుతుంది.
హైబ్రిడ్ రిట్రీవల్: సిగ్నల్స్ను కలపండి
వెక్టర్ సెర్చ్ శక్తివంతమైనదే కానీ దానికి కొన్ని లోపాలు (blind spots) ఉన్నాయి. ERR_CONNECTION_REFUSED_0x800 వంటి ఖచ్చితమైన ఎర్రర్ కోడ్ను పేస్ట్ చేసినప్పుడు, ఎంబెడ్డింగ్ స్పేస్ వాటిని దగ్గరగా ఉంచడం వల్ల, సిమిలారిటీ సెర్చ్ సంబంధం లేని మాడ్యూల్ యొక్క ట్రబుల్ షూటింగ్ గైడ్ను కూడా చూపించవచ్చు. ఖచ్చితమైన మ్యాచ్లు (Exact matches) ముఖ్యం, మరియు వెక్టర్ సెర్చ్ మాత్రమే వాటిని సరిగ్గా గుర్తించలేకపోవచ్చు.
BM25తో కూడిన కీవర్డ్ సెర్చ్ ఈ ఎక్సాక్ట్-మ్యాచ్ సమస్యను అద్భుతంగా పరిష్కరిస్తుంది. కానీ ఇది కాన్సెప్చువల్ డిస్టెన్స్ను (conceptual distance) గుర్తించలేదు. ఒక యూజర్ "performance degradation under heavy load" గురించి అడిగితే, "slow throughput during traffic spikes" అని వివరించే డయాగ్నోస్టిక్ నోట్ను BM25 గుర్తించలేకపోవచ్చు, ఎందుకంటే అక్కడ కీవర్డ్ ఓవర్ల్యాప్ తక్కువగా ఉంటుంది.
మేము ఏదో ఒకటి మాత్రమే ఎంచుకోవడం మానేసి, రెండింటినీ సమాంతరంగా నడపడం ప్రారంభించాము. వెక్టర్ మరియు కీవర్డ్ సెర్చ్లు తమ స్వంత ర్యాంక్డ్ లిస్ట్లను అందిస్తాయి. మేము వాటిని Reciprocal Rank Fusion (RRF) తో విలీనం చేస్తాము. RRF దాని ప్రభావశీలతలో చాలా సరళంగా మరియు శక్తివంతంగా ఉంటుంది. ఇది ప్రతి లిస్ట్లో ఒక డాక్యుమెంట్ ఎక్కడ ఉందో దాని ఆధారంగా స్కోర్ను ఇస్తుంది. రెండు సిస్టమ్స్లోనూ టాప్లో ఉన్న డాక్యుమెంట్లకు భారీ బూస్ట్ లభిస్తుంది. కేవలం ఒక ఇంజిన్ మాత్రమే గుర్తించిన డాక్యుమెంట్లు కూడా ఫైనల్ కాండిడేట్ సెట్లో చోటు సంపాదిస్తాయి.
ఫ్యూజన్ తర్వాత, మేము టాప్ కాండిడేట్లను cross-encoder reranker ద్వారా రన్ చేస్తాము. ఇది ఉచితం కాదు. ఇది సుమారు 50 మిల్లీసెకన్ల కంప్యూట్ సమయాన్ని తీసుకుంటుంది. ఇది రీకాల్ను (recall) 15% పెంచుతుంది. cross-encoder పూర్తి క్వెరీ మరియు ప్రతి కాండిడేట్ చంక్ను కలిపి విశ్లేషిస్తుంది, దీనివల్ల bi-encoder embedding కంటే చాలా మెరుగైన మరియు సూక్ష్మమైన relevance score లభిస్తుంది. ఆ అదనపు 50 మిల్లీసెకన్లు చాలా లాభదాయకం. ఇది LLMకి తప్పుడు కాంటెక్స్ట్ విండోను పంపకుండా మరియు అయోమయంగా లేదా హాలూసినేట్ (hallucinated) చేసిన సమాధానం కోసం రెండు సెకన్ల పాటు వేచి ఉండకుండా మిమ్మల్ని కాపాడుతుంది.
సెర్చ్ చేసే ముందే క్వెరీని సరిచేయండి
యూజర్లు సెర్చ్ ఇంజనీర్లలాగా క్వెరీలను రాయరు. వారు "app broken" అని టైప్ చేస్తారు. అర్థం కాని లాగ్ ఫ్రాగ్మెంట్లను (log fragments) పేస్ట్ చేస్తారు. అస్పష్టమైన, ద్వంద్వార్థం ఉన్న ప్రశ్నలు అడుగుతారు. మీరు ఆ ముడి స్ట్రింగ్స్ను నేరుగా ఇండెక్స్కు పంపితే, మీకు తప్పుడు ఫలితాలే వస్తాయి.
మేము ప్రతి క్వెరీని రిట్రీవల్ ఇంజిన్కు పంపే ముందే మారుస్తాము.
మొదటిది, query expansion. సిస్టమ్ ఒకే చిన్న ప్రశ్న నుండి బహుళ సెర్చ్ పదాలను రూపొందిస్తుంది. ఒక యూజర్, "How do I fix the timeout?" అని అడిగితే, ఇంజిన్ దానిని connection timeouts, read timeouts, gateway timeouts మరియు retry logic వంటి అంశాలను కవర్ చేసేలా విస్తరిస్తుంది. ఈ పద్ధతి వల్ల మా రీకాల్ 78% నుండి 96%కి పెరిగింది.
రెండవది, query decomposition. సంక్లిష్టమైన ప్రశ్నలు చిన్న చిన్న ఉప-ప్రశ్నలుగా (sub-questions) విడగొట్టబడతాయి. "What's the refund policy for enterprise customers past 90 days and how does it differ from monthly plans?" వంటి క్వెరీ, ఒకే పెద్ద embedding lookup కంటే రెండు ప్రత్యేకమైన సెర్చ్లుగా మారుతుంది. ప్రతి ఉప-ప్రశ్న స్వతంత్రంగా ఇండెక్స్ను చేరుకుంటుంది. ఫలితాలు తర్వాత (downstream) తిరిగి అనుసంధానించబడతాయి. ఇది రిట్రీవల్ను ఖచ్చితంగా ఉంచుతుంది, తద్వారా ఒకే embedding ఒకేసారి డజన్ల కొద్దీ కాన్సెప్ట్లను మ్యాచ్ చేయడానికి ప్రయత్నించినప్పుడు జరిగే సమాచార క్షీణతను (dilution) నిరోధిస్తుంది.
మీ పైప్లైన్ను Bayesian Search ద్వారా ట్యూన్ చేయండి
మీరు ఇంకా chunk size, overlap ratios మరియు retrieval weightsలను మాన్యువల్గా ట్యూన్ చేస్తూ ఉంటే, మీరు పెర్ఫార్మెన్స్ను వదులుకుంటున్నట్లే. మేము ఊహించడం మానేసాము.
మేము chunk size, overlap percentage, vector-versus-BM25 weights మరియు reranker thresholds వంటివన్నీ వేరియబుల్స్గా ఉండేలా ఒక సెర్చ్ స్పేస్ను నిర్వచించాము. ఆపై మేము Bayesian optimizationను వర్తింపజేశాము. వందలాది రాండమ్ కాన్ఫిగరేషన్ల ద్వారా grid-searching చేయడం కంటే, Bayesian search ఏది పనిచేస్తుందో దాని యొక్క ఒక probabilistic modelను నిర్మిస్తుంది. ఇది ఒక కాన్ఫిగరేషన్ను ప్రతిపాదిస్తుంది, రీకాల్ మరియు లేటెన్సీని గమనిస్తుంది, దాని నమ్మకాలను (beliefs) అప్డేట్ చేస్తుంది మరియు తదుపరి కాన్ఫిగరేషన్ను ప్రతిపాదిస్తుంది. కాలక్రమేణా, ఇది ఒక మనిషి మాన్యువల్గా సాధించలేని సమతుల్యతను చేరుకుంటుంది.
మేము ఎప్పుడూ ప్రయత్నించని కాంబినేషన్లను ఇది కనుగొంది. ఎక్కువ overlap ఉన్న చిన్న చంక్లు. డెన్స్ వెక్టర్ సెర్చ్పై కొంచెం తక్కువ వెయిటేజీ మరియు మరింత అగ్రెసివ్ reranker threshold. ఈ అన్వేషించని (non-obvious) ట్రేడ్ఆఫ్స్ (tradeoffs) మాకు అధిక రీకాల్ మరియు తక్కువ లేటెన్సీ రెండింటినీ అందించాయి.
ఇది ఒకసారి చేసే సెటప్ టాస్క్ కాదు. మేము ప్రతి నెలా hyperparameter optimizationను మళ్ళీ రన్ చేస్తాము. మీ corpus మారుతూ ఉంటుంది. యూజర్ ప్రవర్తన మారుతుంది. మీ పైప్లైన్ పాతబడిపోకుండా, దానికి అనుగుణంగా మారుతూ ఉండాలి.
ఫలితం
ఆ రీబిల్డ్ యొక్క ముడి ఫలితాలను ఎవరూ ఖండించలేరు.
పదివ స్థానంలో (position ten) రీకాల్ 78% నుండి 95%కి పెరిగింది. సరైన సమాధానం మా నాలెడ్జ్ బేస్లో ఉన్నప్పుడు, మేము ఇరవైసార్లు ఇరవై సార్లు (nineteen out of twenty) దానిని చూపిస్తాము. 95th percentile వద్ద లేటెన్సీ 850 మిల్లీసెకన్ల నుండి 320 మిల్లీసెకన్లకు తగ్గింది. చాట్ చాలా వేగంగా, తక్షణమే స్పందిస్తున్నట్లు అనిపిస్తుంది.
మెరుగైన రిట్రీవల్, లాంగ్వేజ్ మోడల్కు మెరుగైన groundingని అందించింది. హాలూసినేషన్ రేటు 12% నుండి 3%కి తగ్గింది. మోడల్ ముందు సరైన కాంటెక్స్ట్ ఉన్నప్పుడు, అది తప్పుడు నిజాలను సృష్టించడం ఆపేస్తుంది. క్వెరీకి అయ్యే ఖర్చు 38% తగ్గింది. వేగవంతమైన, ఖచ్చితమైన రిట్రీవల్ వల్ల అనవసరమైన కాంటెక్స్ట్, రిట్రై లూప్లు మరియు అనవసరమైన ప్రాంప్ట్ల కోసం వెచ్చించే టోకెన్లు తగ్గాయి.
దీనిని ఇన్ఫ్రాస్ట్రక్చర్లా నిర్మించండి
మీరు ప్రోటోటైప్ నుండి ప్రొడక్షన్కు మారుతున్నట్లయితే, రిట్రీవల్ను కేవలం ఒక కాన్ఫిగరేషన్లా కాకుండా ఇన్ఫ్రాస్ట్రక్చర్ కోడ్లా పరిగణించండి.