面向非ML工程师的RAG管道：领域专家如何构建检索系统

最了解数据的人很少是构建检索系统的人。心内科医生知道出院摘要中哪些部分对随访风险评估很重要。建筑工程师知道工程量清单中哪些项目表明范围蔓延。合规官知道监管文件中哪些条款预示着重大风险。但当需要构建一个检索和呈现这些信息的RAG管道时，这些领域专家退到一旁，将工作交给一位不具备他们专业知识的ML工程师。

这是当今企业AI应用的核心摩擦。面向非ML工程师的最佳RAG管道构建器在大多数组织中并不存在，因为工具假定用户精通Python、有终端访问权限，并且熟悉嵌入模型、向量数据库和分块策略。结果是一个瓶颈：最接近问题的人要等待数周，让ML团队实现他们一个下午就能定义的东西——如果工具允许的话。

拖慢每个RAG项目的知识鸿沟

考虑一个我们在企业部署中反复看到的真实模式。

一家中型律所的法务团队想要在15年的合同档案上构建一个检索系统。他们需要系统在律师起草新协议时呈现相关的先例条款。律师们确切知道哪些条款类型重要、如何分类，以及什么构成有意义的匹配而非表面匹配。

但律师们无法构建管道。他们撰写需求文档。ML工程师阅读后进行解读，用LangChain构建管道，选择分块策略，选择嵌入模型并部署。律师测试后发现某些条款类型的检索质量不佳，提交反馈。ML工程师调整分块参数。又一轮测试。又一轮反馈。整个周期需要六到八周。

瓶颈不是算力，不是模型质量，而是理解领域的人和理解工具的人之间的翻译层。

这个模式在各行业重复出现：

临床团队审查患者笔记时，需要检索系统能理解"提及的状况"和"已诊断的状况"之间的区别。没有临床培训的ML工程师对两者一视同仁。

土木工程师审查工程量清单时，需要检索系统能区分标准项目和隐藏在修订文件中的变更令。这种细微差别对领域外的人来说是不可见的。

金融分析师在财报电话会议记录上构建检索时，需要系统对前瞻性声明和历史业绩摘要进行不同的权重处理。这种区别需要领域知识，再多的提示工程也无法替代。

在每种情况下，领域专家拥有判断力，ML工程师拥有工具。项目停滞在两者之间的鸿沟中。

为什么传统RAG工具将领域专家排斥在外

构建RAG管道的标准方法涉及多个步骤，每个步骤都需要编程知识：

文档摄取需要编写脚本来解析PDF、提取文本、处理扫描文档的OCR以及管理元数据。大多数框架假定你会用Python来完成这些工作。

分块需要选择策略——固定大小、递归、语义——并调整分块大小和重叠等参数。决策取决于文档类型，但实现需要代码。

嵌入需要选择模型、配置模型并生成向量表示。一些框架对此进行了抽象，但配置仍然在代码或YAML文件中进行。

检索需要设置向量存储、配置相似性搜索参数，通常还需要实现带关键词匹配的混合搜索。同样需要代码。

质量评估需要构建评估数据集、运行检索测试以及计算召回率和精确率等指标。这个步骤经常被完全跳过，因为它需要最大的工程投入。

每个步骤单独来看并非不可能的复杂。但合在一起，它们形成了一个只有能够熟练编写和调试Python的人才能构建和修改的管道。结果是，使用大多数现有工具，无代码构建RAG管道实际上是不可能的。

当领域专家可以直接构建时会发生什么改变

这个转变不是要降低技术门槛。而是要改变界面，让拥有正确判断力的人能够做出正确的决策。

可视化管道构建器——比如Ertas画布——让领域专家通过拖拽节点来构建RAG管道的每个阶段。文档摄取、分块策略、嵌入模型选择、检索配置和质量评估变成了可以连接、配置和测试的可视化组件，无需编写任何Python代码。

以下是上述三个场景的实际效果：

法务团队将合同档案拖入摄取节点，选择针对法律文档优化的分块策略，并将其连接到嵌入节点。他们用已知答案的示例查询测试检索效果。当某些条款类型返回不佳的结果时，他们直接调整分块参数——更改重叠率、对附录切换到语义分块——然后重新运行测试。反馈循环从数周缩短到数小时。

临床团队在出院摘要上构建管道。他们使用Quality Scorer来识别哪些分块产生了低置信度的检索结果。他们发现包含药物列表的分块被匹配到了诊断查询。他们调整分块边界，将药物部分与诊断叙述分开。无需提交工单，无需咨询ML工程师。

土木工程团队配置跨越数百个工程量清单文件和修订记录的项目文档检索。他们设置元数据过滤器，使检索能区分原始范围和变更令。当Quality Scorer标记出某些项目阶段的不一致结果时，他们细化元数据标记并重新评估——所有操作都在同一可视化界面中完成。

Quality Scorer：领域专家真正能理解的反馈

构建无Python的RAG管道的最大障碍之一是评估。传统评估需要编写脚本来计算检索指标、构建黄金数据集并解读统计输出。

Ertas的Quality Scorer用可视化、可解读的反馈取代了这一切。在领域专家构建和测试管道之后，Quality Scorer向他们展示：

• 哪些查询返回高置信度结果，哪些没有
• 哪些文档分块被最频繁检索，哪些从未被呈现
• 管道在哪里产生矛盾或低相关性的结果

这些反馈以领域专家能理解的术语呈现——不是F1分数和平均倒数排名，而是对哪些查询有效、哪些无效以及可能原因的直白评估。医生可以看着输出说："这个管道混淆了药物副作用和已诊断的症状"，然后相应地修正分块策略。

谁应该拥有RAG管道

问题不在于领域专家能否构建RAG管道。有了合适的界面，他们显然可以。问题在于组织是否愿意重新调整所有权，让拥有领域知识的人也能控制依赖这些知识的检索系统。

当前的模式——领域专家定义需求，ML工程师实现——创建了一个引入延迟、误解和不必要迭代的翻译层。理解数据的人与检索数据的系统之间的每一个中间步骤，都是质量下降的机会。

当律师可以构建和修改自己的合同检索管道时，检索质量会提高，因为做出分块和配置决策的人真正理解文档。当临床医生可以调整患者笔记的索引方式时，系统反映的是临床判断而非工程师的近似推测。

这不是理论上的改进。将管道所有权转移给领域专家的组织看到了更快的迭代周期、更高的领域特定查询检索准确率，以及技术团队和非技术团队之间更少的来回沟通。

无需ML背景即可开始

无需Python经验构建RAG管道现在是一个实际可行的现实，而非未来的愿景。使用可视化管道构建器的过程遵循一个直接的顺序：

1. 上传您的文档 —— PDF、临床笔记、合同、工程规范，您的领域产生的任何文档
2. 可视化配置分块 —— 选择策略、调整参数、预览文档如何被分割
3. 选择嵌入模型 —— 从适合您文档类型和语言的预配置选项中选择
4. 用真实查询测试 —— 运行您团队实际提出的查询，而非合成基准测试
5. 查看Quality Scorer反馈 —— 识别薄弱环节并调整配置
6. 迭代 —— 根据领域特定的反馈，优化分块、元数据和检索设置

整个过程在可视化画布上完成。无需终端。无需包管理器。无需调试堆栈跟踪。

面向非ML工程师的最佳RAG管道构建器是尊重领域专家已有知识并消除阻碍他们直接应用这些知识的障碍的工具。数据属于专家。检索系统也应如此。