> For the complete documentation index, see [llms.txt](https://doc.duaer.com/zh/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.duaer.com/zh/guides/enterprise-rag-case-selection.md).

# 企业RAG案例怎么选？2027年从五类典型场景起步

本文整理自 Duaer 文档站，围绕企业RAG（检索增强生成）案例的选择，说明典型场景、排序方法、第一个试点的标准、常见误区与衡量方式，帮助团队从边界清楚的场景起步。

## 先说清楚：企业RAG到底解决什么问题

很多企业在2026年前后都做过RAG（检索增强生成）的演示：把几份制度文件放进去，问几个问题，答案看起来不错，大家便觉得可以推广。可真正进入部门日常之后，问题很快暴露出来：答案有时引用错了版本，有时找不到该找的文档，权限一复杂就无从下手。根源往往不在模型，而在于选错了第一个案例。「企业RAG案例」这类搜索背后，真正的需求是知道哪些场景值得先做、先做哪一个、做到什么程度算成功。

RAG的本质是让模型在回答前先去一个可控的资料库里检索相关片段，再基于这些片段生成回答。它适合的是「答案已经写在某处、但人们找不到或读不完」的问题，而不是需要模型凭空推理或创造的问题。

因此判断一个案例是否适合，第一步不是看技术有多先进，而是看三件事：问题的答案是否有明确的来源文档；这些文档是否存在、是否可以被系统访问；以及答错的代价是否可以接受。把这三件事想清楚，案例的边界就出来了。

## 典型场景有哪些

在大多数企业里，RAG的典型场景大致可以归为五类。

第一类是制度与流程问答，比如报销标准、请假规则、采购审批流程。这类内容更新频率低，来源清晰，问题也高度重复，是最常见的起点。

第二类是售前售后的知识支持，比如产品参数、保修条款、常见故障处理手册。它的价值在于缩短一线人员查资料的时间，但对文档的版本管理要求较高。

第三类是合同与合规条款检索，比如某类合同里的付款条件、某项监管要求对应的内部制度条款。这类场景价值高，但答错的代价也大，必须保留人工复核与原文定位。

第四类是研发与运维文档助手，比如接口说明、部署手册、故障复盘记录。资料量大、结构杂，文档质量参差，通常需要先做清洗。

第五类是新人培训与内部知识导航，比如入职指引、岗位职责说明、业务术语解释。它对准确率的容忍度相对较高，适合在组织内部低风险地积累经验。

## 按价值与难度排序，而不是凭感觉挑

确定了候选场景之后，需要一个统一的排序方式。我们通常从两个维度打分：价值看的是这个问题每周被问多少次、每次节省多少查找时间、答错后的业务影响有多大；难度看的是资料是否齐全、是否分散在多个系统、权限结构是否复杂、以及是否需要跨部门协调。

一个实用的做法是把每个场景写在表格里，用高、中、低三档给价值和难度打分，然后优先选择「价值中高、难度低」的那一批。制度问答通常落在这个区间的左上角，而合同条款检索虽然价值高，但往往要排在第二、第三阶段，因为它对权限、审计和复核流程的要求更高。

需要注意的是，「价值高」不等于「应该先做」。如果一个场景价值很高但数据还没有整理，它应该被标记为「先治理数据」，而不是硬塞进试点。关于这种排序方法的更完整讨论，可以参考这篇：[2027年企业AI应用场景怎么排序？先看价值与难度再选试点](https://doc.duaer.com/zh/guides/enterprise-ai-use-case-prioritization/)。

## 怎么选第一个试点

第一个试点的目标不是证明RAG能做很多事，而是验证一条完整链路：资料能进来、检索能命中、答案能追溯、结果能被人评估。因此选择时可以遵循四条标准。

一是资料边界清楚。最好选择一个部门或一个业务线的文档集合，文档数量在可控范围内，责任人也能找到。二是问题样本充足。提前收集真实员工提过的问题，至少几十条，它们会成为后续评测的基础。三是答错可以被发现且可以被纠正。试点阶段最怕的是错误答案长期无人察觉。四是有明确的使用者。找到愿意每天用它、并愿意反馈问题的人，比找到技术最强的团队更重要。

按照这四条标准，制度与流程问答通常是最稳妥的第一个试点。它的资料边界清楚，问题样本容易获得，答错时也便于人工核对原文。

在具体执行时，可以先把候选文档、真实问题和标准答案整理成一张表，再用这张表去跑不同的检索与生成配置，逐项对比结果。如果你希望把这套「选场景、建问题集、做评测」的流程串起来实际跑一遍，也可以直接在 Duaer 里尝试，把试点的资料与问题集放进去，观察检索命中和答案引用的情况，这样比只靠讨论更容易看清问题所在。

## 常见误区：三种看起来合理、实际会拖慢进度的做法

第一种误区是用演示效果做决定。一个精心挑选的问题在演示中表现完美，并不代表日常问题也会如此。试点必须用真实、未经筛选的问题来测。

第二种误区是一次性接入全部文档。资料越多，检索噪声越大，答案越容易混杂不同版本的内容。更稳妥的方式是先接入一个小而干净的集合，验证之后再扩展。关于知识库搭建中的常见问题，可以参考[企业RAG知识库怎么建？2027年避开五个常见误区](https://doc.duaer.com/zh/guides/enterprise-rag-knowledge-base/)。

第三种误区是没有评测集就开始上线。如果没有一组固定的问题和标准答案，团队就无法判断一次改动到底是变好了还是变坏了，争论往往停留在印象层面。

## 怎么衡量与本周可做的一件事

衡量RAG案例需要多个视角。检索层面，关注的是正确文档是否出现在检索结果的前列；生成层面，关注答案是否忠实于所引用的原文；可追溯层面，关注每个关键结论能否定位到具体段落；业务层面，关注员工查找信息的平均耗时是否下降，以及人工复核的工作量是否随时间减少。

这里不需要套用任何外部数字，关键在于建立自己的基线。上线前先记录人工查找的平均耗时和错误情况，上线后用同样的口径对比。如果一段时间后使用频次上升，但人工复核量并没有下降，说明系统还没有真正替代工作，而是增加了一道核对环节，这需要回头检查资料质量和评测集的覆盖面。

如果只能做一件事，建议是：从你所在部门的真实工作群、工单或邮件里，挑出30个员工最近真正问过的问题，逐一记录它们对应的文档出处，并标注这些文档是否是当前有效版本。这个动作不需要任何新工具，却能立刻告诉你三件事：哪些问题有明确来源，哪些资料存在版本混乱，哪个场景最适合作为第一个试点。拿到这份清单后，再去对照前面的排序方法，第一个案例的选择通常会变得清楚很多。

如果你手头已经有这份问题清单，接下来可以把它和候选文档一起放进 Duaer 试一试，直接检验RAG在你自己的资料上能答到什么程度。欢迎到 https://www.duaer.com 注册试用，用你们真实的问题来决定下一步怎么走，而不是依赖任何人的演示。

企业RAG案例的价值，不在于它展示了多少技术，而在于它能否在一个边界清楚的场景里，稳定地回答真实的问题。

## 常见问题

### 企业做RAG，第一个试点应该选哪类场景？

通常建议从制度与流程问答开始。这类资料边界清楚、更新频率低、问题高度重复，且答错时便于人工对照原文核实。合同条款检索价值高，但对权限、审计和复核的要求更高，一般放在后续阶段。

### 怎样判断RAG试点是否有效？

先在上线前记录人工查找的平均耗时和错误情况作为基线，上线后用同样口径对比。同时看检索层面正确文档是否排在前列、答案是否忠实于原文、关键结论能否追溯到具体段落。如果使用频次上升而人工复核量没有下降，说明系统还没有真正替代工作。

### 没有评测集可以直接上线RAG吗？

不建议。没有一组固定的问题和标准答案，团队就无法判断一次改动是变好还是变坏，讨论容易停留在印象层面。可以先从部门真实工作群、工单或邮件中整理一批员工真正问过的问题，逐一记录文档出处并标注版本是否有效，以此作为评测的起点。