你发现答疑机器人不能很好的回答「张伟是哪个部门的？」。因为公司有好几个张伟, 所以张伟相关的文档数量会很多

1. 初步优化检索效果

正如前言提到的，你需要让大模型拿到正确的"参考书"，才能给出正确的"答案"。因此，你可以尝试增加每次拿到"参考书"的数量（增加召回的文档切片数量），或者将"参考书中的知识点"整理成结构化的表格（文档内容结构化）。你可以先从前者入手：

1.1 让大模型获取到更多参考信息

既然知识库中存在张伟的任职信息，那么你可以通过增加一次性召回的文档切片数量的方式，从而扩大检索范围，提升找到相关信息的概率。在之前的代码里，你只召回了2个文档切片，现在，你可以将召回数量增加至5个，再次观察召回效果是否得到了提升。

1.1.1 调整代码

你可以通过以下设置，让检索引擎召回前5个最相关的文档切片。

index = rag.load_index()
query_engine = index.as_query_engine(
    streaming=True,
    # 一次检索出 5 个文档切片，默认为 2
    similarity_top_k=5
)

可以看到：在调整了召回数量后，你的答疑机器人能够回答「张伟是哪个部门？」了，这是因为召回的文档切片中已经包含了张伟和他的部门信息。

不过，单纯增加召回的切片数量并不是一个好方法。想想看，如果这种方法能解决问题，那么不如召回整个知识库，这样不会遗漏任何的信息……可是这不仅会超出大模型的输入长度限制，过多的无关信息还会降低大模型回答的效率和准确性。

而且，事实上你们公司可能有很多叫张伟的同事，这会导致一个问题：当用户问"张伟是哪个部门的"时，系统无法确定用户想问的是哪一个张伟。如果只是简单地增加召回数量，可能会召回到多个张伟的信息，但系统仍然无法准确判断应该返回哪个张伟的信息。因此，我们还需要用其他方法来进一步改进 RAG 效果。

1.2 给大模型结构更清晰的参考信息

在实际应用中，文档的组织结构对检索效果有着重要影响。想象一下，同样的信息，放在一个结构清晰的表格中和散落在一段普通文字里，哪个更容易查找和理解？显然是前者。

大语言模型也是如此。当把原本在表格中的信息转换成普通文本时，虽然信息本身没有丢失，但结构性却降低了。这就像是把一个整齐的抽屉变成了一堆散乱的物品，虽然东西都在，但查找起来就没那么方便了。

1.2.1 重建索引

Markdown格式是一个很好的选择，因为它：

• 结构清晰，层次分明
• 语法简单，易于阅读和维护
• 特别适合RAG（检索增强生成）场景下的文档组织

为了验证结构化文档的效果，课程准备了一份经过优化的Markdown格式文件。接下来，你将：

1. 把这份Markdown文件添加到docs目录
2. 重新建立索引
3. 测试检索效果的提升

2. 熟悉 RAG 的工作流程

截至目前，你已经完成了一些改进，让答疑机器人的问答准确度更高了。但在实际生产环境中，你可能会遇到的问题远不止于此。之前你已经了解了一些 RAG 的工作流程，在这里你可以回顾一下重要的步骤，方便你发现新的改进点：

RAG（Retrieval Augmented Generation，检索增强生成）是一种结合了信息检索和生成式模型的技术，能够在生成答案时利用外部知识库中的相关信息。它的工作流程可以分为几个关键步骤：解析与切片、向量存储、检索召回、生成答案等。具体的概念你可以回顾"扩展答疑机器人的知识范围"这一节。

接下来，将从 RAG 中的每一个环节入手，尝试优化 RAG 的效果。

3. RAG 应用各个环节与改进策略

3.1 文档准备阶段

在传统的客服系统中，客服人员会根据用户所提问题，积累知识库，并共享给其他客服人员参考。在构建 RAG 应用时，这一过程同样不可缺少。

• 意图空间：我们可以把用户提问背后的需求绘制成点，这些点组成了一个用户意图空间。
• 知识空间：而你沉淀在知识库文档中的知识点，则构成了组成一个知识空间。这里的知识点，可以是一个段落、或者一个章节。

