来源

• 原始链接：https://www.youtube.com/watch?v=Akm1sqvWG4A
• 来源类型：视频逐字稿
• 来源标题：绕过多模态税：混合 RAG、SQL RRF 与 UI 遥测

混合 RAG 与多模态税高亮

这篇演讲是一套从文档摄入到检索、回答、遥测和安全防护的端到端 RAG 实践。它最有价值的地方，是把“绕过多模态税”落到工程动作：先在本地把文档结构化，尽量少让 LLM 读脏数据，再用混合检索和代码护栏把系统做可控。

一、不要把整份文档直接交给云端聊天框

背景

演讲开头定义了“多模态税”：用户刚上传 PDF、Word 或图片，还没开始提问，token 已经被文档消耗掉，而且你无法控制对方如何分块和理解文档。

文档一上传，我们就会消耗掉一部分原本应该用于处理问题的 token——还没提问，token 就已经花出去了。

直接上传到云端 chatbot 的问题是，你不知道文档在那边是如何被分块的，LLM 是如何“看”它的，比如表格是否被正确读取，这会带来质量风险。

我们希望对文档在数据库中的存储方式和检索方式有更清晰的掌控。

兴趣匹配判断：这对任何企业 RAG 都是第一性问题。成本、质量和可调试性都要求把“上传给模型”前移为“本地结构化、入库、可检索、可追踪”。

二、Markdown 优先结构化，是降低幻觉的基础动作

背景

演讲者用 Docling 将原始文档转成 Markdown，再根据文档类型选择不同分块策略。重点不是分块算法炫技，而是清理数据比换大模型更重要。

另一种方式是“结构优先”——使用本地 CPU，通过 Docling 将文档转换为 Markdown 文件，这样我们对分块方式有更清晰的了解。

签名日期这种内容基本上是无用的。这会降低对话的准确性，增加幻觉。所以，与其直接上传 28 页的完整文档，不如将文档拆分成不同的相关文件，尽量清理数据，再上传，效果会好很多。

对于 FAQ 场景，一种方式是将数据整理成问答格式——这样引用文档时就能得到准确的引用，不会产生混淆。

兴趣匹配判断：这是一条很可复用的 workflow：原始文档 → Markdown → 清洗 → 按语义结构分块 → 入库。RAG 质量的大头往往在摄入端，而不是回答端。

三、分块策略要跟文档类型匹配

背景

演讲实际演示了 heading-based、paragraph、固定长度、sentence group 等策略。它没有把“最佳分块大小”当通用答案，而是把分块看作产品场景选择。

基于标题的分块策略会按照文档中的标题逐一理解并分块文档。如你所见，我们的问题是关于某个具体内容的，系统给出了答案……引用清晰，如果有任何问题，你知道去哪里排查。

固定 512 字符分块的问题是——它会在句子中间截断，不是最理想的，但在某些情况下是可行的。

如果时间紧迫，只是一条简短的消息，比如临时变更通知，你不需要花时间清理数据，只需拖拽上传，周末的维护计划就人人皆知了。

兴趣匹配判断：这对构建通用文档 agent 很重要。FAQ、政策、截图邮件、产品目录、医疗文档不该共享同一种 chunker；系统应允许摄入时选择或推断合适策略。

四、直接 RAG 往往比多 agent 更适合合规场景

背景

演讲者刻意区分“Python 函数”与真正的多 agent。能用确定性代码做的事情，就不要为了 agent 感强行多轮 LLM 调用。

它们只是 Python 代码，并不是调用另一个 LLM 来帮我们做事的真正 agent。这样设计的主要原因是速度——不需要三四个 agent 循环三四次，否则要等 20 到 30 秒，用户会失去耐心。

只需要一次自然语言调用，其余能用 Python 函数完成的事情就用 Python 函数来做，这样你对函数有完全的控制权，不会有幻觉。

如果合规性对你很重要，直接 RAG 是更好的选择。而 agent 模式有一些额外工具可以调用，但控制力较弱，而且耗时更长。

兴趣匹配判断：这是非常实用的 agent 系统设计原则。生产系统不应该用“agent”包装所有逻辑；确定性函数、直接 RAG、控制流和少量 LLM 调用，往往更快、更可控、更容易审计。

五、混合检索的关键是精确匹配与重排融合

背景

演讲者把向量检索、BM25、RRF / reranker 和返回数量放在同一个系统里讨论。它提醒：语义相似不是所有问题的答案，尤其涉及 SKU、数字、药品名和产品名。

如果你做的是客服产品 chatbot，你不需要“最相近”的信息，你需要的是精确信息。涉及数字、产品名称，或者医疗 chatbot 中的药品名称，你需要的是精确匹配，而不是近似匹配。

所以我们需要同时具备关键词搜索和语义搜索，即混合搜索，以获得更好的结果。

当我们同时有向量检索结果和 BM25 结果时，需要将两者融合，仍然返回前两条或前五条最相关的答案。如果返回前 20 条，对用户来说会非常混乱。

兴趣匹配判断：这条适合所有 RAG 产品。检索层的设计应当根据答案形态调参：FAQ 可少量高精，产品目录要扩大召回，医疗场景要更严格更少分散。

六、安全与遥测要在进入 LLM 前发生

背景

演讲后段强调 LangFuse 观测、guardrail、prompt 注入防护和用户同意。最值得保留的是：不应该把危险输入先发给 LLM，再希望 prompt 叫它拒绝。

很多 guardrail 的核心思想是，问题应该在到达 LLM 之前就被拦截——无论是 prompt 注入还是不应该回答的问题，都不应该发送给 LLM 去生成内容。

注入不应该到达 LLM，应该在发送之前就被拦截。我们使用意图拒绝、词典过滤和 LLM 分类器来阻止这些问题。

因为这只是代码，不需要很长的 prompt，结果是可预期的——你清楚地知道在拦截什么、没有拦截什么。

兴趣匹配判断：这和 agent 安全边界高度相关。安全不应完全委托给系统提示；输入过滤、权限、合规分类、同意控件和追踪日志都应成为应用层能力。

整体判断

这篇非常适合转成 RAG 工程清单：文档先结构化成 Markdown，按类型选择分块策略，检索层同时支持向量与关键词，结果用重排和返回数量控制，能用代码完成的逻辑不要强行 agent 化，guardrail 要在进入 LLM 前执行，生产中用遥测追踪成本、延迟、引用和失败。它的反常识价值在于：小模型加好数据预处理，可能比大模型加脏文档更可靠。