ai大模型下 如何应用于自己的企业数据

你手上有一堆公司内部文档、工单、报表，想让大模型直接回答「这批货为什么延期」「这份合同的付款条款是什么」，结果发现模型没读过这些东西，直接问就是编。这篇不讲模型哪个强，只讲把自有数据接进去的落地顺序：先判断你的问题属于哪一类，再决定走检索、微调还是纯提示，最后把显存、许可证和验收口径定下来。

你手上有一堆公司内部文档、工单、报表，想让大模型直接回答「这批货为什么延期」「这份合同的付款条款是什么」，结果发现模型没读过这些东西，直接问就是编。问题不在模型笨，而在你没把数据接进去。这篇不讲模型哪个强，只讲落地顺序：先判断你的问题属于哪一类，再决定走检索、微调还是纯提示，最后把显存、许可证和验收口径定下来。

整个链路其实就是四步，顺序错了会白折腾。很多人一上来就想微调，结果数据一改就得重训，成本全砸在水里。先把任务分清楚，再选技术路线，然后处理数据切片，最后算账和定验收标准。下面按这四步拆开讲，每步都给你可执行的动作和判断标准。

第一步：先分清你的问题属于哪一类

企业内部的需求五花八门，但落到大模型能接的部分，基本就三类：查事实、做归纳、做判断。查事实是「文档里写了什么」，做归纳是「多份材料汇总口径」，做判断是「要不要批这笔款」。前两类适合把数据喂进上下文或走检索，第三类得靠人定规则，模型只能做初筛。

• 判断标准：如果这个问题人工翻文档五分钟能答出来，就适合做检索问答；如果答案取决于公司没写下来的惯例，先别接模型，先把惯例写下来。
• 不适用的情况：数据本身没有结构化归口、同一件事在不同文档里口径冲突时，先做数据治理，接模型只会把矛盾放大。
• 查事实类优先走向量检索加重排，因为要能追溯来源；做归纳类先量一下你的材料总长度，超出上下文窗口就得分段处理。

第二步：检索、微调、提示词三选一，别三个一起上

技术路线没有优劣，只有匹配。检索适合知识常更新、要求给出来源的场景；微调适合固定输出格式和固定语气；提示词负责约束回答结构，不负责灌知识。三条路一起上是最常见的浪费，先试一条，不行再换。

1. 先搭最小检索链路拿一批真实文档跑通切片、嵌入、召回，验证召回内容对不对。召回错了就别调提示词，先修切片和嵌入模型。
2. 再看模型有没有照着答在系统提示里写清「只依据检索到的片段回答、找不到就说找不到」，抽几个问题看它会不会编。
3. 最后才考虑微调只有当输出格式反复调不稳、或者话术风格要求很严时，再上微调，并且想清楚数据多久会变一次。

排查顺序很关键：先看检索召回的内容对不对，再看模型有没有照着答。很多人一看到答案不对就去改提示词，结果召回本身就是错的，改半天没用。把这两层分开看，定位问题会快很多。

第三步：数据准备与切片，这一步决定后面好不好用

切片方式直接决定检索质量。按「一个问题一个片段」的思路切，而不是按字数硬切。表格、合同条款、操作手册的切法完全不同，表格建议整表保留并附带表头说明，不然模型看到一堆数字不知道哪列是哪列。每个片段都要带上来源标识，用户才能核对。

• 片段带上文件名、章节、更新日期，回答时一并返回，没有来源的答案在企业里基本没人敢用。
• 敏感数据先本地脱敏再入库，权限按人分：能看财务数据的人和有权限问财务数据的人要能对上。
• 扫描件或图片先过 OCR 再入库，识别错的字会一路带进答案里，后面很难排查。
• 同一份文档里口径冲突的地方先标出来，别让检索随机命中其中一条，那样答案会飘。

第四步：算力、许可证与上线前的验收口径

到这一步，技术路线和数据都差不多定了，该算账了。先按检索片段总长度和并发量估显存与吞吐，具体数字到 /models/deploy 用部署测算对一遍，再到 /compute/sizing 按模型算卡数，别凭感觉买卡。许可证要单独看：模型权重的授权范围、是否允许商用、衍生模型怎么算，到 /open-weight-license-basics 确认边界，别只看「开源」两个字。

验收口径

上线前抽一批真实问题做对照，看答对率、答错时是否暴露「不知道」、能不能点回原文

成本口径

把检索、嵌入、生成三段分开记，到 /tools/model-cost-calculator 折算，避免只盯生成那一段

权限口径

回答里出现的数据，提问的人本身有没有权限看，这条要在上线前跑一遍

上线前的验收标准最好在上线前就写下来。抽一批真实问题做对照，重点看三件事：答对率、答错时会不会老实说不知道、答案能不能点回原文。没有这套口径，上线后你没办法判断系统是好是坏，只能靠感觉吵架。成本也一样，检索、嵌入、生成三段分开记，到站内工具页面核对当时的数字，单看生成那一段容易低估。