当我们将意图空间和知识空间投影到一起，会发现两个空间存在交集与差异。这些区域分别对应了我们后续的三个优化策略：

1. 重叠区域：
   • 即可以依靠知识库的内容来回答用户问题的部分，这是 RAG 应用效果保障的基础。
   • 对于这部分用户意图，你可以通过优化内容质量、优化工程和算法，不断地提升回答质量。
2. 未被覆盖的意图空间：
   • 因为缺乏知识库内容的支撑，大模型容易输出“幻觉”回答。例如，公司新增了一个"数据分析部"，但知识库中没有相关文档，不论如何改进工程算法，RAG 应用都无法准确回答这一问题。
   • 你需要做的是主动补充缺漏的知识，不断跟进用户意图空间的变化。
3. 未被利用的知识空间：
   • 召回不相关知识点可能会干扰大模型的回答。
   • 因此，需要你优化召回算法避免召回无关内容。此外，你还需要定期查验知识库，剔除无关内容。

在尝试优化工程或算法之前，你应该优先构建一套可以持续收集用户意图的机制。通过系统化采集真实用户需求来完善知识库内容，并邀请对用户意图有深刻理解的领域专家参与效果评估，形成"数据采集-知识更新-专家验证"的闭环优化流程，保障 RAG 应用的效果。

当你准备好这些，就可以进一步优化 RAG 应用的各个环节了。

3.2 文档解析与切片阶段

首先，RAG 应用会解析你的文档内容，然后对文档内容进行切片。

大模型在回答问题时拿到的文档切片如果缺少关键信息，会回答不准确；如果拿到的文档切片非关联信息过多（噪声），也会影响回答质量。即过少或过多的信息，都会影响模型的回答效果。

因此，在对文档进行解析与切片时，需要确保最终的切片信息完整，但不要包含太多干扰信息。

3.2.1 使用多种文档切片方法

在文档切片的过程中，切片方式会影响检索召回的效果。让我们通过具体例子来了解不同切片方法的特点。

3.2.1.1 Token 切片

适合对 Token 数量有严格要求的场景，比如使用上下文长度较小的模型时。

示例文本： “LlamaIndex是一个强大的RAG框架。它提供了多种文档处理方式。用户可以根据需要选择合适的方法。”

使用Token切片(chunk_size=10)后可能的结果：

• 切片1： “LlamaIndex是一个强大的RAG”
• 切片2： “框架。它提供了多种文”
• 切片3： “档处理方式。用户可以”

3.2.1.2 句子切片

这是默认的切片策略，会保持句子的完整性。

同样的文本使用句子切片后：

• 切片1: “LlamaIndex是一个强大的RAG框架。”
• 切片2: “它提供了多种文档处理方式。”
• 切片3: “用户可以根据需求选择合适的方法。”

3.2.1.3 句子窗口切片

每个切片都包含周围的句子作为上下文窗口。

示例文本使用句子窗口切片(window_size=1)后：

• 切片1： “LlamaIndex是一个强大的RAG框架。” 上下文： “它提供了多种文档处理方式。”
• 切片2： “它提供了多种文档处理方式。” 上下文： “LlamaIndex是一个强大的RAG框架。用户可以根据需求选择合适的方法。”
• 切片3： “用户可以根据需求选择合适的方法。” 上下文： “它提供了多种文档处理方式。”

3.2.1.4 语义切片

根据语义相关性自适应地选择切片点。

示例文本： “LlamaIndex是一个强大的RAG框架。它提供了多种文档处理方式。用户可以根据需求选择合适的方法。此外，它还支持向量检索。这种检索方式非常高效。”

语义切片可能的结果：

• 切片1： “LlamaIndex是一个强大的RAG框架。它提供了多种文档处理方式。用户可以根据需求选择合适的方法。”
• 切片2： “此外，它还支持向量检索。这种检索方式非常高效。” （注意这里是按语义相关性分组的）

3.2.1.5 Markdown 切片

专门针对 Markdown 文档优化的切片方法。

示例 Markdown 文本：

# RAG框架
LlamaIndex是一个强大的RAG框架。

