提升企业 RAG 准确性：利用 Gemini Flash 2.0 的创新方法与实用技巧

RAG：超越基础

RAG（Retrieval-Augmented Generation，检索增强生成）的典型方法相当粗略——将大量非结构化文档分割成 1000 个 token 的块，为了保险起见，加入一些块重叠，将所有内容嵌入到向量中，然后就大功告成了。这种蛮力方法既不准确也不完整。

那么，我们如何解决这个问题呢？这个问题一直困扰着我。经过一番阅读、摆弄不同的代码库和实验之后，我认为我终于找到了一种更好的方法，可以支持。

首先，为了达成共识，让我们尝试理解一下朴素的 RAG 是如何工作的。假设你有一个 pdf 文档。你选择一个任意的块大小，比如 512，然后你开始将整个文档分割成这些块大小，并添加一些重叠。然后，你将这些块转换为嵌入或向量，现在你就可以进行语义搜索了。当然，我简化了这一点，因为有不同类型的分块策略，但你明白了我的意思。但是，如果我们在文档中首先通过主题或实体发现相似的块，然后创建嵌入，我想（并在某处读到过）？

最大的问题是，如果你的文档很大，例如你有 10 万个文档，那么用 LLM 来做这件事的成本很高。直到 Google 推出了 Gemini Flash 2.0，它的成本要低得多，而且比之前的一些模型更好。

所以我不得不尝试一下，但我也必须将其与我读过的另一种策略——知识增强生成（KAG）结合起来。

但是，这里有一个挑战——我想使用一个数据库。不是向量 + 图，也不是带有图和多个扩展的 Postgres，而只是一个数据库。最好是一个可以执行 SQL、JSON、向量和基本图的数据库。

所以我选择了 SingleStore 作为数据库，Python (Fast API) 作为后端，NextJS 作为前端。从高层次来看，这是我的计划。

1.放弃任意分块。相反，通过 LLM 运行文档以识别语义上连贯的部分。我选择了 Gemini Flash 的低延迟、经济实惠的 API。

2.提取结构化知识。除了检索文本之外，使用 Gemini 从文档中提取关键实体及其关系。将此结构化数据存储为关系格式（SingleStore 用于快速查找）。

3.使用混合检索。除了仅依赖向量搜索之外，将语义分块检索与知识图查找相结合。对结果进行逻辑排序，然后将最佳上下文交给 LLM。 tl;dr — 当我这样做时，准确性如何？ 这么说吧，我感到很惊喜。

在本文中，我将逐步介绍整个方法。你也可以从代码库中获取我的代码，并在你自己的数据集上进行测试。

首先，让我们看一下数据库的简单模式——一个 documents 表来保存文档的记录，Documents_Embeddings 表，用于存储语义块和相应的向量，一个 entities 表和一个关系表。

以下是使用向量和关键词匹配索引创建它的 SQL：

CREATE TABLE Document_Embeddings (

  embedding_id BIGINTPRIMARY KEY AUTO_INCREMENT,

  doc_id BIGINTNOTNULL,

  content TEXT,

  embedding VECTOR(1536),

  SORT KEY(),

  FULLTEXT USING VERSION 2 content_ft_idx (content), -- Full-Text index (v2) on content

  VECTOR INDEX embedding_vec_idx (embedding), -- Vector index on embedding column

  INDEX_OPTIONS '{ "index_type": "HNSW_FLAT", "metric_type": "DOT_PRODUCT" }'

);

ALTERTABLE Entities

ADD FULLTEXT USING VERSION 2 ft_idx_name (name);

CREATETABLE Documents (

  doc_id BIGINTPRIMARY KEY AUTO_INCREMENT,

  title VARCHAR(255),

  author VARCHAR(100),

  publish_date DATE,

  source JSON --Other metadata fields (e.g. summary, URL) can be added as needed

);

