过去两年我们接触的需求里，有相当一部分在评估阶段就建议客户先不要做——不是技术上做不了，而是投入产出不成立，或者前置条件（数据、流程、责任划分）还没准备好。把这件事写在最前面，比在 PoC 结束后再解释更负责任。
一个基本判断标准：这项工作现在是不是由人在做、做得慢、且答案有据可查？三个条件同时成立，AI 才有明确价值；缺一个，就需要重新讨论方案。
每一类都按"输入什么—系统给出什么—人在哪里介入"来定义，而不是按技术名词来定义。
制度文件、作业指导书、标准与方法规范、设备手册、历史项目资料、会议纪要，含 PDF、Word、Excel、扫描件。
自然语言提问，返回直接答案 + 引用段落 + 文件名与版本 + 页码定位，可一键跳转原文核对；命中不足时明确回答"知识库中未找到依据"，而不是编造。
格式相近但排版不统一的业务单据：提单与发票、检测原始记录、病历文本、合同、报关与报检材料。
按字段抽取为结构化数据并回写到业务系统，逐字段标注置信度与来源位置；对低置信字段和前后矛盾项主动挂起，形成待人工确认清单。
已有系统中的一次业务事件：一条工单、一份委托、一次异常记录、一封邮件。
按预设规则完成受限动作：生成报告初稿、跨系统取数并交叉核对、按条件提醒相关人、拟写回复草稿并挂到审批流。每个动作可调用的接口范围是白名单式的。
这三类可以单独实施，也可以叠加在同一个项目里。多数客户从第一类或第二类切入，跑顺之后再考虑第三类——智能体的风险在于它会"动手"，前两类只是"给答案"。
直接把文档丢给大模型问答，在正式业务里几乎一定会翻车。下面这条流水线上的每一个环节，都对应一类具体的失败模式。
上图为标准处理链路。实际项目中，01 和 02 的工作量通常占整体的六成以上——决定效果上限的是文档处理质量，不是模型选型。
| 环节 | 不做或做不好会出现什么 | 我们的处理方式 |
|---|---|---|
| 01 文档解析 | 跨页表格被打散、双栏 PDF 串行、扫描件识别错行，导致后面所有环节都在错误内容上运行。 | 按文档类型分别配置解析策略；表格结构单独还原并保留行列关系；扫描件先做质量分级，低质量件走人工补录而不是硬识别。解析结果抽样人工校验后才入库。 |
| 02 切分与元数据 | 按固定字数切分会把一条完整条款切成两半，检索出来的片段缺少前提条件，答案在字面上正确、在业务上是错的。 | 按条款、章节、记录单元等业务边界切分；每个片段附带来源文件、版本号、生效日期、适用范围和密级，供检索时过滤与在答案里回显。 |
| 03 混合检索 | 只用向量检索时，对编号、型号、标准号、人名这类专有符号召回极不稳定（"HJ 505" 与 "HJ 605" 语义几乎相同）。 | 向量检索与关键词检索并行后合并；权限过滤在检索阶段前置执行，越权文档从候选集里直接排除，而不是生成后再屏蔽。 |
| 04 重排序 | 召回的十几个片段里只有两三个真正相关，全部塞给模型会稀释注意力，答案开始跑偏。 | 用重排序模型对候选片段精排，只保留高相关片段进入上下文；按 token 预算裁剪，保证长文档场景下上下文不溢出。 |
| 05 生成与约束 | 模型在没有依据时倾向于"编一个看起来合理的答案"，这是业务场景里最危险的一类错误。 | 提示词层面强制"仅依据给定片段作答"；答案与引用做一致性校验；检索置信度低于阈值时直接返回"未找到依据"并给出相近文档线索，把不确定性交还给人。 |
| 06 评估与回归 | 换个模型、改个提示词、加一批文档，效果可能整体下滑，但没人发现，直到业务部门投诉。 | 上线前与业务方共同构建评估问题集并记录基线；任何模型、提示词、知识库变更后重跑评估集，对比基线；线上 Bad case 定期回流补入评估集。 |
"准确率 95%" 这种说法在没有定义题目范围之前没有意义。我们用一组可以在您自己数据上复现的指标来验收。
| 指标 | 含义 | 怎么用 |
|---|---|---|
| 检索命中率 | 正确依据是否出现在检索返回的前 N 个片段中。 | 这是效果的上限。检索没召回，后面再强的模型也答不对。优先优化这一项。 |
| 答案有据率 | 答案中的关键结论是否都能在引用片段里找到对应原文。 | 直接对应"会不会胡说"。低于约定值不予验收。 |
| 合理拒答率 | 知识库中确实没有依据时，系统明确说明"未找到"的比例。 | 刻意在评估集里放入超纲问题。一个从不拒答的系统是不可信的。 |
| 字段抽取准确率 | 文档处理场景下，按字段统计的抽取正确比例，分关键字段与一般字段。 | 关键字段（金额、批号、结果值）单独统计，标准高于一般字段。 |
| 人工复核工作量 | 引入系统后，同样一批业务需要人工确认的条目数与耗时。 | 真正的业务收益指标。它比任何模型分数都更能说明系统是否值得留下。 |
| 响应时间 | 在约定并发下的首字返回时间与完整回答时间。 | 按实际部署硬件实测，不引用厂商标称值。 |
区分现成能力、需评估能力和后续方向，避免把规划内容当作交付承诺。
以下能力已有可运行实现，具体配置与交付边界以合同及演示确认为准。
以下内容不作为默认现成功能，需在需求与技术评估阶段逐项确认。
当前不作为现有功能承诺；如项目有明确需求，可在需求阶段确认实现条件与范围。
"私有化"有几种不同程度，对应的数据边界、成本结构完全不同，需要先对齐概念再谈方案。
| 形态 | 数据边界 | 成本结构 | 适用情况 |
|---|---|---|---|
| 公有云模型 API | 提问内容与命中片段会发送至模型服务商；知识库原文可保留在本地，仅传输片段。 | 无硬件投入，按调用量计费，用量波动直接反映在账单上。 | 数据敏感度不高、希望快速验证效果、用量不确定的起步阶段。优先选用已完成备案或登记的国产模型服务。 |
| 专属云 / 私有云 | 模型运行在客户专属实例或客户自有云账号内，不与其他租户共享。 | 实例常驻费用为主，成本相对可预测。 | 已有云上业务系统、要求数据不出自有云账号、但暂不打算自购硬件。 |
| 本地 GPU 部署 | 模型权重与全部数据均在客户机房或内网，可完全离线运行。 | 一次性硬件投入 + 电力与运维成本，长期用量大时单位成本更低。 | 数据不允许出内网、有机房与运维条件、并发和用量稳定可预估的场景。 |
| 模型规模 | 显存参考（4bit 量化） | 说明 |
|---|---|---|
| 7B 级 | 约 6—10 GB | 单张消费级或入门专业卡即可运行。适合结构化抽取、分类、摘要等边界清晰的任务。 |
| 14B 级 | 约 10—16 GB | 知识库问答的常见起点，在多数中文业务问答上表现与成本较平衡。 |
| 32B 级 | 约 20—28 GB | 需要较强推理与长上下文的场景。通常需要专业计算卡。 |
| 70B 及以上 | 约 40 GB 起，常需多卡 | 成本显著上升。多数企业场景不必上到这一档，把预算投在文档处理和检索优化上收益更高。 |
以上为选型阶段的参考量级，用于判断预算区间，不是采购依据。实际显存占用还受上下文长度、并发数、KV 缓存和量化方式影响，最终配置以在贵司真实并发条件下实测为准。嵌入模型与重排序模型另需少量显存，通常可与主模型共卡。
我们的客户集中在检测、制药、医疗器械、医疗和安全生产领域，这些行业里 AI 不是"能不能用"的问题，而是"以什么身份用"的问题。
验收标准在 PoC 之前就写清楚，而不是等系统做完再讨论算不算达标。
圈定 1—2 个场景，清点文档数量、格式与质量，确认数据密级与责任人。产出可行性判断与不建议做的部分。
与业务方共同出题建立评估集并约定通过线，用真实（脱敏）数据跑通链路，给出基线数据。不达标则终止或调整范围。
补齐权限、日志、管理后台与增量更新机制，完成与业务系统的接口对接和部署环境搭建。
与原有人工方式并行一段时间，比对差异、回流 Bad case，培训维护人员后正式移交。
不在官网标价——同样一句"做个知识库"，不同的文档量、接口和部署方式，造价可以差好几倍。这里说明的是钱花在哪些项上。
项目建设期发生，与实施范围直接相关。
上线后按年度或按量发生。
影响造价的主要变量：文档总量与格式复杂度（扫描件比例尤其关键）、需要对接的系统数量、部署形态、并发规模、是否需要验证文档、以及人工复核流程的改造深度。我们会在评估阶段给出分项估算，而不是先报一个总价再谈范围。
不是产品演示会，是一次针对贵司具体流程的可行性讨论。带上您手头最耗时的那件事，我们一起判断它适不适合用 AI 解决。
以下信息能让第一次沟通直接进入实质讨论，没有也可以先聊。