## 特点
- 提供多种文档处理方式
- 支持向量检索
- 使用简单方便

### 详细说明
用户可以根据需求选择合适的方法。

Markdown切片会根据标题层级进行智能分割：

• 切片1： “# RAG框架\nLlamaIndex是一个强大的RAG框架。”
• 切片2： “## 特点\n- 提供多种文档处理方式\n- 支持向量检索\n- 使用简单方便”
• 切片3： “### 详细说明\n用户可以根据需求选择合适的方法。”

在实际应用中，选择切片方法时不必过于纠结，你可以这样思考：

• 如果你刚开始接触 RAG，建议先使用默认的句子切片方法，它在大多数场景下都能提供不错的效果
• 当你发现检索结果不够理想时，可以尝试：
  • 处理长文档且需要保持上下文？试试句子窗口切片
  • 文档逻辑性强、内容专业？语义切片可能会有帮助
  • 模型总是报 Token 超限？Token 切片可以帮你精确控制
  • 处理 Markdown 文档？别忘了有专门的 Markdown 切片

没有最好的切片方法，只有最适合你场景的方法。你可以尝试不同的切片方法，观察 Ragas 评估结果，找到最适合你需求的方案。学习的过程就是不断尝试和调整的过程！

3.3 切片向量化与存储阶段

文档切片后，你还需要对其建立索引，以便后续检索。一个常见的方案是使用嵌入（Embedding）模型将切片向量化，并存储到向量数据库中。

在这一阶段，你需要选择合适的 Embedding 模型以及向量数据库，这对于提升检索效果至关重要。

3.3.1 了解 Embedding 与向量化

Embedding 模型可以将文本转换为高维向量，用于表示文本语义，相似的文本会映射到相近的向量上，检索时可以根据问题的向量找到相似度高的文档切片。

平面坐标系中的有向线段是 2 维向量。例如，从原点 (0, 0) 到 A (xa, ya) 的有向线段可以称为向量 A。向量 A 与向量 B 之间的夹角越小，也就意味着其相似度越高。

3.3.2 选择合适的 Embedding 模型

不同的 Embedding 模型对相同的几段文字进行计算时，得到的向量可能会完全不同。通常越新的 Embedding 模型，其表现越好。例如前文中使用的是阿里云百炼上提供的 text-embedding-v2。如果换成更新的版本 text-embedding-v3  你会发现即使不去做前面的优化，检索效果也会有一定的提升。

除了通过相似度对比来评估不同 Embedding 模型的效果，你还可以从实际应用的角度来评测。例如你可以使用 Ragas 评测工具来对比 text-embedding-v2 和 text-embedding-v3 两个模型在 RAG 系统中的实际表现。

3.3.3 选择合适的向量数据库

在构建 RAG 应用时,你有多种向量存储方案可以选择,从简单到复杂依次是：

3.3.3.1 内存向量存储

最简单的方式是使用 LlamaIndex 内置的内存向量存储。只需安装 llama-index 包,无需额外配置,就能快速开发和测试 RAG 应用：

from llama_index.core import VectorStoreIndex
# 创建内存向量索引
index = VectorStoreIndex.from_documents(documents)

优点是快速上手，适合开发测试；缺点是数据无法持久化，且受限于内存大小。

3.3.3.2 本地向量数据库

当数据量增大时,可以使用开源的向量数据库,如 Milvus、Qdrant 等。这些数据库提供了数据持久化和高效检索能力

优点是功能完整、可控性强；缺点是需要自行部署维护。

3.3.3.3 云服务向量存储

对于生产环境,推荐使用云服务提供的向量存储能力

3.4 检索召回阶段

检索阶段会遇到的主要问题就是，很难从众多文档切片中，找出和用户问题最相关、且包含正确答案信息的片段。

从切入时机来看，可以将解法分为两大类：

1. 在执行检索前，很多用户问题描述是不完整、甚至有歧义的，你需要想办法还原用户真实意图，以便提升检索效果。
2. 在执行检索后，你可能会发现存在一些无关的信息，需要想办法减少无关信息，避免干扰下一步的答案生成。

3.4.1 问题改写

