RAG 实战：用 AI 搜索企业知识库

RAG 听起来很技术性，但其有用的核心理念很简单：让 AI 在回答之前搜索选定的公司文档，而不是让它凭空猜测。

大多数小企业的问题不是缺少信息，而是信息分散。价格信息在一个文件夹里，退款规则在某个旧 PDF 里，客服回答埋在邮件里，交付流程在某个人的私人笔记里。企业主、经理或资深管理员成了活的搜索引擎。

这正是 RAG 可以发挥作用的地方。不是黑盒 AI agent，也不是对良好运营的替代。只是一种实用的方式，帮助团队在要求 AI 写答案之前先搜索自己的知识。

RAG 不是 AI 知道一切。而是 AI 先查看选定的公司信息，然后基于这些上下文进行回答。

实际的业务问题

小团队通常知道答案。慢的部分是在正确的时刻找到正确的答案。

• 新员工每周都问同样的入职问题
• 销售团队在回复潜在客户前需要最新的套餐详情
• 支持团队必须在旧对话中搜索政策答案
• 运营在一个地方保存清单，在其他地方保存异常情况
• 企业主成了做任何小决定前每个人都要问的人

普通关键字搜索只在人们知道确切搜索词时才有帮助。真实问题要复杂得多。有人问"我们还能退款吗？"而文档说的是"取消窗口"。有人问"我们的入门套餐包含什么？"而价格表里说的是"基础实施范围"。

RAG 是检索增强生成的意思。用简单的英文说：系统先检索相关信息，把这些信息提供给 AI 模型，然后要求模型基于这个上下文生成答案。

这很重要，因为普通聊天机器人可以在不知道你内部规则的情况下自信地写作。RAG 助手可以被告知只从选定的业务文档中回答，并在答案不在提供的知识中时说明这一点。

一个简单的 RAG 模式：选定的公司文档变成可搜索的知识库，团队在聊天中提问，答案基于检索到的上下文。

向量数据库的作用

向量数据库通过语义而非精确关键字来帮助搜索。如果有人问"退款规则"，而文档中说的是"取消和退货政策"，语义搜索仍然可以找到正确的部分。这是有用的部分；企业在受益于更好的内部搜索之前不需要听关于 embeddings 的讲座。

有一个实用细节很重要：embedding 步骤与答案生成步骤是分开的。embedding 模型将每个已批准的文档块转换为向量。Qdrant 存储和搜索这些向量。语言模型随后可以基于检索到的上下文生成答案。这些工作不应该混在一起。

在小型 RAG 工作流中，每个工具应该有一个明确的工作。

n8n 协调工作流。它接收问题，触发搜索步骤，将检索到的上下文发送给模型，记录结果，并将答案返回给团队。

Qdrant 存储可搜索的文档块。它以一种可以按含义而非确切措辞进行搜索的形式保存选定的公司知识。

embedding 模型创建向量。这可以是 OpenAI 的 embedding API 或其他专门的 embedding 模型。它的工作是将文档和用户的问题转换为可比较的数值表示。

语言模型生成答案。Groq 或其他 LLM 可以用在这里，但它应该基于检索到的上下文回答，而不是编造文档中不存在的政策。

Slack 为团队提供了熟悉的界面。问题和答案可以留在私有内部频道中，而不是放在另一个没人打开的仪表板中。

技术栈本身不是重点。Qdrant、n8n、embedding 模型、答案模型和 Slack 只有在工作流能比手动搜索更快、更一致地回答真实业务问题时才有用。

这可以帮助解决的业务问题

当答案已经存在某处，但团队浪费时间去找它时，知识助手最有用。

这就是为什么 RAG 可以很好地适用于小团队自动化工作。许多团队已经运行在 Drive 文件夹、PDF、电子表格、Notion 页面、邮件线程和聊天中，第一场胜利通常不是替换这些工具。而是让正确的部分变得可搜索。

对于菲律宾的小企业，知识层通常不如正式的公司 wiki 那样完善。它可能是 Google Drive 文件夹、Facebook Messenger 线程、WhatsApp 或 Viber 聊天、Gmail、共享电子表格和只有一个人知道的一些文档的混合体。一个有用的 AI 知识助手应该尊重这个现实：从已批准的文件和流程开始，只有在工作流清楚时才连接到团队的实际工具。

这不会解决什么问题

RAG 不会把坏文档变好。如果源材料已过时、相互矛盾或缺失，助手不应该假装没事。

它不会为你决定公司政策。

它不会自己清理多年的混乱文件。

它不应该在没有访问控制的情况下回答敏感问题。

它不应该把不确定性隐藏在自信的段落后面。

它仍然需要用团队的真实问题进行测试。

一个好的版本应该被允许说："我在提供的文档中找不到那个。"这个答案有时比精心猜测更有价值。

从比你想的更小的地方开始

第一个版本不需要公司曾经创建的每个文件。

一个更好的起始集合可能是 10 到 30 个有用的文档：当前定价、服务范围、退款政策、入职 SOP、支持常见问题、交付检查清单，以及一些人们已经经常问的内部笔记。这足以测试助手是否检索有用上下文，然后再花时间连接更多系统。

第一个构建也应该有一个明确的承诺：从选定文档中回答内部团队问题。不更新客户记录，不发送客户回复，不在没有审查的情况下做决定。

构建前要映射的问题

在将其转变为工作流之前，先映射知识。

• 哪些文档实际上是最新的？
• 团队重复问什么问题？
• 哪些答案仅适合内部使用？
• 哪些答案应该需要经理批准？
• 助手应该在哪里回答：Slack、邮件、Notion 还是其他工具？
• 当答案缺失或不确定时应该发生什么？

这些问题比模型选择更重要。连接到混乱、未审查知识的快速模型仍然会更快地产生混乱的答案。

当企业已经有答案但团队浪费时间去找它们时，RAG 很有用。从一个小的、已批准的知识集合开始，测试真实问题，让助手展示不确定性，而不是用自信的猜测填补空白。

实际目标不是让聊天机器人听起来印象深刻。而是帮助团队更快地找到正确的内部答案，提供足够的上下文让人类信任、检查或改进。

想看工作流版本吗？我用 n8n、Qdrant 和 Groq 构建了一个可检查的 Slack Knowledge Bot，它从已批准的 Google Drive 文档回答，显示来源，并标记低置信度匹配。

n8n RAG 文档

n8n Qdrant Vector Store 节点文档

Qdrant 文档概览

OpenAI embeddings 文档

Groq 模型文档

原文发表于 FloxoLab。