CREATETABLE Relationships (

  relationship_id BIGINTPRIMARY KEY AUTO_INCREMENT,

  source_entity_id BIGINTNOTNULL,

  target_entity_id BIGINTNOTNULL,

  relation_type VARCHAR(100),

  doc_id BIGINT, - reference to Documents.doc_id (not an enforced foreign key)

  KEY (source_entity_id) USING HASH, -- index for quickly finding relationships by source

  KEY (target_entity_id) USING HASH, --index for quickly finding relationships by target

  KEY (doc_id) --index for querying relationships by document

);

CREATETABLE Entities (

  entity_id BIGINTNOTNULL AUTO_INCREMENT,

  name VARCHAR(255) NOTNULL,

  description TEXT,

  aliases JSON,

  category VARCHAR(100),

  PRIMARY KEY (entity_id, name), --Composite primary key including shard key columns

  SHARD KEY (entity_id, name), --Enforce local uniqueness on shard key

  FULLTEXT USING VERSION 2 name_ft_idx (name) --Full-text index for name search

);

现在我们已经设置了表格，使用 pdf 作为文档源来填充这些表格并不复杂或有趣。我为每个步骤都有不同的方法 -

获取语义块并创建嵌入，插入到 Documents 和 Document_Embeddings 中，提取实体和关系，并填充 Entities 和 Relationships 表。

现在，让我们看一下检索策略，因为现在可以用几种不同的方式来完成，无论你是想获得更高的准确性还是速度。我选择了下面的策略。

让我们通过一个简单的例子来了解这个策略。假设我们想对一个简单的术语进行搜索——“hello world”：

步骤 1 — 使用与我们用于为文档创建嵌入相同的模型将查询转换为嵌入，并对 Documents_Embeddings 表执行混合搜索。

-- Simplified query combining vector and text search

SELECT chunk_text,

     dot_product(chunk_embedding, query_embedding) as vector_score,

     MATCH(chunk_text) AGAINST('hello world') as text_score

FROM Document_Embeddings

ORDER BY (0.7 * vector_score + 0.3 * text_score) DESC

LIMIT 5;

步骤 2 — 我们现在查看结果并运行我们的查询，以找到来自前几步的重新排序结果的实体

提取潜在实体：

“Hello World” (编程概念)

"Brian Kernighan" (人)

"C Programming Language" (编程语言)

"Java" (编程语言)

"Python" (编程语言)

接下来，我们得到关系，例如

"Brian Kernighan" -> "created" -> "Hello World"

"C Programming Language" -> "introduced" -> "Hello World"

"Brian Kernighan" -> "authored" -> "C Programming Language"

步骤 3 — 我们现在将结果合并并丰富，作为 LLM 的最终上下文组装，使用以下子步骤

1. 按相关性分数对块进行排序

2. 使用实体信息进行丰富

3. 添加关系上下文

4. 为 LLM 提示设置格式

我们的例子现在看起来像下面这样，然后我们将其传递给 LLM 以获得响应

context = f”””

Relevant Information:

{top_chunks_with_scores}

Key Entities:

- Hello World (编程概念)

- Brian Kernighan (人，创建者)

Important Relationships:

- Brian Kernighan created Hello WorldHello World

• Hello World 最初于 1972 年在 C 编程语言中引入

以下是更详细的流程图，更适合视觉导向的人群

结论

自两年前 RAG 推出以来，它已经取得了长足的进步，但在我看来，随着更新、更快、更便宜、更好的推理模型的出现，我们现在已经取得了巨大的飞跃。是的，上下文大小也增加了，所以在某些情况下，直接将整个文档发送给模型可能会更容易，但在我看来，这仍然无法取代浏览分布在数十万个非结构化和结构化数据中的特定领域知识。为此，我们仍然需要某种检索增强。

如果您正在构建企业 AI 应用程序，希望这能为您提供一个起点，让您做一些更适合企业的事情，而不是简单的仅解析文档和信息合成。