实用笔记：AI系列：RAG中最难的部分之二——为何要追求完美

本指南将逐步构建从原始材料到可运行系统的完整流程，内容涉及《AI系列：RAG中最棘手的难题——第二部分：为何完美的数据块仍会导致糟糕的检索结果》。重点在于可操作的步骤、明确的检查点，以及可直接放入代码库中的代码，无需猜测其用途。 在概览阶段，应在修改代码之前明确输入参数、各步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏的状态。 除了功能结果外，还需记录执行时间以及token或查询成本。提前了解成本情况，可避免在流程从演示环境过渡到共享环境时出现意外费用。

首先，什么是嵌入向量？

在完成“什么是”第一阶段的工作时，首先写下相关契约：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 将配置信息与应用程序代码分开存放。环境文件、密钥存储以及功能开关应集中于一个位置，这样操作人员无需查看整个系统结构即可进行审计。 在调整提示词之前，先使用固定的问题集来测试召回率。仅仅更换提示词往往无法解决检索效果不佳的问题。

"How do I reset my password?"     → [0.81, 0.12, -0.44, 0.09]
"Steps to change your password"   → [0.79, 0.15, -0.41, 0.11]
"How do I cancel my subscription?"→ [0.22, 0.68, 0.05, -0.39]

from numpy import dot
from numpy.linalg import norm

def cosine_similarity(a, b):
    return dot(a, b) / (norm(a) * norm(b))

query = [0.80, 0.13, -0.42, 0.10]  # "reset my password"

print(cosine_similarity(query, [0.81, 0.12, -0.44, 0.09]))  # 0.998 - very close
print(cosine_similarity(query, [0.22, 0.68, 0.05, -0.39]))  # 0.310 - far apart

为何检索任务如此困难

在处理“为何检索才是真正的解决方案”这一阶段时，首先需列出相关约定：所需输入、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 同时记录正常流程与异常恢复流程。重试机制、人工审核环节以及死信处理都是产品本身的组成部分，而非后续的优化工作。 在调整提示词之前，需先用固定的问题集来衡量检索的召回率。仅仅更换提示词很难解决检索效果不佳的问题。

真正的检索流程是怎样的

在处理“真正的检索是什么”这一阶段时，首先需明确相关规范：所需的输入参数、成功标志以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 相较于庞大的脚本，应优先选择小型且可测试的单元。当某个步骤出现故障时，故障点应指向单一责任模块，而非复杂的流程链。 在调整提示词之前，先使用固定的问题集来衡量检索的召回率。仅仅更换提示词很难解决检索效果不佳的问题。 在处理“真正的检索是什么”这一阶段时，首先需明确相关规范：所需的输入参数、成功标志以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持一致性。 除了功能结果外，还需记录执行时间以及token或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。

混合搜索：为何仅靠向量搜索不够

将向量搜索视为可测量的表面时，混合搜索效果最佳。在扩大范围之前，先记录一个成功的案例、一个失败的案例以及回滚说明。 将配置置于应用程序代码之外。环境文件、密钥存储和功能标志应集中存放，以便操作人员无需查看整个结构即可进行审计。 将分块策略与检索策略分开。当质量指标发生变化时，修改其中一项不应迫使重新编写另一项。

from collections import defaultdict

def reciprocal_rank_fusion(result_lists, k=60):
    scores = defaultdict(float)
    for result_list in result_lists:
        for rank, doc_id in enumerate(result_list):
            scores[doc_id] += 1 / (k + rank + 1)
    return sorted(scores, key=scores.get, reverse=True)

vector_ids = [d.metadata["chunk_id"] for d in vector_store.similarity_search(query, k=20)]
bm25_ids = [d.metadata["chunk_id"] for d in bm25_index.search(query, k=20)]

final_ranking = reciprocal_rank_fusion([vector_ids, bm25_ids])

重排序是无人会跳过的步骤

