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