【方法一：使用大模型扩充用户问题】

你可以让大模型充当一个问题改写助手。它会帮你把简单的问题改写得更加完整和清晰。比如，它不仅会考虑到可能存在多个张伟的情况，还会把相关的上下文信息都补充进去。看看具体怎么做：

query_gen_str = """\
系统角色设定:
你是一个专业的问题改写助手。你的任务是将用户的原始问题扩充为一个更完整、更全面的问题。

规则：
1. 将可能的歧义、相关概念和上下文信息整合到一个完整的问题中
2. 使用括号对歧义概念进行补充说明
3. 添加关键的限定词和修饰语
4. 确保改写后的问题清晰且语义完整
5. 对于模糊概念，在括号中列举主要可能性

原始问题:
{query}

请生成一个综合的改写问题，确保：
- 包含原始问题的核心意图
- 涵盖可能的歧义解释
- 使用清晰的逻辑关系词连接不同方面
- 必要时使用括号补充说明

输出格式：
[综合改写] - 改写后的问题
"""
query_gen_prompt = PromptTemplate(query_gen_str)   


def generate_queries(query: str):
    response = Settings.llm.predict(
        query_gen_prompt, query=query
    )
    return  response    

# 生成扩展查询
print("\n🔍 原始问题:")
print(f"   {question}")
query = generate_queries(question)
print("\n📝 扩展查询:")
print(f"   {query}\n")

# 创建查询引擎
query_engine = sentence_index.as_query_engine(
    streaming=True,
    similarity_top_k=5
)
# 执行查询
response = query_engine.query(query)

print("💭 AI回答:")
print("-" * 40)
response.print_response_stream()
print("\n")

# 显示参考文档
print("\n📚 参考依据:")
print("-" * 40)
for i, node in enumerate(response.source_nodes, 1):
    print(f"\n文档片段 {i}:")
    print(f"相关度得分: {node.score:.4f}")
    print("-" * 30)
    print(node.text)

# 评估结果
print("\n📊 回答质量评估:")
print("-" * 40)
evaluation_score = evaluate_result(query, response, ground_truth)
display(evaluation_score)

【方法二：将单一查询改写为多步骤查询】

除了改写问题，你还可以尝试另一种思路：把复杂的问题拆解成简单的步骤。LlamaIndex 提供了两个强大的工具来实现这个功能：

• StepDecomposeQueryTransform： 这个工具可以帮你把一个复杂问题分解成多个子问题。比如对于"张伟是哪个部门的?",它会先分解为：
  1. “公司里有几个叫张伟的员工？”
  2. “这些张伟分别在哪些部门？”

这样可以更全面地获取所有张伟的信息。

• MultiStepQueryEngine： 这个查询引擎会按顺序处理这些子问题。它会先获取公司所有张伟的信息，然后再查询每个张伟的部门信息，最终将答案整合成一个完整的回应，告诉用户"公司有三名张伟，分别在教研部、课程开发部和IT部"。

这种方法就像解决数学题一样 - 把大问题分解成小问题往往更容易得到准确的答案。不过要注意，这种方法会多次调用大模型，所以会消耗更多的token。

from llama_index.core.indices.query.query_transform.base import (
    StepDecomposeQueryTransform,
)
step_decompose_transform = StepDecomposeQueryTransform(verbose=True)
# set Logging to DEBUG for more detailed outputs
from llama_index.core.query_engine import MultiStepQueryEngine
query_engine = sentence_index.as_query_engine(streaming=True,similarity_top_k=5)
query_engine = MultiStepQueryEngine(
    query_engine=query_engine,
    query_transform=step_decompose_transform,
    index_summary="公司人员信息"
)
print(f"❓ 用户问题: {question}\n")
print("🤖 AI正在进行多步查询...")
response = query_engine.query(question)
print("\n📚 参考依据:")
print("-" * 40)
for i, node in enumerate(response.source_nodes, 1):
    print(f"\n文档片段 {i}:")
    print("-" * 30)
    print(node.text)

# 评估结果
print("\n📊 多步查询评估结果:")
print("-" * 40)
evaluation_score = evaluate_result(question, response, ground_truth)
display(evaluation_score)