将重排步骤视为可测量的流程时，其效果最佳。在扩大范围之前，先记录一个成功的案例、一个失败案例以及回滚说明。同时记录正常流程与恢复流程的细节。重试机制、人工审核环节以及死信处理都是产品本身的一部分，而非后续需要补充的内容。应将分块策略与检索策略分开，当质量指标发生变化时，修改其中一项不应迫使重新编写另一项。

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("BAAI/bge-reranker-base")

def rerank(query, candidates, top_n=5):
    pairs = [(query, c["text"]) for c in candidates]
    scores = reranker.predict(pairs)
    for c, s in zip(candidates, scores):
        c["rerank_score"] = float(s)
    return sorted(candidates, key=lambda c: c["rerank_score"], reverse=True)[:top_n]

解决核心问题，而非仅仅优化索引

将“修复问题”阶段视为可度量的对象来处理效果最佳。在扩大范围之前，先记录一份理想的测试用例、一个故障案例以及回滚说明。 优先选择小型且可测试的单元，而非庞大的脚本。当某个步骤出现故障时，故障应指向单一责任模块，而非复杂的流程链。 将分块策略与检索策略分开。当质量指标发生变化时，修改其中一项不应迫使重新编写另一项。 将“修复问题”阶段视为可度量的对象来处理效果最佳。在扩大范围之前，先记录一份理想的测试用例、一个故障案例以及回滚说明。 在功能结果之外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。

def hyde_retrieve(query, llm, vector_store, k=5):
    hypothetical = llm.invoke(f"Write a short passage answering: {query}")
    return vector_store.similarity_search(hypothetical, k=k)

用数据衡量而非凭直觉判断

在采用“测量而非阶段”模式时，应在修改代码之前明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储以及功能标志应集中存放于一个位置，以便操作人员无需查看整个流程即可进行审计。 需引用实际作为答案依据的段落。如果没有引用，操作人员就无法区分是幻觉内容还是索引缺失导致的错误。

def recall_at_k(retrieved_ids, relevant_ids, k):
    top_k = set(retrieved_ids[:k])
    return len(top_k & relevant_ids) / len(relevant_ids) if relevant_ids else 0.0

给今天开始从事这项工作的人的建议

在“你要说明什么”阶段，应在修改代码之前明确输入内容、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及错误处理都是产品本身的组成部分，而非后续需要补充的内容。 要引用那些真正作为答案依据的段落。如果没有引用，操作人员就无法区分是幻觉内容还是索引缺失导致的错误。

RAG背后不为人知的真相

在“关于令人不安的真相”阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 优先选择小型、可测试的单元，而非冗长的脚本。当某个步骤失败时，故障应指向单一责任点，而非复杂的流程链。 需引用实际作为答案依据的段落。没有引用的话，操作人员就无法区分是幻觉内容还是索引缺失导致的错误。 在“关于令人不安的真相”阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 除了功能结果外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在流程从演示模式转为共享模式时出现意外费用。

在各种环境中。

操作检查清单

将操作检查清单阶段视为可衡量的标准，效果最佳。在扩大范围之前，需记录一份最优输出样本、一个故障案例以及回滚说明。

把这一阶段视为输入与已验证输出之间的契约。为相关成果命名，明确成功标准，杜绝默许的半完成状态。

将分块策略与检索策略分开。当质量指标发生变化时，修改其中一项不应强制重新编写另一项。

分别对单轮回复和多轮对话的表现进行评分。仅汇总聊天评分会掩盖工具循环故障。

编写简短的操作手册：如何轮换密钥、如何清空队列、如何回滚最近的输入数据。

请同时记录正常流程和故障恢复流程。重试机制、人工审核环节以及死信处理都是产品不可或缺的部分，而非后续需要补充的功能。

在推广该技术栈之前，应先冻结版本，为关键流程保存标准操作记录，并明确回滚步骤。共享环境需要设置速率限制、进行租户身份验证，同时指定专人负责密钥轮换工作。与其展示花哨的一次性演示，不如注重扎实的可靠性。

针对 da3fc7392f6d 的批量说明：请勿将提供方密钥放入代码仓库，应为每个会话设置令牌使用上限，并将操作记录与评估用配置文件存放在同一位置，以便后续更换模型时保持数据可比性。