മിക്ക RAG ട്യൂട്ടോറിയലുകളും നോട്ട്ബുക്കിൽ അവസാനിക്കുന്നു. അവ കുറച്ച് വൃത്തിയുള്ള പിഡിഎഫുകൾ (PDFs) ലോഡ് ചെയ്യുന്നു, ഓരോ ആയിരം അക്ഷരങ്ങൾ വീതം ടെക്സ്റ്റ് വിഭജിക്കുന്നു, ആ കഷണങ്ങൾ ഒരു വെക്റ്റർ ഡാറ്റാബേസിലേക്ക് (vector database) നിറയ്ക്കുന്നു, അതിനെ ഒരു ആർക്കിടെക്ചർ എന്ന് വിളിക്കുന്നു. ഒരു വെള്ളിയാഴ്ച ഉച്ചസമയത്ത് ആ ഡെമോ കൃത്യമായി പ്രവർത്തിക്കും. എന്നാൽ പ്രൊഡക്ഷനിൽ (production), അതേ പൈപ്പ്‌ലൈൻ നിശബ്ദമായി ഒരു ബാധ്യതയായി മാറുന്നു.

ഒരു റിട്രീവൽ സിസ്റ്റത്തിലെ (retrieval system) യഥാർത്ഥ തടസ്സം (bottleneck) അപൂർവ്വമായി മാത്രമേ മോഡലോ പ്രോംപ്റ്റോ ആകുന്നുള്ളൂ. അത് ഇൻജഷൻ (ingestion) ആണ്. ഒരു RAG പൈപ്പ്‌ലൈനിന് നൽകപ്പെട്ട വിവരങ്ങൾ മാത്രമേ വീണ്ടെടുക്കാൻ (retrieve) കഴിയൂ; ആ വിവരങ്ങൾ ബഹളമയമോ (noisy), പഴക്കമുള്ളതോ (stale), അല്ലെങ്കിൽ അപൂർണ്ണമോ ആണെങ്കിൽ, മോഡൽ ആത്മവിശ്വാസത്തോടെ തെറ്റായ വിവരങ്ങൾ (nonsense) നൽകും. ബോട്ട് തെറ്റായ കാര്യങ്ങൾ പറയുന്നതായി (hallucinated) ഉപയോക്താക്കൾ പരാതിപ്പെടുമ്പോൾ, അതിന്റെ കുറ്റം പലപ്പോഴും ആരും സൂക്ഷ്മമായി നിരീക്ഷിക്കാത്ത ഒരു ഡാറ്റാ പൈപ്പ്‌ലൈനിന്റെ മുകൾഭാഗത്തായിരിക്കും (upstream).

വൈറ്റ്ബോർഡ് കെണി

ആർക്കിടെക്ചർ ഡയഗ്രമുകൾ ഇൻജഷനെ “Documents → Vector DB” എന്ന് അടയാളപ്പെടുത്തിയ ഒരു ഒറ്റ അമ്പടയാളമായി കാണിക്കുന്നു. എന്നാൽ യാഥാർത്ഥ്യം ഇതിലും സങ്കീർണ്ണമാണ്. സ്രോതസ്സ് സിസ്റ്റങ്ങൾ (Source systems) അറിയിപ്പില്ലാതെ മാറുന്നു. HTML ലേഔട്ടുകൾ പുനർരൂപകൽപ്പന ചെയ്യപ്പെടുന്നു. URL-കൾ ജനറൽ ലാൻഡിംഗ് പേജുകളിലേക്ക് റീഡയറക്ട് ചെയ്യുന്നു. പ്രാരംഭ HTTP റെസ്‌പോൺസിന് ശേഷം ജാവാസ്ക്രിപ്റ്റ് ഫ്രെയിംവർക്കുകൾ ഉള്ളടക്കം മാറ്റുന്നു. ഇൻജഷനെ ഒരു ഒറ്റത്തവണ സെറ്റപ്പ് ജോലിയായി കാണുന്നത് ആദ്യത്തെ തെറ്റാണ്. ഇത് ഏതൊരു ETL പൈപ്പ്‌ലൈനിനും തുല്യമായ കൃത്യത ആവശ്യമായ, തുടർച്ചയായ ഒരു ഡാറ്റാ എഞ്ചിനീയറിംഗ് പ്രശ്നമാണ്.

എന്തുകൊണ്ടാണ് RAG പരാജയങ്ങൾ സാധാരണയായി ഫീഡ് പരാജയങ്ങളാകുന്നത്