【方法三：用假设文档来增强检索（HyDE）】

前面的方法都是在调整问题本身，现在让我们换个思路：如果我们先假设一个可能的答案会怎样？这就是HyDE（Hypothetical Document Embeddings）方法的独特之处。

它的工作方式很有趣：

1. 先让大模型基于问题编一个"假想的答案文档"
2. 用这个假想文档来检索真实文档
3. 最后用检索到的真实文档来生成实际答案

这就像你在找一本书时，心里已经有了一个大致的内容轮廓，然后用这个轮廓去图书馆匹配相似的书籍。让我们看看具体怎么实现：

from llama_index.core.indices.query.query_transform.base import (
    HyDEQueryTransform,
)
from llama_index.core.query_engine import TransformQueryEngine
# run query with HyDE query transform
hyde = HyDEQueryTransform(include_original=True)
query_engine = sentence_index.as_query_engine(streaming=True,similarity_top_k=5)
query_engine = TransformQueryEngine(query_engine, query_transform=hyde)

print(f"❓ 用户问题: {question}\n")
print("🤖 AI正在通过 HyDE 分析...")
streaming_response = query_engine.query(question)

print("\n💭 AI回答:")
print("-" * 40)
streaming_response.print_response_stream()

# 显示参考文档
print("\n📚 参考依据:")
print("-" * 40)
for i, node in enumerate(streaming_response.source_nodes, 1):
    print(f"\n文档片段 {i}:")
    print("-" * 30)
    print(node.text)

# 评估结果
print("\n📊 HyDE 查询评估结果:")
print("-" * 40)
evaluation_score = evaluate_result(question, streaming_response, ground_truth)
display(evaluation_score)

虽然这个"假想文档"完全是AI编造的，但它的结构和风格与真实的公司员工信息非常相似。LlamaIndex提供了灵活的控制机制来优化这个过程：

HyDEQueryTransform类允许我们通过以下方式精确控制假想文档的生成：

• 自定义LLM：通过llm参数传入不同的大模型配置，可以选择更适合的语言模型来生成假想文档
• 提示词模板：通过hyde_prompt参数自定义提示词模板，精确控制输出的格式和内容
• 查询策略：使用include_original参数决定是否将原始查询与假想文档结合使用

TransformQueryEngine则作为查询引擎的包装器，它会：

1. 先调用HyDEQueryTransform生成假想文档
2. 使用假想文档进行向量检索
3. 最后返回查询结果

这种架构让我们能在不修改底层查询引擎的情况下，通过调整HyDEQueryTransform的参数来优化检索效果。即使假想文档的具体内容可能不够准确，但通过精心设计的配置，它可以帮助系统更准确地检索相关信息。

3.4.2 提取标签增强检索

在向量检索的基础上，我们还可以添加标签过滤来提升检索精度。这种方式类似于图书馆既有书名检索，又有分类编号系统，能让检索更精准。

标签提取有两个关键场景：

1. 建立索引时，从文档切片中提取结构化标签
2. 检索时，从用户问题中提取对应的标签进行过滤

当我们建立索引时，可以将这些标签与文档切片一起存储。这样在检索时，比如用户问"张伟是哪个部门的"，我们可以：

1. 从问题中提取人名标签 {“key”: “人名”, “value”: “张伟”}
2. 先用标签过滤出所有包含"张伟"的文档切片
3. 再用向量相似度检索找出最相关的内容

这种"标签过滤+向量检索"的组合方式，能大幅提升检索的准确性。特别是在处理结构化程度较高的企业文档时，这个方法效果更好。

3.4.3 重排序

重排序是指对召回结果进行重新计算和排序的过程。

3.5 生成答案阶段

现在，大模型会根据你的问题和检索召回的内容，生成最终的答案。然而，这个答案可能还是不及你的预期。你可能会遇到的问题有：

1. 没有检索到相关信息，大模型捏造答案。
2. 检索到了相关信息，但是大模型没有按照要求生成答案。
3. 检索到了相关信息，大模型也给出了答案，但是你希望 AI 给出更全面的答案。

