చాలా RAG ప్రోటోటైప్లు లోపల చూడటానికి ఒకేలా ఉంటాయి. ఎవరైనా ఒక PDFని పైప్లైన్లోకి పంపి, టెక్స్ట్ను 512-టోకెన్ల ముక్కలుగా (chunks) చేసి, వాటిని వెక్టర్ డేటాబేస్లో వేసి, పని పూర్తయిందని అనుకుంటారు. ఒక డెమో కోసం ఇది అద్భుతంగా అనిపించవచ్చు, కానీ ప్రొడక్షన్లో ఇది విఫలమవుతుంది.
ఒక ఫిక్స్డ్ చంక్ (fixed chunk) దేనిని కత్తిరిస్తుందో పట్టించుకోదు. అది ఒక లీగల్ కాంట్రాక్ట్ను ఇండెమ్నిటీ క్లాజ్ (indemnity clause) మధ్యలోనే విడగొట్టవచ్చు. ఐదు సంబంధం లేని API ఎండ్పాయింట్లను ఒకే కాంటెక్స్ట్ విండోలోకి నెట్టేసి, మోడల్ను అనవసరమైన సమాచారంతో (noise) ముంచేస్తుంది. ఇది అవసరమైన దానికంటే ఎక్కువ ఫ్రాగ్మెంట్లను రిట్రీవ్ చేసేలా చేస్తుంది, దీనివల్ల లేటెన్సీ (latency) పెరిగి, టోకెన్లు వృథా అవుతాయి. దీని ఫలితం సగం సమాధానాలు, హాలూసినేషన్లు (hallucinations) మరియు అసంతృప్తి చెందిన వినియోగదారులు.
మేము మా రిట్రీవల్ లేయర్ను పూర్తిగా మార్చి కొత్తగా నిర్మించాము. దీని ఫలితంగా 95 శాతం రీకాల్ (recall) సాధించడమే కాకుండా, లేటెన్సీని 40 శాతం తగ్గించగలిగాము. మేము దీన్ని ఎలా చేశామో ఇక్కడ వివరంగా ఉంది.
ప్రొడక్షన్లో ఫిక్స్డ్ చంక్స్ ఎందుకు విఫలమవుతాయి
512-టోకెన్ల డీఫాల్ట్ అనేది ఒక డిజైన్ ఎంపిక కాదు. ఇది ప్రారంభ దశలోని ఎంబెడ్డింగ్ మోడల్ కాంటెక్స్ట్ విండోలు మరియు లైబ్రరీ డీఫాల్ట్ల వల్ల వచ్చిన ఫలితం మాత్రమే. దీన్ని అమలు చేయడం సులభం, కానీ దీనిపై ఆధారపడటం వినాశకరమైనది.
డాక్యుమెంట్లు ఒకేలా ఉండవు. ఒక లీగల్ క్లాజ్ ఎటువంటి విరామం లేకుండా ఏడు వందల టోకెన్ల వరకు ఉండవచ్చు. దాన్ని ఐదు వందల పన్నెండు వద్ద విడగొడితే, రెండు విడిపోయిన ఫ్రాగ్మెంట్లు ఏర్పడతాయి. ఒక లాయర్ లేదా కంప్లయన్స్ ఆఫీసర్ లయబిలిటీ క్యాప్స్ (liability caps) గురించి అడిగినప్పుడు, సిస్టమ్ సగం బాధ్యతను మాత్రమే తిరిగి ఇస్తుంది. లాంగ్వేజ్ మోడల్ ఆ మిగిలిన సగ భాగాన్ని ఊహించి (hallucinate) తప్పు సమాచారాన్ని ఇస్తుంది, లేదా ఇంకా దారుణంగా, ఆ క్యాప్ ఉనికిలోనే లేదని చెబుతుంది.
API డాక్యుమెంటేషన్ దీనికి విరుద్ధమైన సమస్యను ఎదుర్కొంటుంది. ఐదు వందల టోకెన్ల చంక్ ఒక పూర్తి మాడ్యూల్ను: authentication headers, error codes, rate limits, మరియు webhook schemas లను మింగేయవచ్చు. ఒక డెవలపర్ AUTH_4027ని ఎలా హ్యాండిల్ చేయాలో అడిగినప్పుడు, రిట్రీవర్ సంబంధం లేని ఫంక్షన్ల మిశ్రమాన్ని చూపిస్తుంది. మోడల్కు వాటిని ఒక సాధారణ సమాచారంగా మార్చడం తప్ప వేరే దారి ఉండదు.
తప్పుడు చంకింగ్ లేటెన్సీని కూడా పెంచుతుంది. బలహీనమైన ఫ్రాగ్మెంట్ల వల్ల ఒక టాపిక్ను కవర్ చేయడానికి మీరు పెద్ద top-k అవసరమవుతుంది. ఎక్కువ చంక్స్ అంటే పొడవైన ప్రాంప్ట్లు (prompts). పొడవైన ప్రాంప్ట్లు అంటే నెమ్మదైన జనరేషన్ మరియు ఎక్కువ బిల్లులు. వినియోగదారు అనుభవం (user experience) క్రమంగా దెబ్బతింటుంది.
చంక్ను డాక్యుమెంట్కు అనుగుణంగా మార్చండి
మేము టోకెన్లను లెక్కించడం ఆపివేసి, సమాచారాన్ని చదవడం ప్రారంభించాము. సరైన చంకింగ్ వ్యూహం అనేది మూల డాక్యుమెంట్ (source) యొక్క నిర్మాణాన్ని బట్టి ఉంటుంది.
లీగల్ డాక్యుమెంట్లు (Legal documents) క్లాజ్-అవేర్ బౌండరీలతో కూడిన రికర్సివ్ క్యారెక్టర్ చంకింగ్ను (recursive character chunking) కోరుకుంటాయి. ఈ స్ప్లిటర్ క్రమానుగత శ్రేణిని (hierarchy) గౌరవిస్తుంది: ఇది మొదట సెక్షన్ హెడర్ల కోసం, తర్వాత నంబర్ చేయబడిన పేరాగ్రాఫ్ల కోసం, ఆపై సహజమైన వాక్య విరామాల కోసం వెతుకుతుంది. ఇది ఎప్పుడూ సబ్-క్లాజ్ను విడగొట్టదు లేదా ఒక బాధ్యతాయుతమైన వాక్యాన్ని చంక్స్ మధ్యలో ముక్కలు చేయదు. మీరు ఇండెమ్నిఫికేషన్ (indemnification) గురించి ఏదైనా చదివినప్పుడు, మీకు పూర్తి క్లాజ్, క్యాప్ మరియు మినహాయింపులు లభిస్తాయి.
API డాక్యుమెంటేషన్ (API documentation) స్ట్రక్చర్-అవేర్ చంకింగ్ను కోరుకుంటుంది. మేము టోకెన్ బడ్జెట్ ఆధారంగా కాకుండా, ఫంక్షన్ డెఫినిషన్ (function definition) ద్వారా విడగొడతాము. ప్రతి చంక్లో పూర్తి ఫంక్షన్ సిగ్నేచర్ (function signature), దాని పారామీటర్ వివరణలు మరియు దానికి వెంటనే ఉన్న ఎర్రర్ హ్యాండ్లింగ్ నోట్స్ ఉంటాయి. ఒక డెవలపర్ ఒక నిర్దిష్ట మెథడ్ కోసం వెతికినప్పుడు, వారికి ఒక అసంబద్ధమైన ముక్క కాకుండా, పూర్తి కాంట్రాక్ట్ లభిస్తుంది.
సపోర్ట్ టికెట్లు (Support tickets) గందరగోళంగా మరియు నాన్-లీనియర్గా ఉంటాయి. ఒక థ్రెడ్ బగ్ రిపోర్ట్తో మొదలై, ఒక వర్క్అరౌండ్ (workaround) పరిచయం చేసి, అంతర్గత ఎస్కలేషన్ నోట్తో ముగియవచ్చు. సెమాంటిక్ చంకింగ్ (Semantic chunking) వాక్యాల మధ్య ఎంబెడ్డింగ్ సిమిలారిటీని కొలవడం ద్వారా టాపిక్ మార్పులను గుర్తిస్తుంది. మేము కేవలం సహజమైన థీమాటిక్ బౌండరీల వద్ద మాత్రమే విరామాలను అనుమతిస్తాము, తద్వారా లాగిన్ ఫెయిల్యూర్ల గురించి జరిగే సంభాషణ, బిల్లింగ్ సైకిల్స్ గురించి జరిగే సంభాషణతో కలవదు.
వికీలు (Wikis) అత్యంత కష్టమైనవి. అవి విస్తారంగా, క్రాస్-లింక్ చేయబడి మరియు క్రమబద్ధీకరించబడకుండా ఉంటాయి. మేము ఏజెంటిక్ చంకింగ్ను (agentic chunking) ఉపయోగించాము, ఇక్కడ ఒక తేలికపాటి LLM పేజీని చదివి, థీమాటిక్ కోహెరెన్స్ (thematic coherence) ఆధారంగా విరామాలను నిర్ణయిస్తుంది. ఇది డేటా ఇంజెషన్ సమయంలో కొంచెం ఎక్కువ ఖర్చుతో కూడుకున్నది, కానీ ఫలితంగా వచ్చే చంక్స్ స్వయం సమగ్రంగా మరియు రిట్రీవల్ కోసం సిద్ధంగా ఉంటాయి. డిప్లాయ్మెంట్ బెస్ట్ ప్రాక్టీసెస్ (deployment best practices) గురించి ఒక పేజీ, అసంబద్ధమైన టెక్స్ట్ బ్లాక్లుగా కాకుండా లాజికల్ యూనిట్లుగా విడిపోతుంది: అంటే ప్రీ-ఫ్లైట్ చెక్స్, రోల్బ్యాక్ ప్రొసీజర్స్ మరియు మానిటరింగ్ సెటప్ వంటివి.
హైబ్రిడ్ రిట్రీవల్: కీవర్డ్స్ మరియు వెక్టర్స్ కలిపి
డెన్స్ వెక్టర్ సెర్చ్ (Dense vector search) అర్థాన్ని అర్థం చేసుకుంటుంది. కానీ ఖచ్చితమైన స్ట్రింగ్స్ (exact strings) విషయంలో ఇది సరిగ్గా పనిచేయదు. ఒక వినియోగదారు AUTH_4027 వంటి ఖచ్చితమైన ఎర్రర్ కోడ్ కోసం లేదా "Stark Industries" వంటి కస్టమర్ పేరు కోసం వెతికినప్పుడు, వెక్టర్ ఎంబెడ్డింగ్లు లక్ష్యాన్ని తప్పగొట్టవచ్చు, ఎందుకంటే అవి క్యారెక్టర్-లెవల్ ఖచ్చితత్వం కంటే కాన్సెప్చువల్ ప్రాక్సిమిటీ (conceptual proximity) కోసం ఆప్టిమైజ్ చేయబడతాయి.
BM25 ద్వారా చేసే ప్యూర్ కీవర్డ్ సెర్చ్కు దీనికి విరుద్ధమైన లోపం ఉంది. ఇది AUTH_4027ను ఖచ్చితంగా కనుగొంటుంది, కానీ "authorization failure" మరియు "login denied" మధ్య ఉన్న కాన్సెప్చువల్ సంబంధాన్ని గుర్తించలేదు.
We run both in parallel. BM25 and vector search operate independently over the same corpus. Their result lists are merged using Reciprocal Rank Fusion, which reorders candidates by balancing their positional ranks. You do not need calibrated weights. You simply get the precision of exact match and the intuition of semantic search in a single ranked list.
Then we add a cross-encoder reranker. This is a separate model that scores each passage against the original query, producing a relevance signal far finer than either retriever alone. It adds about 50 milliseconds of latency. It increases recall by 15 percent. If you care about answer quality, that trade is non-negotiable.
Query Expansion: Fix the Search Before It Starts
Bad queries are the dirty secret of every retrieval system. Users do not write like your embedding space. They type "it broke." They paste truncated stack traces. They use internal jargon your index has never seen.
We transform the query before it ever touches the index. First, we expand a single query into three to five diverse search terms. If the original is "payment failed," we also search for "transaction error," "billing declined," and "charge unsuccessful