ഇതൊന്ന് സങ്കൽപ്പിക്കുക: നിലവിലെ റീഫണ്ട് പോളിസിയെക്കുറിച്ച് ഒരു ഉപയോക്താവ് നിങ്ങളുടെ ഇന്റേണൽ അസിസ്റ്റന്റിനോട് ചോദിക്കുന്നു. മോഡൽ വെക്റ്റർ സ്റ്റോറിൽ നിന്ന് ഏറ്റവും അനുയോജ്യമായ കഷണം (chunk) എടുക്കുകയും 30 ദിവസത്തെ കാലാവധി പറയുകയും ചെയ്യുന്നു. എന്നാൽ യഥാർത്ഥ പോളിസി കഴിഞ്ഞ പാദത്തിൽ 60 ദിവസമായി മാറിയിരുന്നു. LLM തെറ്റായ ഉത്തരം സ്വയം നിർമ്മിച്ചതല്ല. അത് തെറ്റായ ഇൻപുട്ടിനെ വിശ്വസിച്ചു. റിട്രീവൽ ലെയർ ഒരു പഴയ പേജ് നൽകി, കൂടാതെ എംബെഡിംഗ് (embedding) അർത്ഥപരമായി (semantically) അടുത്തതായി തോന്നിയതിനാൽ, മോഡൽ അതിനെ സത്യമായി കണക്കാക്കി.

ഈ രീതി നിരന്തരം ആവർത്തിച്ചുകൊണ്ടിരിക്കുന്നു. കോർപ്പസ് (corpus) നാവിഗേഷൻ ഫൂട്ടറുകൾ (footers), ഡ്യൂപ്ലിക്കേറ്റ് പ്രസ് റിലീസുകൾ, ടേബിളുകളെ പകുതിയായി വിഭജിക്കുന്ന കഷണങ്ങൾ എന്നിവയാൽ നിറഞ്ഞതാണെങ്കിൽ, ടീമുകൾ ടെമ്പറേച്ചറും (temperature) top-k ഉം ക്രമീകരിക്കുന്നതിനായി മണിക്കൂറുകൾ പാഴാക്കുന്നു. ജനറേഷൻ (generation) ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിന് മുമ്പ്, നിങ്ങളുടെ സിസ്റ്റത്തിന് എന്തൊക്കെ അറിയാൻ അനുവാദമുണ്ടെന്ന് ഓഡിറ്റ് ചെയ്യുക.

ഇൻജഷനെ നശിപ്പിക്കുന്ന ഏഴ് കെണികൾ

1. ആദ്യത്തെ റൺ ഒരു കള്ളമാണ്

നിങ്ങളുടെ ആദ്യത്തെ ക്രോൾ (crawl) സമയത്തെ ഒരു ഗ്രീൻ ചെക്ക്മാർക്ക് കൊണ്ട് കാര്യമായ nothing ലഭിക്കില്ല. പ്രൊഡക്ഷൻ ഡാറ്റ സജീവമാണ്. ഡോക്യുമെന്റേഷൻ പേജുകൾ മാറ്റം വരുത്തപ്പെടുന്നു, ബ്ലോഗ് പെർമാലിങ്കുകൾ തകരുന്നു, സൈറ്റ്മാപ്പുകൾ നിശബ്ദമായി സെക്ഷനുകൾ ഒഴിവാക്കുന്നു. പൈപ്പ്‌ലൈൻ ഒരു എറർ ഇല്ലാതെ പൂർത്തിയായി എന്ന് മാത്രം നിങ്ങൾ പരിശോധിക്കുകയാണെങ്കിൽ, നിങ്ങൾ അന്ധമായി സഞ്ചരിക്കുകയാണ്. നിങ്ങൾ ഔട്ട്‌പുട്ട് പരിശോധിക്കേണ്ടതുണ്ട്. പ്രതീക്ഷിച്ച ഡോക്യുമെന്റുകൾ ഉണ്ടെന്നും, അവയുടെ ഘടന ഇപ്പോഴും ശരിയാണെന്നും, ഒരു സ്രോതസ്സ് റിസൾട്ടുകൾ വ്യത്യസ്തമായി പേജിനേഷൻ (paginate) ചെയ്യാൻ തീരുമാനിച്ചതിനാൽ ടെക്സ്റ്റിന്റെ ആകെ അളവ് കുറഞ്ഞിട്ടില്ലെന്നും ഉറപ്പുവരുത്തുക.

2. ക്രോളിംഗ് എന്നാൽ ഇൻജഷൻ അല്ല

