பெரும்பாலான குழுக்கள் இப்போதும் தங்கள் முதல் retrieval pipeline-ஐ ஒரே மாதிரியாகவே உருவாக்குகின்றன. அவர்கள் ஒரு குறிப்பிட்ட token limit-ஐ (ஒருவேளை 512 இருக்கலாம்) தேர்வு செய்து, ஆவணங்களைச் சீரான தொகுதிகளாகப் (blocks) பிரித்து, அவற்றை ஒரு vector database-இல் செலுத்துகிறார்கள். சிறிய தரவுத்தொகுப்பு மற்றும் எளிமையான கேள்விகள் இருக்கும்போது, இது அற்புதமாகத் தோன்றும். ஆனால், production சூழலில் இது தோல்வியடைகிறது.
ஒரு சட்ட ஒப்பந்தத்தில் (Legal contract) ஒரு விதி (clause) வாக்கியத்தின் நடுப்பகுதியில் துண்டிக்கப்படும்போது, அது அர்த்தமற்ற துண்டுகளாகச் சிதறுகிறது. ஒரு chunk மூன்று தொடர்பில்லாத functions-களைத் தன்னுள் அடக்கினால், API documentation குழப்பமான ஒன்றாக மாறிவிடும். வாடிக்கையாளர் சேவைத் டிக்கெட்டுகளில் (Customer support tickets) பகுதிகளுக்கு இடையே overlap இல்லையென்றால், அவற்றின் தொடர்ச்சியான கருத்துத் தொடர்பு (narrative thread) இழக்கப்படும். இதன் விளைவு கணிக்கக்கூடியதுதான்: அதிகப்படியான latency, பலவீனமான recall மற்றும் generator-ஐத் தவறான தகவல்களைக் கூறத் (hallucinate) தூண்டும் பதில்கள்.
நாங்கள் எங்கள் retrieval layer-ஐ முழுமையாகத் தகர்த்து மீண்டும் உருவாக்கினோம். இதன் விளைவாக, recall 78 சதவீதத்திலிருந்து 95 சதவீதமாக உயர்ந்தது, latency 62 சதவீதம் குறைந்தது, மேலும் எங்களது pipeline ஒரு தற்காலிகத் தீர்வாக (weekend hack) இல்லாமல், உண்மையான உள்கட்டமைப்பைப் (infrastructure) போலச் செயல்படத் தொடங்கியது. உண்மையில் எது வேலை செய்தது என்பது இதோ.
Smart Chunking: Tokens-ஐ விடக் கட்டமைப்பிற்கு முன்னுரிமை
ஒவ்வொரு ஆவணமும் ஒரே மாதிரியான மொழியில் பேசுகிறது என்று நினைப்பதே முதல் தவறு. 512-token chunk என்பது கதை போன்ற உரைநடைகளுக்கு (narrative prose) மட்டுமே பொருந்தும், வேறு எதற்கும் பொருந்தாது. எனவே, மூல ஆவணத்தின் கட்டமைப்பைப் (anatomy) போற்றும் ஒரு உத்தியை நாங்கள் பின்பற்றினோம்.
சட்ட ஆவணங்களுக்கு (Legal documents), நாங்கள் recursive chunking முறையைப் பயன்படுத்துகிறோம். இந்த algorithm முதலில் பிரிவுகள் (sections) மற்றும் கட்டுரைகள் (articles) போன்ற உயர்நிலை எல்லைகளைக் கொண்டு பிரிக்க முயல்கிறது. ஒரு பிரிவு இன்னும் நீளமாக இருந்தால், அது துணைப் பிரிவுகள் (subsections), பின்னர் பத்திகள் (paragraphs), பிறகு வாக்கியங்களைத் (sentences) தேடுகிறது. இது விதிகளின் (clauses) தர்க்கரீதியான வரிசையைப் பாதுகாக்கிறது. ஒரு non-compete agreement சிதையாமல் அப்படியே இருக்கும். வரையறைகள் (Definitions), இழப்பீடு தொடர்பான விதிமுறைகளுடன் (indemnity terms) கலக்காது.
API documentation-க்கு கட்டமைப்பை உணர்ந்த (structure-aware) chunking தேவைப்படுகிறது. ஒரு function signature, அதன் parameter table மற்றும் அதன் example request ஆகியவை ஒன்றாகவே இருக்க வேண்டும். ஒரு குறிப்பிட்ட token எண்ணிக்கைக்குப் பிறகு பிரிக்கும்போது, பெரும்பாலும் parameters ஒரு chunk-இலும், examples வேறொரு chunk-இலும் அமைந்துவிடும். அதற்குப் பதிலாக, நாங்கள் document object-ஐ அடிப்படையாகக் கொண்டு chunk செய்கிறோம். ஒரு chunk ஒரு முழுமையான endpoint அல்லது ஒரு தனி function-ஐக் கொண்டிருக்கும். இதன் மூலம், retriever உண்மையான கேள்விக்குப் பதிலளிக்கும் வகையில் ஒரு முழுமையான குறிப்பைத் (self-contained reference) திருப்பித் தரும்.
Support tickets-களுக்கு semantic chunking இயல்பாகவே பொருத்தமானது. ஒரு token எல்லையில் துண்டாக்குவதற்குப் பதிலாக, தலைப்பு எங்கு மாறுகிறது என்பதைக் கண்டறிகிறோம். ஒரு login புகார் என்று தொடங்கி, பிறகு billing கேள்விக்கு மாறும் ஒரு ticket, இரண்டு தெளிவான பகுதிகளாகப் பிரிக்கப்படும். ஒவ்வொரு பகுதியும் அதற்குத் தேவையான metadata-வை எடுத்துச் செல்லும், இதனால் பயனர் உண்மையில் எந்தப் பிரச்சனையைக் கவலைப்படுகிறார் என்பதை மாடல் இனி யூகிக்க வேண்டிய அவசியமில்லை.
நிறுவனத்தின் உள் விக்கி பக்கங்கள் (Internal wikis) மிகவும் குழப்பமானவை. அவை உரைநடை, அட்டவணைகள், வரைபடங்கள் மற்றும் இணைக்கப்பட்ட விவாதத் தொடர்களைக் (embedded threads) கொண்டுள்ளன. இவற்றுக்கு, நாங்கள் agentic chunking முறையைப் பயன்படுத்துகிறோம். ஒரு சிறிய மொழி மாதிரி (small language model) முன்னதாகவே படித்து, ஒரு கருப்பொருள் சார்ந்த முழுமையான அலகு (thematically complete unit) எங்கு முடிகிறது என்பதைத் தீர்மானிக்கிறது. இது தரவுகளை உள்ளிடும்போது (ingestion time) சற்று கூடுதல் செலவை ஏற்படுத்தினாலும், ஒவ்வொரு புதிய பக்க வடிவத்திற்கும் விதிகளைத் தனித்தனியாகத் திருத்தும் (hand-tuning) மனித உழைப்பைக் குறைக்கிறது.
Hybrid Retrieval: அனைத்துத் தேவைகளையும் பூர்த்தி செய்தல்
தெளிவற்ற பொருள்களைக் (fuzzy meaning) கண்டறிவதில் vector search சிறந்தது. 'slow uploads' பற்றி கேட்டால், அது latency மற்றும் bandwidth பற்றிய பத்திகளைத் தந்துவிடும். ஆனால், துல்லியமான பொருத்தங்களை (exact matches) தவறாகக் கையாளுவதில் இது பெயர் பெற்றது. ஒரு developer ERR_CONNECTION_REFUSED என்ற error code-ஐத் தேடினால், dense embeddings பெரும்பாலும் அதை ஒரு பொதுவான இரைச்சலாகவே (generic noise) கருதும்.
பாரம்பரிய keyword algorithm ஆன BM25, இதற்கு நேர்மாறாகச் செயல்படுகிறது. இது துல்லியமான சொற்களையும் (precise strings) அரிதான வார்த்தைகளையும் சரியாகக் கண்டறியும், ஆனால் கருப்பொருள் நுணுக்கங்களை (semantic nuance) விட்டுவிடும். ஒரு ஒப்பந்தத்தில் கையெழுத்திடுவது (signing the agreement) பற்றிய தேடல், 'executing the contract' என்று குறிக்கப்பட்ட உள்ளடக்கத்தைக் கண்டறியத் தவறிவிடலாம்.