<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Enterprise Search on lgovea</title>
    <link>https://lgovea.com/tags/enterprise-search/</link>
    <description>Recent content in Enterprise Search on lgovea</description>
    <generator>Hugo</generator>
    <language>en</language>
    <copyright>2026 lgovea</copyright>
    <lastBuildDate>Tue, 08 Sep 2026 20:37:49 -0600</lastBuildDate>
    <atom:link href="https://lgovea.com/tags/enterprise-search/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Document Quality Is the Real Bottleneck in Enterprise Rag</title>
      <link>https://lgovea.com/posts/document-quality-is-the-real-bottleneck-in-enterprise-rag/</link>
      <pubDate>Tue, 08 Sep 2026 20:37:49 -0600</pubDate>
      <guid>https://lgovea.com/posts/document-quality-is-the-real-bottleneck-in-enterprise-rag/</guid>
      <description>&lt;p&gt;I’ve witnessed again and again companies trying to implement a RAG solution only to fail in the process. Most of these projects don’t fail because the technology is immature. They fail because the documents fed into them are contradictory, outdated, or simply shouldn’t be there.&lt;/p&gt;
&lt;p&gt;The oversimplified flow of a RAG (Retrieval-Augmented Generation) solution looks like this: a user asks a question, the system retrieves relevant passages from a vector database, and those passages plus the question are sent to an LLM to formulate an answer. Why such initiatives most often fail is quite obvious to the external eye but not so obvious to the people leading them from within.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