HTML ശേഖരിക്കുക എന്നത് എളുപ്പമുള്ള കാര്യമാണ്. ഒരു റോ ക്രോൾ (raw crawl) എല്ലാം പിടിച്ചെടുക്കുന്നു: കുക്കി ബാനറുകൾ, "Related Articles" സൈഡ്ബാറുകൾ, പരസ്യങ്ങൾ, ഫൂട്ടർ കോപ്പിറൈറ്റ് അറിയിപ്പുകൾ എന്നിവയെല്ലാം ഇതിൽ ഉൾപ്പെടും. നിങ്ങൾ ആ റോ HTML അശ്രദ്ധമായി ചങ്ക് (chunk) ചെയ്യുകയാണെങ്കിൽ, ഓരോ ടെക്സ്റ്റ് കഷണത്തോടൊപ്പം നാവിഗേഷൻ മെനുവിന്റെ ഭാഗങ്ങളും വരും. ഒരു ഉപയോക്താവ് API റേറ്റ് ലിമിറ്റുകളെക്കുറിച്ച് ചോദിക്കുമ്പോൾ, റിട്രീവർ 40 ശതമാനവും സൈഡ്‌ബാർ ലിങ്കുകളുള്ള ഒരു കഷണം നൽകിയേക്കാം. വൃത്തിയുള്ള എക്സ്ട്രാക്ഷൻ (clean extraction) പ്രധാനമാണ്. നിങ്ങൾ പ്രധാന ഉള്ളടക്കം (main content area) തിരിച്ചറിയുകയും, ബോയ്‌ലർപ്ലേറ്റ് (boilerplate) ഒഴിവാക്കുകയും, എല്ലാ പേജുകളിലും ആവർത്തിക്കുന്ന ഘടകങ്ങൾ നീക്കം ചെയ്യുകയും വേണം. അല്ലാത്തപക്ഷം നിങ്ങൾ ഒരു നോളജ് ബേസ് (knowledge base) നിർമ്മിക്കുകയല്ല, മറിച്ച് വെബ്‌സൈറ്റിലെ അനാവശ്യ ഘടകങ്ങൾക്കായി ഒരു സെർച്ച് എഞ്ചിൻ നിർമ്മിക്കുകയാണ് ചെയ്യുന്നത്.

3. ചങ്കിംഗ് അർത്ഥം നശിപ്പിക്കുന്നു

മിക്ക ക്വിക്ക്സ്റ്റാർട്ട് ഗൈഡുകളിലും ഫിക്സഡ്-സൈസ് ചങ്കിംഗ് (fixed-size chunking) ആണ് ഉപയോഗിക്കുന്നത്, ഇത് അപകടകരമാണ്. അക്ഷരങ്ങളുടെ എണ്ണം മാത്രം നോക്കി ഒരു ഡോക്യുമെന്റ് വിഭജിച്ചാൽ, നിങ്ങൾ ടേബിളുകളെ പകുതിയായി മുറിക്കുകയും, ഘട്ടം 4-ഉം 5-ഉം വേർതിരിക്കുകയും, ബുള്ളറ്റ് പോയിന്റുകളെ അവയുടെ ഹെഡിംഗുകളിൽ നിന്ന് അകറ്റുകയും ചെയ്യും. ഒരു പ്രൈസിംഗ് ടേബിളിന്റെ രണ്ടാം പകുതി മാത്രം അടങ്ങിയ ഒരു ചങ്ക് അർത്ഥശൂന്യമാണ്. സ്ട്രക്ചർ-അവേർ ചങ്കിംഗ് (structure-aware chunking) യഥാർത്ഥ ഫോർമാറ്റിനെ മാനിക്കുന്നു. ഹെഡിംഗ് ഹൈരാർക്കി (heading hierarchy) വിശകലനം ചെയ്യുക. സാധ്യമാകുന്നിടത്തോളം ടേബിളുകൾ മാറ്റമില്ലാതെ നിലനിർത്തുക. ഒരേ H2 അല്ലെങ്കിൽ H3-ന് കീഴിലുള്ള പാരഗ്രാഫ് അതിരുകളിൽ വിഭജിക്കുക. ലിസ്റ്റുകൾ ചെറുതാണെങ്കിൽ അവ ഒരൊറ്റ ചങ്കിനുള്ളിൽ തന്നെ നിലനിർത്തുക. ലക്ഷ്യം ഒരേ വലിപ്പമുള്ള ബ്ലോക്കുകൾ ഉണ്ടാക്കുക എന്നതല്ല, മറിച്ച് അർത്ഥവത്തായ യൂണിറ്റുകൾ ഉണ്ടാക്കുക എന്നതാണ്.

4. വിവരങ്ങളുടെ പുതുമയുമായി ബന്ധപ്പെട്ട പ്രശ്നം (The Freshness Problem)

A static snapshot of an internal wiki is simple mode. Continuously ingesting from the live web is hard. You need to know when a page was last gathered, whether it has changed since then, and how long the information remains valid. Stale data does not always mean a visibly old date. Sometimes a page updates its text but keeps the same URL, so your system never notices without content hashing. Build clear refresh rules based on source volatility. A financial data feed might need hourly checks. A company about page might need quarterly checks. Record timestamps and set time-to-live boundaries, especially if your domain involves regulated or safety-critical guidance where old facts can cause real harm.

