చాలా బృందాలు ఇప్పటికీ తమ మొదటి రిట్రీవల్ పైప్లైన్ను ఒకే విధంగా రూపొందిస్తున్నాయి. వారు 512 వంటి ఒక నిర్ణీత టోకెన్ పరిమితిని ఎంచుకుంటారు, పత్రాలను సమానమైన బ్లాక్లుగా విభజిస్తారు మరియు ఆ బ్లాక్లను వెక్టర్ డేటాబేస్లోకి పంపిస్తారు. సరళమైన ప్రశ్నలతో కూడిన చిన్న డేటాసెట్పై, ఇది అద్భుతంగా కనిపిస్తుంది. కానీ ప్రొడక్షన్లో, ఇది విఫలమవుతుంది.
ఒక క్లాజ్ (clause) వాక్యం మధ్యలో విడిపోయినప్పుడు, లీగల్ కాంట్రాక్టులు అర్థం లేని ముక్కలుగా విడిపోతాయి. ఒకే చంక్ మూడు సంబంధం లేని ఫంక్షన్లను కలిపివేస్తే, API డాక్యుమెంటేషన్ గందరగోళంగా మారుతుంది. సెగ్మెంట్ల మధ్య ఓవర్ల్యాప్ లేకపోతే కస్టమర్ సపోర్ట్ టికెట్లు తమ కథన క్రమాన్ని కోల్పోతాయి. దీని ఫలితం ఊహించదగినదే: పెరిగిన లాటెన్సీ (latency), బలహీనమైన రీకాల్ (recall), మరియు జనరేటర్ హాలూసినేట్ (hallucinate) చేసేలా చేసే సమాధానాలు.
మేము మా రిట్రీవల్ లేయర్ను పూర్తిగా మార్చి కొత్తగా నిర్మించాము. దీని ఫలితంగా రీకాల్ 78 శాతం నుండి 95 శాతానికి పెరిగింది, లాటెన్సీ 62 శాతం తగ్గింది మరియు మా పైప్లైన్ ఒక వీకెండ్ హ్యాక్ లాగా కాకుండా నిజమైన ఇన్ఫ్రాస్ట్రక్చర్లా పనిచేయడం ప్రారంభించింది. మేము వాడిన పద్ధతులు ఇక్కడ ఉన్నాయి.
స్మార్ట్ చంకింగ్: టోకెన్ల కంటే నిర్మాణానికి ప్రాధాన్యత
ప్రతి పత్రం ఒకే విధమైన భాషలో ఉంటుందని అనుకోవడమే మొదటి తప్పు. 512-టోకెన్ చంక్ అనేది కథన రూపంలో ఉన్న వచనం (narrative prose) కోసం మాత్రమే ఉపయోగపడుతుంది, మరెక్కడా కాదు. మేము మూల పత్రం యొక్క నిర్మాణాన్ని గౌరవించే వ్యూహానికి మారాము.
లీగల్ డాక్యుమెంట్ల కోసం, మేము రికర్సివ్ చంకింగ్ను (recursive chunking) ఉపయోగిస్తాము. ఈ అల్గారిథమ్ మొదట సెక్షన్లు మరియు ఆర్టికల్స్ వంటి ఉన్నత స్థాయి సరిహద్దుల ఆధారంగా విభజించడానికి ప్రయత్నిస్తుంది. ఒక సెక్షన్ ఇంకా చాలా పొడవుగా ఉంటే, అది సబ్-సెక్షన్ల కోసం, ఆపై పారాగ్రాఫ్ల కోసం, ఆపై వాక్యాల కోసం వెతుకుతుంది. ఇది క్లాజుల యొక్క లాజికల్ నెస్టెడ్ను కాపాడుతుంది. దీనివల్ల నాన్-కాంపిటీ అగ్రిమెంట్ (non-compete agreement) విడిపోకుండా ఉంటుంది. డెఫినిషన్లు ఇండెమ్నిటీ టర్మ్స్లోకి కలవవు.
API డాక్యుమెంటేషన్కు స్ట్రక్చర్-అవేర్ చంకింగ్ అవసరం. ఒక ఫంక్షన్ సిగ్నేచర్, దాని పారామీటర్ టేబుల్ మరియు దాని ఎగ్జాంపుల్ రిక్వెస్ట్ అన్నీ కలిసి ఉండాలి. నిర్ణీత టోకెన్ల సంఖ్య తర్వాత విభజించడం వల్ల తరచుగా పారామీటర్లు ఒక చంక్లో, ఉదాహరణలు మరొక చంక్లో ఉండిపోతాయి. దానికి బదులుగా మేము డాక్యుమెంట్ ఆబ్జెక్ట్ ఆధారంగా చంకింగ్ చేస్తాము. ఒక చంక్ ఒక పూర్తి ఎండ్పాయింట్ను లేదా ఒకే ఫంక్షన్ను కలిగి ఉంటుంది. అప్పుడు రిట్రీవర్ ప్రశ్నకు ఖచ్చితంగా సమాధానం ఇచ్చేలా ఒక స్వయం సమగ్రమైన (self-contained) రిఫరెన్స్ను తిరిగి ఇవ్వగలదు.
సపోర్ట్ టికెట్లు సహజంగా సెమాంటిక్ చంకింగ్కు (semantic chunking) సరిపోతాయి. టోకెన్ బౌండరీ వద్ద కత్తిరించడానికి బదులుగా, టాపిక్ ఎక్కడ మారుతుందో మేము గుర్తిస్తాము. లాగిన్ ఫిర్యాదుతో మొదలై బిల్లింగ్ ప్రశ్నకు మారుతున్న టికెట్ రెండు స్పష్టమైన భాగాలుగా విడిపోతుంది. ప్రతి భాగం దానికి అవసరమైన మెటాడేటాను కలిగి ఉంటుంది, దీనివల్ల యూజర్ నిజంగా ఏ సమస్య గురించి ఆందోళన చెందుతున్నారో మోడల్ ఊహించాల్సిన అవసరం ఉండదు.
ఇంటర్నల్ వికీలు మరింత గందరగోళంగా ఉంటాయి. అవి వచనం, పట్టికలు, డయాగ్రామ్లు మరియు ఎంబెడెడ్ థ్రెడ్లను కలిగి ఉంటాయి. వీటి కోసం, మేము ఏజెంటిక్ చంకింగ్ను (agentic chunking) ఉపయోగిస్తాము. ఒక చిన్న లాంగ్వేజ్ మోడల్ ముందుగా చదివి, ఒక థీమాటిక్గా పూర్తి యూనిట్ ఎక్కడ ముగుస్తుందో నిర్ణయిస్తుంది. ఇది డేటా ఇంజెషన్ సమయంలో కొంచెం ఎక్కువ ఖర్చుతో కూడుకున్నది, కానీ ప్రతి కొత్త పేజీ ఫార్మాట్ కోసం రూల్స్ను మాన్యువల్గా సెట్ చేయాల్సిన శ్రమను ఇది తగ్గిస్తుంది.
హైబ్రిడ్ రిట్రీవల్: అన్ని కోణాలను కవర్ చేయండి
అస్పష్టమైన అర్థాలను (fuzzy meaning) పట్టుకోవడంలో వెక్టర్ సెర్చ్ అద్భుతంగా పనిచేస్తుంది. స్లో అప్లోడ్ల గురించి అడిగితే, అది లాటెన్సీ మరియు బ్యాండ్విడ్త్ గురించి పేరాగ్రాఫ్లను సంతోషంగా తిరిగి ఇస్తుంది. కానీ ఖచ్చితమైన మ్యాచ్లను (exact matches) తప్పుగా చూపడంలో ఇది ప్రసిద్ధి చెందింది. ఒక డెవలపర్ ERR_CONNECTION_REFUSED అనే ఎర్రర్ కోడ్ కోసం వెతికితే, డెన్స్ ఎంబెడ్డింగ్లు దానిని తరచుగా సాధారణ నాయిస్గా పరిగణిస్తాయి.
క్లాసిక్ కీవర్డ్ అల్గారిథమ్ అయిన BM25 దీనికి విరుద్ధంగా పనిచేస్తుంది. ఇది ఖచ్చితమైన స్ట్రింగ్లు మరియు అరుదైన పదాలను పట్టుకుంటుంది, కానీ సెమాంటిక్ సూక్ష్మతలను (semantic nuance) కోల్పోతుంది. అగ్రిమెంట్పై సంతకం చేయడం గురించి అడిగే క్వెరీ, 'executing the contract' అని ట్యాగ్ చేయబడిన కంటెంట్ను ఎప్పటికీ వెలికితీయకపోవచ్చు.