实用笔记：什么是检索增强生成（RAG）？实用指南

以下笔记围绕《什么是检索增强生成（RAG）？附Python示例的实用指南——Geeky Codes》整理出一条实用学习路径。重点在于契约定义、校验机制以及可直接插入的代码占位符，而非激励性表述。

了解RAG的工作原理、大语言模型为何会产生幻觉，并用Python构建你的第一个检索增强生成流程。

在学习RAG工作原理的阶段，首先需明确契约内容：所需输入、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续代码修改的透明度。 将配置信息置于应用程序代码之外。环境文件、密钥存储和功能开关应集中存放，以便操作人员无需查看整个系统结构即可进行审计。 每次调用时都要记录请求ID、模型ID及延迟时间。若没有这些记录，间歇性的服务错误就会被视为应用程序的故障。

检索阶段

在处理检索阶段时，首先写下相关规范：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改不会偏离原有设计。 同时记录正常流程和异常恢复流程。重试机制、人工干预环节以及错误消息处理都是产品功能的一部分，而非后续需要补充的内容。 每次调用时都要记录请求ID、模型ID以及响应延迟时间。如果没有这些记录，间歇性的服务错误就会被视为应用程序的缺陷。

增强阶段

在处理增强阶段时，首先写下契约：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 优先选择小型、可测试的单元，而非庞大的脚本。当某个步骤失败时，故障应能指向单一的责任模块，而非复杂的流程链。 每次调用时都要记录请求ID、模型ID以及延迟时间。没有这些记录，间歇性的服务端错误就会被视为应用程序的缺陷。

生成阶段

在生成阶段工作时，首先写下契约：所需的输入、成功信号以及部分失败时会发生什么。这样的清单能确保后续的代码修改保持一致性。 将这一阶段视为输入与经过验证的输出之间的契约。为相关成果命名，定义成功检查标准，并拒绝默许的部分完成。 每次调用时都要记录请求ID、模型ID以及延迟时间。没有这些记录，间歇性的服务提供商错误就会被视为应用程序的故障。

                    Documents
                        │
                        ▼
                  Data Ingestion
                        │
                        ▼
                   Text Extraction
                        │
                        ▼
                    Chunking
                        │
                        ▼
                  Embedding Model
                        │
                        ▼
                 Vector Database
──────────────────────────────────────────

                  User Question
                        │
                        ▼
                Query Embedding
                        │
                        ▼
                 Similarity Search
                        │
                        ▼
              Top-K Relevant Chunks
                        │
                        ▼
                 Prompt Builder
                        │
                        ▼
                  Large Language Model
                        │
                        ▼
                     Final Answer

from sentence_transformers import SentenceTransformer
import faiss
import numpy as np

documents = [
    "Employees receive 20 days of paid leave every year.",
    "Annual bonuses are paid in December.",
    "Health insurance covers hospitalization expenses."
]

model = SentenceTransformer("all-MiniLM-L6-v2")
embeddings = model.encode(documents)

index = faiss.IndexFlatL2(embeddings.shape[1])

index.add(np.array(embeddings).astype("float32"))

query = "How many leave days do employees receive?"

query_embedding = model.encode([query])

D, I = index.search(
    np.array(query_embedding).astype("float32"),
    k=1
)

print(documents[I[0][0]])

常见的生产环境挑战

在处理“常见生产环境挑战”阶段时，首先需明确合同规范：所需输入、成功标志以及部分失败时的处理方式。这份清单能确保后续的代码修改保持一致性。 在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在系统从演示环境过渡到共享环境时出现意外账单。 每次调用都要记录请求ID、模型ID和延迟时间。如果没有这些记录，间歇性的服务提供商错误就会被视为应用程序故障。 在处理“常见生产环境挑战”阶段时，首先需明确合同规范：所需输入、成功标志以及部分失败时的处理方式。这份清单能确保后续的代码修改保持一致性。 需同时记录正常流程和故障恢复流程。重试机制、人工审核环节以及死信处理都是产品本身的组成部分，而非后续的优化工作。

核心要点

“关键要点”环节若被视为可量化的评估标准，效果会最佳。在扩大范围之前，先记录一份优秀的实现示例、一个失败案例以及回滚说明。 相较于庞大的脚本，应优先选择小型且可测试的单元。当某一步骤失败时，故障应能指向单一责任模块，而非复杂的流程链。 在讲解循环之前，先确定解释器及依赖项的锁定文件。笔记本电脑与持续集成环境之间的差异是API演示中最常见的隐性故障原因。

参考资料

将“参考资料”阶段视为可度量的环节最为有效。在扩大范围之前，先记录一份最佳案例、一个失败实例以及回滚说明。应将此阶段视为输入与已验证输出之间的契约，为相关文档命名、明确成功标准，并杜绝默许的半完成状态。在讲解循环逻辑之前，需先固定解释器及依赖项锁定文件。在笔记本电脑与持续集成环境之间切换是API演示中最常见的隐性故障来源。

操作检查清单

对于“操作检查清单”阶段，应在修改代码之前明确输入内容、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏的状态信息。

将配置置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一处，这样操作人员无需查看全部架构即可进行审计。

将客户端构建与消息处理循环分开，这样在无需重写对话状态机的情况下即可更换服务提供方。

在调整提示词之前，先使用固定的问题集来测试召回率。仅仅更换提示词往往无法解决检索效果不佳的问题。

在更改提示词或模型之前，先确定一套基准数据。同时调整系统和评估标准会掩盖潜在的退化问题。

只要预算允许，就在持续集成过程中使用测试数据而非真实的付费 API 来执行针对关键路径的冒烟测试。

在推广该技术栈之前，应先冻结版本，为关键流程记录标准输出日志，并明确回滚步骤。共享环境需要设置速率限制、租户验证机制，以及明确的密钥轮换负责人。与其展示花哨的一次性演示，不如注重扎实的可靠性。

针对 ce641ce6bc02 的批量说明：请将提供商密钥移出代码仓库，设定单会话令牌上限，并将日志存储在评估用示例文件旁，以便后续模型更换时保持数据可比性。