5. Duplicate Pollution

Websites are full of repetition. The same product description appears on the category page, the product page, and a promotional landing page. The same press release lives under /news/, /press/, and /blog/. Vector search does not deduplicate automatically. If ten nearly identical chunks sit in your database, they can crowd out diverse, relevant results in your top-k retrieval. You need canonical tracking or content deduplication before embedding. If two chunks say the same thing, keep the authoritative source and drop the copies. Your retriever has limited slots. Do not let them go to waste.

6. Missing Metadata

A vector database without metadata is just a dense text search engine with no memory of context. Smart retrieval depends on filtering and ranking signals that raw embeddings cannot provide. Store the source URL, the capture date, the document category, and the version number. If you ingest API documentation, versioning is essential. Without it, a query might blend v1 and v2 specs into the same answer. If you ingest HR policies, tagging by region or department lets you filter results before they ever reach the model. Metadata turns a text dump into a curated knowledge system.

7. JavaScript Gaps

Modern sites do not ship their content in the first HTML payload. They send a skeleton and hydrate it with JavaScript calls. A basic HTTP request might see nothing but a loading spinner and a layout shell. If your pipeline cannot execute JavaScript, you will ingest blank pages or partial fragments and never realize anything is wrong. Using a headless browser solves the rendering problem but introduces new ones: heavier memory use, slower throughput, and bot detection walls. Choose your trade-offs deliberately, but do not pretend a simple curl equivalent is enough for every source.

A Practical Ingestion Checklist

If you are building or reviewing a RAG feed, start here:

  • Validate source coverage and pagination. A sitemap might list only the first ten articles in a category. Crawl deep and verify that paginated or dynamically loaded content is actually captured.
  • Remove boilerplate before chunking. Strip navigation, ads, footers, and repeated legal disclaimers. If a phrase appears on every page, it is noise.
  • Use structure-aware chunking. Respect headings, bullet lists, and tables. Split on semantic boundaries, not character counts.
  • Attach rich metadata. Include URL, capture date, content category, and version. Make these fields filterable in your retrieval queries.
  • Set refresh frequencies based on data volatility. High-change sources need frequent re-crawls. Static archives do not.
  • Monitor the corpus, not just the job status. A pipeline can exit with code zero while producing garbage. Audit samples of stored chunks regularly for drift and quality.
  • Define rules for versioning and deletions. When a source page is removed, delete its chunks. When it updates, overwrite or version them. Orphaned data is a silent killer.

The Hard Truth About Embeddings

No embedding model, no matter how advanced, can repair a missing document. It cannot guess that a page was updated last week if your feed still holds last year's copy. It cannot infer the context of a table row that got separated from its header by a bad chunk boundary. Embeddings compress meaning, but they do not create meaning where the ingestion layer failed to preserve it.

Retrieval quality starts at the ingestion layer. That layer decides whether your RAG system is a useful tool or just a confident liar with a vector database behind it.

The Real Takeaway

ഇൻജഷൻ ഹെൽത്ത് അളക്കാൻ പൈപ്പ്‌ലൈൻ ഡാഷ്‌ബോർഡുകളെ മാത്രം ആശ്രയിക്കുന്നത് നിർത്തുക. പൈപ്പ്‌ലൈനുകൾ വിജയകരമായി പൂർത്തിയാകുന്നതും ലോഗുകൾ തെറ്റുകളില്ലാത്തതും കൊണ്ട് മാത്രം ഒരു ക്ലീൻ കോർപ്പസ് ലഭിക്കുമെന്ന് ഉറപ്പില്ല. ഡാറ്റാബേസ് തുറന്ന്, ഉപയോക്താക്കൾക്ക് ലഭിക്കുന്ന യഥാർത്ഥ ചങ്കുകൾ നേരിട്ട് വായിച്ചു നോക്കുക. ടെക്സ്റ്റുകളിൽ കോപ്പിറൈറ്റ് നോട്ടീസുകൾ, വിഭജിക്കപ്പെട്ട ടേബിളുകൾ, കാലഹരണപ്പെട്ട പോളിസി പേജുകൾ എന്നിവയാണെങ്കിൽ, നിങ്ങളുടെ പ്രശ്നം LLM അല്ല. ആദ്യം ഫീഡ് ശരിയാക്കുക. ബാക്കിയുള്ളവയെല്ലാം വെറും മാലിന്യത്തിന് മുകളിൽ നടത്തുന്ന ട്യൂണിംഗ് മാത്രമാണ്.