C.1先把四个最容易混淆的区分立起来
这一节的内容,几乎覆盖了企业 AI 落地中最常见的四种误解。企业在内部推进时踩的坑,八成来自这里。
区分一:统一表征 ≠ 统一训练目标
很多人以为"广告/企业数据无法像多模态那样统一"——这个说法是错的。统一表征其实有三层:
| 层次 | 做什么 | 广告/企业数据能否做到 |
| ① 模态内编码 | 把每种东西变成向量(文本编码器、ID 查表、数值分桶) | ✅ 能 |
| ② 跨模态对齐 | 让不同类型的东西在同一空间可比(如双塔模型) | ✅ 也能 |
| ③ 统一预训练目标 | 用哪一个自监督任务训练整个空间 | ❌ 卡在这里 |
真正的门槛在第三层。语言有序列结构(预测下一个词)、图像有空间结构(还原加噪图)、图文对有配对结构(判断是否匹配)——这三个任务都是从数据自身结构里"长出来"的;而广告数据是人为拼接的字段,没有内在结构,任务必须由人来设计。
2024 年的一个重要进展:HSTU/GEM 这类工作把推荐/广告重构成"序列生成"问题——把用户行为历史当成一句话,预测下一个行为。一旦任务成型,Scaling Law 就在推荐场景生效了。
这说明"第三层"并非不可逾越,只是需要有人先把任务设计出来。
区分二:训练 embedding 模型 ≠ 使用 embedding 模型
这是企业侧最常见的误解——以为要用自己的数据"训练"一个向量模型。
| 训练(大厂做) | 使用(企业做) |
| 谁做 | OpenAI / 智源 / 各模型公司 | 任何有数据的企业 |
| 数据 | 海量公开数据(网页、图文对、代码) | 自己的 CRM / 工单 / 文档 |
| 方法 | 自监督训练(对比学习 / 掩码预测) | 调用模型做推理(参数一动不动) |
| 需要 | 成千上万 GPU 小时 | 一台普通服务器,甚至 CPU |
| 产出 | 一个通用的 embedding 模型 | 一堆向量(存进向量库) |
两者成本差 4–5 个数量级——所以绝大多数企业只做"使用"。只有当领域词汇极其特殊(医疗、法律、工业术语)时,才值得用自己的数据微调。
区分三:RAG 提供"事实",不是"教规则"
图 2 RAG vs 微调:提供事实 与 教会能力
- RAG:把相关文档片段塞进这一次提问的上下文。查完了就完了,模型什么都没记住——像允许带书进考场。
- 微调:用大量样本训练,永久改变模型参数,让它学会某种模式——像反复刷题练成肌肉记忆。
- "举一反三"是 LLM 自带的能力(预训练就有了),不是 RAG 教的。RAG 的贡献只是:确保它这次手里有正确的材料。
区分四:embedding 懂"语义",不懂"业务"
图 1 embedding 的能力边界:懂语义,不懂业务事实
这一个区分解决了最常见的疑问:"预训练没见过我们公司的数据,它怎么能答得出来?"
| 角色 | 职责 | 需要懂什么 | 类比 |
| embedding 模型 | 把每段文字编码成向量,让意思相近的靠近 | 只懂通用语言规律 | 图书馆的索引系统 |
| 向量数据库 | 存储 + 按相似度检索 | 什么都不用懂 | 书架 |
| LLM | 读完检索出的原文,回答问题 | 通用理解力 + 当次材料 | 请个聪明人读完这几本书再回答 |
所以"预训练里没有企业数据"根本不构成障碍:索引系统不需要读过贵公司的书就能建索引,它只要会判断"这两段文字说的是不是一回事"。
至于"我们的退款政策是 7 天还是 15 天"——这个事实存放在文档里、被检索出来、由 LLM 读给你听。业务知识从来不在 embedding 里。
C.2向量数据库到底怎么工作
这是最容易讲混的一环,把它拆成五步就清楚了:
| 步骤 | 谁做 | 做什么 |
| ① 训练模型 | 大厂 / 研究机构 | 用海量公开数据自监督训练通用 embedding 模型(BGE、OpenAI text-embedding、CLIP) |
| ② 编码数据 | 企业 | 拿现成模型,把自己的数据(先文本化、再分块)一条条编码成向量——这是推理,不是训练 |
| ③ 存入库 | 企业 | 存(向量 + 原文 + 元数据)到向量库(Milvus / Qdrant / pgvector) |
| ④ 检索 | 系统 | 用户提问 → 同样编码成向量 → 找最相似的 N 条 |
| ⑤ 生成 | LLM | 把检索结果作为上下文,生成答案。这就是 RAG。 |
一个技术细节值得注意:结构化数据(CRM 字段、订单表)通常要先"文本化"再编码——把一行记录写成"客户张先生,32 岁,2025 年 3 月购买过 A 产品……",再送进 embedding 模型。
也有专门处理表格的模型,但主流做法仍是"先转成自然语言"。
C.3为什么不能"直接把资料全给模型"
这是一个特别自然的疑问:既然 LLM 能理解,为什么不把资料全部上传、让它自己去查?
图 1 为什么必须检索:数据量与可读量的数量级鸿沟
| 约束 | 数字对比 | 后果 |
| 容量 | 中型企业资料约 10 亿字;最先进模型一次最多读约 100 万字 | 差 1000 倍,物理上塞不进去 |
| 成本 | 全量读取按 token 计费,单次约数万元 | 用户一天问几百次,账算不过来 |
| 速度 | 全量读取需几十分钟 | 向量检索只需百毫秒 |
一句话:向量化的本质不是"让模型更好地理解",而是"先从 10 亿字里筛出 3 段"。它是筛选机制,不是理解方式。
类比:不用检索 = 你问律师一个合同问题,他把律所 50 万份卷宗全搬来让你自己找;用检索 = 管理员先挑出 5 本最相关的、翻开关键几页给你。
但要承认:资料少的时候,你的直觉是对的。
- 只有 20 份文档、合计 5 万字 → 直接全塞进去反而更准(少一层信息损失)
- 每次只针对单一文件提问("帮我总结这份合同")→ 上传单个文件即可
- 但要跨几十万份资料问答(企业知识库、客服助手)→ 必须先检索
图 2 三种方案对比:全文塞入 / 关键词 / 向量检索
为什么不用关键词搜索?因为用户问"为什么我的接口老是失败",文档里写的是"请求频率超限返回 429"——字面上没有任何共同词,关键词永远匹配不上,只有语义检索能建立关联。
C.4企业的三个关键选择
下面用一个真实场景把三个选择串起来:某企业软件公司,要把 3 年积累的客服工单 + 产品文档 + 销售合同,做成一个内部 AI 助手(客服和销售都能用)。
选择一 · 选模型:通用还是领域微调
| 选项 | 做法 | 结果 |
| A. 通用模型 |
直接拿来用,零成本 |
常规问题够用;但会把「API 限流」和「接口响应慢」判为高度相似——而这是两个完全不同的问题(一个是频率超限返回 429,一个是性能问题) |
| B. 领域微调 |
用 5000 条真实工单做对比学习:同一问题的不同问法拉近,不同问题推远 |
能区分专业术语的细微差别;但需要标注数据与一次训练成本 |
现实做法:先用通用模型跑并测量准确率;只有当业务方反馈"AI 老是答错方向"、且确认是术语混淆时,再针对性微调。不要一上来就微调。
选择二 · 切分策略
图 3 切分策略:切太碎丢上下文,切太大混主题
| 数据类型 | 建议切法 | 原因 |
| 产品文档(结构清晰) | 按小节切(500–800 字),每块开头重复标题路径 | 主题单一,且保留"这段话从哪来" |
| 客服工单(问题+过程+结论) | 整条工单不切 | 解决方案脱离问题描述就失去意义 |
| 销售合同(长、条款化) | 按条款切,元数据记合同号与签署方 | 用户通常问某一条,不是整份 |
选择三 · 元数据设计(最容易被忽略、却最影响可用性)
| 字段 | 对应哪类提问 |
source_type(工单/文档/合同) | "只在产品文档里找""看看合同怎么约定的" |
created_at(时间) | "上个月报的问题"——语义检索无法表达时间范围 |
customer_id(客户) | "XX 客户的问题"——同样是结构化约束 |
department / owner(归属) | 权限控制:销售只能看自己负责的客户 |
product_version(版本) | "v2.0 的行为"与"v3.0"答案不同,混在一起会答错 |
severity(严重程度) | "有没有类似的严重故障" |
C.5一次真实检索的完整过程
图 4 一次真实检索:元数据过滤 → 向量检索 → 拼装 → 生成
这个例子最能说明元数据的价值。用户问"XX 客户上个月报的登录问题怎么解决的"——这里面「XX 客户」和「上个月」是结构化约束,「登录问题」才是语义内容。
向量检索只能处理后者。如果不做元数据过滤,系统会返回一堆来自不同客户、不同时间的相似工单,LLM 很可能把别人的方案当成这个客户的答案——在企业场景里,这就是事故。
权限走的是同一条路:销售问问题时,在过滤阶段就加上"只能看我负责的客户",而不是靠提示词去"请求模型保密"。
这是企业级与消费级最本质的差别之一:安全必须做在检索层,不能寄托于模型的自律。
C.6五层落地门槛:为什么"技术门槛低"是错觉
图 3 企业级 AI 落地的五层漏斗:越往下越难,且都与"模型能力"无关
| 门槛 | 现实情况 | 为什么难 |
| ① 数据治理 | 数据散在几十个系统里(CRM、ERP、工单、邮件、网盘、IM),大部分非结构化、脏、无元数据 | 做好 RAG 约 80% 工作量在"把数据收拾干净"——这跟 AI 无关,是苦活 |
| ② 权限合规 | 销售能看客户信息、HR 不能;某区域合同其他区域不能看 | 检索必须带权限过滤,否则出现"实习生靠 AI 查到 CEO 薪酬"。这是监管红线 |
| ③ 效果评测 | 怎么知道答得对?依据是哪份文件?出错能否回滚? | 没有评测体系,企业不敢把流程交给 AI |
| ④ 从问答到执行 | 问答是"给信息、人决策";执行是"AI 直接调系统改数据" | 错误不可逆。所以现实形态是"AI 建议 + 人工确认",而非全自动 |
| ⑤ 成本与 ROI | 每次查询 = 向量检索 + LLM 推理,大企业日均几十万次 | ROI 算不过来,项目就停在试点——这是 2024–2026 年大量 POC 止步的直接原因 |
C.7为什么消费级已经普及,企业级还没跑起来
图 4 消费级 vs 企业级:五个维度的结构性差异
一句话:技术门槛低 ≠ 落地门槛低。
· 做一个能演示的 RAG 系统:一周
· 做一个能在 1000 人企业里安全运行、权限正确、效果可评测、成本可控的系统:一年以上,且需要 IT / 法务 / 合规 / 业务多部门协作
用本书的信号框架再看一遍
| 信号维度 | 企业级 Agent 的处境 |
| 信号源 | 数据脏、散、缺标签 → 信号质量差 |
| 反馈速度 | 出错几周才发现,且难归因 → 闭环极长 |
| 试错成本 | 不能拿真实业务做实验 → 不可模拟 |
| 偏差 | 只看得到"用过的场景" → 选择偏差 |
结论:企业级 Agent 的瓶颈从来不在"模型不够聪明"。
真正的破局点在三处——数据基础设施(把脏数据变干净)、权限体系(让 AI 能安全地看数据)、评测工具(让效果可验证)。
这三样才值得关注:因为模型能力每年都在涨,而这三块基础设施,涨得很慢。
C.8一页速查:判断一个企业 AI 项目的六个问题
| 问题 | 为什么问 | 危险信号 |
| ① 数据现在存放在哪几个系统里? | 数据源数量直接决定治理成本 | 回答"很多地方都有"——意味着 80% 的活还没开始 |
| ② 谁有权看哪些数据?规则写在哪? | 权限方案决定系统能否合规上线 | "我们打算靠提示词让模型保密"——红线 |
| ③ 效果由谁评测?标准是什么? | 没有评测就没有信任,没有信任就没有规模化 | "先上线看看效果"——通常意味着不会被真正采用 |
| ④ 它的输出是"给人看"还是"直接执行"? | 后者风险高一个量级 | 一开始就做全自动执行——建议先做"建议 + 确认" |
| ⑤ 每次查询的成本是多少? | 决定 ROI 是否成立 | 说不清单次成本——大概率没算过账 |
| ⑥ 用的是通用模型还是领域微调? | 判断技术路线是否匹配场景 | 一上来就微调——通常是被术语问题误导 |
最后一句:大模型是"理解引擎",向量检索是"检索引擎"——两者不是替代关系,而是分工关系。
理解引擎再强,也解决不了"材料太多、一次读不完";检索引擎再准,也看不懂材料的意思。
企业级 AI 的工程本质,就是把这两个引擎接起来,再加上权限与评测这两道护栏。
TOUGE RESEARCH
关注公众号,追更深度研究
每两周一期长报告:把一个行业的来龙去脉、商业模式与竞争格局讲透。只写能落到判断上的内容。
长按识别二维码关注