为了解决这些问题，你可以从以下角度着手分析与解决：

1. 选择合适的大模型：

   1. 如果只是简单的信息查询总结，小参数量的模型足以满足需求，比如 qwen-turbo 。
   2. 如果你希望答疑机器人能完成较为复杂的逻辑推理，建议选择参数量更大、推理能力更强的大模型，比如 qwen-plus 甚至是 qwen-max 。
   3. 如果你的问题需要查阅大量的文档片段，建议选择上下文长度更大的模型，比如 qwen-long 、qwen-turbo 或qwen-plus 。
   4. 如果你构建的 RAG 应用面向一些非通用领域，如法律领域，建议使用面向特定领域训练的模型，如farui-plus 。

2. 充分优化提示词模板，比如：

   1. 明确要求不编造答案：大模型可能会产生一些不真实的内容，通常称为幻觉。你可以通过提示词要求大模型：「如果所提供的信息不足以回答问题，请明确告知"根据现有信息，我无法回答这个问题。“切勿编造答案。」，来减少大模型产生幻觉的几率。
   2. 添加内容分隔标记：检索召回的文档切片如果随意混杂在提示词里，人也很难看清整个提示词的结构，大模型也会受到干扰。建议将提示词和检索切片明确地分开，以便大模型能够正确地理解你的意图。
   3. 根据问题类型调整模板：不同问题的回答范式可能是不同的，你可以借助大模型识别问题类型，然后映射使用不同的提示词模板。比如有些问题，你希望大模型先输出整体框架，然后再输出细节；有些问题你可能希望大模型言简意赅的给出结论。

3. 调整大模型的参数，比如：

   1. 如果你希望大模型输出在相同的问题下，输出的内容尽可能相同，你可以在每次模型调用时传入相同的seed值。
   2. 如果你希望大模型在回答用户问题时不要总是用重复的句子，你可以适当调高 presence_penalty 值。
   3. 如果你希望查询事实性的内容，可以适当降低 temperature 或 top_p 值；反之，查询创造性的内容时，可以适当增加它们的值。
   4. 如果你需要限制字数（如生成摘要、关键词）、控制成本或减少响应时间的场景，可以适当降低max_tokens的值，但是若max_tokens过小，可能会导致输出截断，反之，需要生成大段文本时，可以提高它的值。
   5. 你也可以查阅千问 API Reference ，来了解更多参数的使用说明。

4. 调优大模型：如果上述方法都做了充分的尝试，仍然不及预期，或者希望有更进一步的效果提升，你也可以尝试面向你的场景调优一个模型。在后续的章节中，你将学习和实践这一点。

本节小结

通过前面的学习，你已经了解了一个简单 RAG 的工作流程，以及常见优化手段。你也可以结合前面学习到的知识，结合实际需求，将不同的问题，路由到不同的 RAG 应用中，以构建一个能力更强大的模块化 RAG 应用。此外，通过前面的学习，你应该也能发现，大模型不只是可以用于构建问答系统。借助大模型识别用户意图、提取结构化信息（比如前面的根据用户问题提取标签），也能在很多其他应用场景中发挥作用。

当然，RAG 的优化手段远不止课程中介绍的这些，业内关于 RAG 的研究和探索也在持续进行，还有很多高级 RAG 课题值得你去学习。从前面的学习可以看到，构建一个完善、表现得足够好的 RAG 应用并不简单。而在实际工作中，你可能需要更快地捕捉业务机会，没有时间投入到这些细节完善中。以下是一些值得探索的方向：

• GraphRAG 技术巧妙地结合了检索增强生成（RAG）和查询聚焦摘要（QFS）的优点，为处理大规模文本数据提供了一个强大的解决方案。它把两种技术的特长融合在一起：RAG 擅长找出精确的细节信息，而 QFS 则更善于理解和总结文章的整体内容。通过这种结合，GraphRAG 既能准确回答具体问题，又能处理需要深入理解的复杂查询，特别适合用来构建智能问答系统。
  如果你想深入了解如何实际运用 GraphRAG，可以参考 LlamaIndex 提供的详细教程：使用 LlamaIndex 构建 GraphRAG 应用 。