企业 AI 应用常见问题

适合的通常有三个特征：有大量文字或表格需要人去看、判断规则相对明确、结果可以被检查。比如资料查找、字段抽取、材料预审、记录整理和重复问答。不适合的包括：需要承担法定或专业责任的判断、直接控制设备或生产、错一次代价极高且无法人工复核的环节。还有一类容易被忽略——流程本身还没理清、每个人做法都不一样的事情。这种情况要先理流程，不是先上 AI，否则只是把混乱自动化。

知识库是把文档整理成可检索、有版本、有权限的资料；RAG 是回答问题时先从知识库里找出相关原文，再让模型基于这些原文作答，好处是结论能追溯到出处；Agent 是在一条工作流里连续做多步——检索、抽取、校验、调用接口、生成草稿，并把有后果的动作交回给人。三者是递进关系：没有可靠的知识库，RAG 的引用就不可信；没有可验收的 RAG，Agent 只是把错误自动化得更快。

不必须，而且我们不建议一开始就买。PoC 阶段可以用按量 API、租赁算力或客户已有的环境，几天到几周就能在脱敏样本上跑通一个流程。只有当数据不能出域、并发或时延有硬性要求、或者长期调用量算下来本地更划算时，才值得讨论本地硬件。这个判断应该由 PoC 的实际数据触发，而不是作为起点——先买硬件再找场景，是我们见过最贵的做法。

可以。我们的调用层把业务逻辑和具体模型分开，公有 API、开源模型和国产模型可以替换和对比。选哪个由评测决定：在同一套固定样本上比效果、时延和成本，把结果给客户看，而不是先定品牌再补理由。如果客户有信创目录、采购清单或数据出域方面的要求，以客户的要求为准。

取决于对方系统开放什么。我们的首选顺序是：先用导入导出或数据库只读视图做"侧车"，验证这件事有没有价值；确认有价值之后再谈接口对接和写入。我们不建议在没有验证前就要求打通生产系统——那会把一个几周的验证变成几个月的集成项目，失败成本也高得多。封闭系统只能先做离线导入导出，这一点需要在 PoC 方案里写清楚。

不会。未经书面授权，客户数据不用于模型训练，也不跨客户复用。PoC 阶段我们只请求完成该流程必需的、脱敏的最小样本，并在合同里约定使用范围、留存期限和删除或返还方式。使用外部模型 API 时，数据出域的范围需要客户事先确认；不同意出域的部分走私有云或本地部署路线。

主要靠三件事，而不是靠换一个更大的模型。一是所有结论必须给出原文引用，"答案能不能被引用支持"是可以逐条检查的；二是证据不足或文件冲突时拒答并转人工，而不是硬答一个看起来合理的结果；三是用固定样本持续测引用正确性、答案支持率和拒答率，错误案例逐条复盘。此外，高风险结论一律进入人工确认环节——这些措施用于降低幻觉和漏检风险，不能保证所有错误都被发现或阻断；仍需在限定样本上评测，并由责任人复核。

按角色和数据域两个维度控制：谁能看哪些文档、哪些字段、哪个组织范围的记录。关键是在检索阶段就过滤，而不是先检索再遮挡结果——后者在提示词层面很容易被绕过。PoC 里会用不同角色的账号做交叉越权测试，越权读取必须为零；所有访问、修改和导出都留日志备查。

在开始前就把验收表写清楚：固定测试集、人工基线、要测哪些指标、阈值是多少、谁是验收人。过程中每周由业务负责人看真实的失败样本，不是只看成功演示。结束时给出逐项指标、错误清单和是否通过的结论。阈值由客户在自己的样本上确认，我们不预设成绩，也不把"演示成功"当作通过。PoC 通过只证明限定数据和限定流程内可行，不等于全场景验收。

可以评估。内网部署需要客户提供服务器或云资源、网络策略、账号和运维窗口，并通过客户的安全评审。需要如实说明的是：内网部署会带来采购、机房、运维和折旧成本，可选的模型能力也可能与最新的公有 API 有差距。我们会把这些成本和差距列清楚，由客户在知情的前提下决定，而不是默认推荐本地部署。

按合同约定，通常是：客户数据和客户知识库里的内容始终归客户；定制开发的代码和交付文档按合同归属，一般归客户，我们会交付源代码和技术文档；第三方模型和开源组件按各自的授权条款使用，我们在交付时列出组件清单和许可证。我们不会把客户的数据或知识库内容当作自己的资产复用到其他项目。

在界面上区分哪些是模型生成、哪些是原文引用、哪些是人工确认过的内容，并记录生成时间、使用的模型版本和知识库版本。对外发布或需要归档的材料，由确认人签署后再输出。如果最终的服务形态涉及面向公众提供生成内容，还需要按当时适用的规定评估标识和其他合规要求——这部分会在部署前与客户共同确认。

凡是可能造成人身安全、生产中断、资金损失、法律责任或对外承诺的环节，都必须有人工责任人：安全风险定级和隐患关闭、设备检修方案和操作步骤、对外发文和材料签署、涉及金额与合同条款的判断，以及任何写入生产系统的动作。AI 在这些环节只做检索、整理和草稿，最终结论和责任在人。这一点会写进合同，不是可选项。