企业官网建设流程全解析

开篇先聊一个我经常被问到的问题。很多刚接触大模型应用开发的朋友，一上来就把 LLM（大语言模型）和 Embedding（嵌入/向量化）混为一谈，觉得“让 AI 找资料”和“让 AI 回答问题”都是同一个模型在干活，买课学了一堆 RAG（检索增强生成）、Agent、知识库的概念，代码也能跑通，但你问他“为什么这一步用 Embedding 模型而不是调 ChatGPT API？”，他就卡住了。

这个问题的本质，在于没搞清楚 LLM 和 Embedding 虽然都长在“深度学习 + Transformer”这棵树上，但它们的训练目标、输入输出、能力边界和成本模型完全不同。一个是“会说话的百科全书”，另一个是“能把万物变成坐标的翻译官”。如果你正在做知识库问答、语义搜索、文本去重、Agent 工具调用，或者只是想搞明白 Dify、FastGPT 这类平台里那一堆模型配置到底该怎么选，这篇文章就是帮你把这两个概念彻底掰开揉碎。我会从原理差异讲到真实项目里的分工配合，最后再给你一份我用过好几次的选型心法和避坑清单，照着抄就行。

1. 别急着对比，先把两个概念各自是什么说清楚

很多文章一上来就列对比表格，但如果你没搞懂这两个东西各自在解决什么问题，表格背下来也白搭。我先用最直白的方式把它们的“人设”立起来。

1.1 LLM：靠“预测下一句话”练出来的全能选手

LLM 全称 Large Language Model，主流结构是 decoder-only 的 Transformer，代表如 GPT 系列、Qwen、Llama、DeepSeek 等。它的核心训练目标非常纯粹：给定前文，预测下一个词的概率分布。训练数据是全网级别的文本，经过预训练（Pre-training）阶段，模型从海量文本里学到了语法、事实知识、推理模式、代码逻辑，甚至一定程度上的“性格”。

你可以这样理解：LLM 是一个读过几万亿字的海量书籍、代码、论文、论坛帖子的人。你问它问题，它靠的不是“查数据库”，而是根据当前对话上下文，一个词一个词地“续写”出最合理的回复。这个“续写”的参数量巨大，通常从几十亿到几千亿不等，推理时需要把全部参数和中间激活值放进显存里计算，所以它对硬件的要求很高，单次调用成本也不低。

在实际开发里，LLM 承担的是“最后一步的理解和生成”。比如用户问“帮我总结一下这份合同的赔付条款”，真正干活的必须是 LLM，因为它要读懂合同语义、提取关键信息、组织语言输出。Embedding 模型做不到这件事，它最多能告诉你“这段话和另一段话像不像”。

1.2 Embedding：把文本、图片、音视频都变成一串数字坐标

Embedding（嵌入/向量化）的本质，是一个“编码器”。你把一句话、一段代码、一张图片甚至一条用户行为序列丢进去，它输出一个固定长度的向量（如 1024 维的浮点数数组）。这个向量就是该输入的“语义指纹”。

为什么要有这个东西？因为计算机不认识文字，只认识数字。而普通的 One-Hot 编码把每个词当成一个独立 ID，完全没有语义关联（“苹果”和“水果”是两个毫无关系的稀疏向量）。Embedding 模型通过训练，把语义相近的输入映射到向量空间里距离相近的位置。比如“今天天气怎么样”和“北京今天下雨吗”这两个句子，虽然字面完全不同，但它们在向量空间里的夹角（余弦距离）会非常小，代表“语义相似”。

这里要特别强调一个容易误解的点：Embedding 模型输出的向量本身不包含“自然语言答案”。它是一个纯粹的数学坐标。它回答的问题是“这两个东西像不像”、“这个东西属于哪一类”，而 LLM 回答的是“根据这些东西，请你生成一段人话”。这两个能力在真实系统里是互补关系，不是替代关系。

1.3 一个比喻让你记住核心差异

如果非要用一句话记忆：

• LLM 是演员，能根据剧本（Prompt）临场发挥、写出新台词。
• Embedding 是图书管理员，能在几十万本书里以极快的速度找出“可能相关”的几本递给你。

图书管理员递上来的书最终还是要交给演员来读、来总结、来回答，演员不可能自己去几十万本里一本本翻。这就是 RAG（检索增强生成）的基本分工。

2. 从技术指标对比，看清两者的“说明书”

概念层面理清后，我们从具体的技术维度拉个对照表。这份表我建议你收藏，无论是面试还是做技术选型，直接用得上。

2.1 训练目标对比：自回归 vs 对比学习

LLM 的核心 Objective 是自回归语言建模（Autoregressive Language Modeling），简单说就是最大化给定前文条件下下一个 Token 的概率。这个目标让模型被迫学会“语言长什么样”，包括语法、知识、逻辑、常识。这也是为什么它能“生成”，因为在预测下一个词的时候，它其实是在做选择，每个选择都建基于它对整个世界文本分布的理解。

Embedding 模型的训练目标则不同。主流的训练方式是“对比学习”（Contrastive Learning）。以经典的 Sentence-BERT 和后来大量基于 LLM 蒸馏的 Embedding 模型为例，训练数据通常是一对一对的（query，document），其中 document 可能是与 query 语义相关的正向样本，也可能是随机采样的负向样本。模型要学习的是：让正向样本对的向量距离更近，让负向样本对的向量距离更远。本质上，它在学“语义判别”，而不是“语言生成”。

这里有个很重要的推论：因为训练目标不是“生成语言”，Embedding 模型的参数量通常远小于 LLM，一般为几亿到几十亿级别（常见的 bge-m3 是 5.68 亿参数，OpenAI 的 text-embedding-3-large 官方没公布具体参数，但推理成本极低）。这也是为什么它跑得飞快、部署门槛低。

2.2 输入输出对比：Token 序列 vs 固定向量

LLM 的输入是一个 Token 序列（通过分词器把文本切成子词），输出也是一个 Token 序列（概率分布）。所以 LLM 可以处理任意变长输入，输出也是不定长的。它的上下文窗口（Context Window）是硬件和训练配置决定的，比如 8K、32K、128K。超出窗口的部分要么截断，要么通过滑动窗口、摘要等方式压缩。

Embedding 模型的输入也是 Token 序列，但输出是一个固定维度的向量。常见的有 256、512、768、1024、1536、3072 维度。维度越高，理论上能承载的信息容量越大，但存储和计算成本也更高。而且 Embedding 模型对输入长度通常有更严格的限制（如 512 或 8192 Token），超出会直接报错或截断，这点在知识库切块时特别要注意。

有了这个背景，你就能理解为什么 LLM 适合做生成类任务（总结、扩写、问答、代码），而 Embedding 适合做检索和匹配类任务（召回候选集、去重、聚类、分类特征）。

2.3 能力上限对比：可解释性 vs 模糊匹配

这一条最容易踩坑。很多人以为“Embedding 相似度等于语义理解”，大错特错。Embedding 模型学到的相似度是一种“语义近似度”，它擅长捕捉主题、领域、风格的相似性，但对逻辑推理、否定关系、反事实场景非常麻木。

举个例子：假设有以下三句话：

• A：猫在垫子上。
• B：垫子在猫下。
• C：猫把垫子掀翻了。

从 Embedding 相似度看，A 和 B 的向量距离可能比 A 和 C 更近，因为两者共享了“猫”、“垫子”、“在”这些字面 Token，但实际上 A 和 B 的空间关系完全相反，而 A 和 C 的场景更接近现实。这种“字面重合度高但语义逻辑不同”的案例，Embedding 模型极其容易搞混。相反，LLM 因为有更强的推理能力和上下文建模，能理解“在...上”和“在...下”的对立关系。

所以，如果你在做问答系统，千万别指望只靠 Embedding 做语义判断。正确姿势是：用 Embedding 做粗召回（从百万文本里筛选出 top 20 候选），再用 LLM 做精排和处理（真正回答问题）。

2.4 训练成本与部署形态对比

这一节直接关系到你钱包里的钱。

LLM（以 7B 模型为例）做 FP16 推理，光权重就占用约 14GB 显存，加上 KV Cache 和中间激活值，单卡 24GB 勉强能跑，部署成本高。每次推理生成 500 个 Token，在 A100 上可能耗时 2~5 秒。如果用 API（如 GPT-4、Claude、Qwen-Max），按 Token 计费，一次复杂对话成本可能在几毛钱到几块钱不等。

Embedding 模型就廉价得多。以 bge-m3 为例，它部署在 CPU 上都能快速跑（当然 GPU 更快），单卡可以同时服务几十路请求。向量化一万条文本，在普通 GPU 上也就几分钟的事。API 调用的话，OpenAI 的 text-embedding-3-small 每百万 Token 只要几毛钱，几乎是白菜价。

从系统架构的角度看，LLM 通常是“中心化的思考引擎”，数量少但贵；Embedding 则是“外围的索引工人”，量多但便宜。一套生产级的 RAG 系统，往往是一两个 LLM + 好几个不同用途的 Embedding/Rerank 模型配合工作的。

3. 在真实应用场景里拆解：谁在什么时候干活

很多人看了对比表还是懵，因为不知道什么时候该用什么。我用最常见的四个场景来拆解。

3.1 知识库问答系统（RAG）的两阶段流水线

这是目前最主流的大模型落地场景。整个流程可以拆成两个阶段：

阶段一：索引构建（离线阶段）。 这个阶段全程只涉及 Embedding，不涉及 LLM。你要把所有知识库文档做切块（Chunking），每一段变成一个文本块，然后调用 Embedding 模型把每个文本块变成向量，存进向量数据库（如 Milvus、Qdrant、pgvector）。这一步的目的是“提前把文档变成可以被快速搜索的坐标”。

阶段二：查询问答（在线阶段）。 用户提问后系统要做两件事。第一件是召回：把用户的问题同样用 Embedding 模型向量化，然后在向量数据库里通过 ANN（近似最近邻）算法找到最相似的 top K 文本块。这一步拼的是速度和召全率，LLM 太慢，干不了这活。第二件是生成：把用户问题连同召回的文本块一起拼成 Prompt，交给 LLM 阅读并生成答案。LLM 负责判断哪段文本真正有用、如何组织答案、如何应对信息不足。

所以你看，同样一个知识库系统，Embedding 负责“找资料”，LLM 负责“读资料 + 写答案”。如果你只用 LLM 不用 Embedding，会有什么问题？大模型上下文窗口有限，你不可能把整个知识库都塞进去。而且 Token 费贵得惊人。如果你只用 Embedding 不用 LLM，会有什么问题？你只能把用户问题映射到“最相似的文本块”，然后直接把原文返回给用户，这根本不算“问答”，顶多算“搜索”。

3.2 语义搜索与推荐系统：Embedding 的主场

如果你要基于 10 万条商品数据做“以文搜图”或者“相似文章推荐”，这场景里 LLM 基本帮不上忙。

一个典型的路径是：

1. 把每篇文章/商品的标题和描述，用 Embedding 模型向量化，存入向量库。
2. 用户输入搜索词，同样向量化，做 ANN 检索。
3. 根据返回的 top K，按业务规则排序展示。

这条流水线全部由 Embedding 完成。为什么不用 LLM？因为 LLM 做相似度计算不高效。你可以让 LLM “判断这两段话是否相似”，但你要么得每次把几十万候选两两塞给它看，要么得靠它做 fancy 的推理——成本极高、速度极慢、还会不稳定。用 Embedding 算一次余弦相似度是毫秒级甚至微秒级，用 LLM 是秒级。

3.3 Agent 工具调用与意图识别：两者缺一不可

Agent（智能体）是目前另一个热门方向。一个 Agent 通常需要：

1. 理解用户意图（分类问题）
2. 决定调用哪个工具（匹配问题）
3. 构造工具入参（生成问题）
4. 根据工具返回结果组织最终回复（生成问题）

其中步骤 1 和 2 可以有不同的实现方式。一种是纯 LLM 调用函数（Function Calling），让模型从预定义的函数列表里选一个匹配的——这依赖 LLM 的逻辑和指令跟随能力。另一种更轻量、更快的方式是先用 Embedding：把用户 query 向量化，和每个功能点的文本描述做相似度匹配，命中后再用 LLM 填参数和生成回复。

我实际项目中更倾向于混合方案：Embedding 做第一层粗筛，把候选工具从 50 个缩减到 3~5 个，再让 LLM 从这 3~5 个里精确选择并生成入参。这样既控制了速度，又保证了泛化能力。如果只有 LLM，每次都要把所有工具描述塞给模型，工具一多 Prompt 就爆炸，而且 LLM 选错工具的幻觉时有发生；如果只有 Embedding，则无法处理复杂语义和生成参数。

3.4 文本预处理和聚类：Embedding 的高性价比阵地

在构建 LLM 应用前，你经常要对文本数据进行清洗、去重、分类。比如你抓取了 10 万条评论，想做情感分析或主题聚类。

这种“离线批量处理”场景，首选 Embedding。方法不复杂：先对每条评论向量化，然后用 KMeans 聚类或者计算两两距离，就能把语义相近的文本聚成堆。比如客服工单系统里，你可以用这个方法自动发现“用户最常抱怨的五类问题”，再决定要不要用 LLM 为每一类生成总结报告。

这里为什么要用 Embedding？因为 10 万条文本如果都用 LLM 分析，比如让 LLM 给每条打标签，API 费用会非常夸张。而 Embedding 便宜两个数量级，聚类效果也足够好。

4. 工具选型和评估标准：结合 Dify、LlamaIndex 等平台的实践

搜索引擎和热词里频繁出现 Dify、Rerank、Text Embedding 安装等词汇。这里我展开讲一下，在这些集成平台里如何选模型、如何配合 Rerank 模型，以及如何评估效果。

4.1 Embedding 模型选型：三个核心指标

选 Embedding 模型，我一般只看三件事：

1. 维度（Dimension）。维度越高信息容量越大，但存储和计算越贵。不是维度越高越好，要和你的数据量匹配。数据量在 100 万以下，768 或 1024 维度足够用。
2. 最大输入 Token 长度（Max Tokens）。如果你的文档块本身比较长（比如 1000 字以上），就不能选输入长度只有 256 Token 的模型，否则会截断导致语义丢失。很多中文长文档场景我推荐选 512 以上输入长度的模型。
3. 领域适配。通用 Embedding 模型在垂域（医学、法律、金融）上效果往往打折。如果有预算，建议用领域语料对 Embedding 模型做继续预训练或微调（热词里提到的 LoRA 微调 Embedding 模型就是干这个的）。否则，用 bge-m3、text-embedding-3-large 这类通用模型作为 base，再用 Rerank 模型来弥补召回精度不足。

4.2 Rerank 为什么能救 Embedding 的场

要理解 Rerank（重排序），就得先知道 Embedding 召回的局限。Embedding 是双塔结构（query 一个塔，document 一个塔，分别编码后算相似度），它的优点是快，缺点是 query 和 document 没有充分交互。有时候用户问的是“猫是不是比狗聪明”，而文档里只有“狗和猫的智力研究”，两者从字面上看相关性不高，但可能内容确实相关。双塔模型容易漏掉这种需要深度理解才能看出的相关性。

Rerank 模型（如 bge-reranker、Cohere Rerank）则是交叉编码器：把 query 和 document 拼在一起作为输入，让模型直接打分。它的计算量远大于双塔模型，但准确率高很多。所以标准做法是两段式：

• 第一段：Embedding 粗召回，从 100 万条里捞出 top 50。
• 第二段：Rerank 精排，从 50 条里挑出 top 5 送进 LLM 上下文。

在 Dify 这类平台里，你可以在“知识库检索”配置项中同时设定 Embedding 模型和 Rerank 模型。检索时它会先向量检索，再做重排序，最后把最优结果拼进 Prompt。建议你如果对召回效果不满意，先别急着换 Embedding 模型，加一个 Rerank 模型往往提升更明显、成本也更划算。

4.3 评估 Embedding 效果的正确姿势

很多人选 Embedding 模型只看“排行榜分数”，但排行榜用的是通用数据集，你的业务场景不一定一样。我更推荐自己做一个小的评估集：

1. 从你的业务数据里挑 100 个典型问题，每个问题标注出它对应的“正确答案/参考文档”。
2. 用候选 Embedding 模型给这 100 个问题向量化，并在全量文档里召回 top 5。
3. 计算 Recall@5（正确文档出现在前 5 的比例）。如果低于 70%，你就要考虑重新选型、调切块策略或者上 Rerank。

比如我做过一个法律文档问答项目，刚开始用通用的 openai embedding 模型，Recall@5 只有 65%。后来换了 bge-m3（中文优化更好），在同等切块策略下 Recall@5 提到了 82%。这一步收获巨大，而代价只是改写了几十行调用代码。

4.4 切块策略对 Embedding 效果的影响

这块很多人忽略，但它常常是 RAG 效果差的最大原因。Embedding 是对整个文本块做一个压缩向量，如果文本块太长了，向量会被“平均化”，细节信息全部丢失。比如你一次性切了 2000 字的文档块，里面讨论了五个不同的主题，Embedding 向量无法同时表达五个主题，检索时就会四不像。

我建议按如下原则做切块：

• 先按章节/段落切，不要生硬按固定 Token 数切。
• 单块尽量控制在 200~500 字，中文场景 300 字左右比较稳。
• 如果单块信息密度太高，考虑设置 overlap（相邻块重叠 100~200 字），避免切断语义。
• 对每个块，可以额外拼接一个“块标题”或“父级摘要”，提升召回质量。

切块后，记得把块的元数据（来源、标题、页码）也一起存进向量数据库，方便后续引用。

5. 实际项目中的一些经验教训与常见误用

最后一章，我集中聊聊我在真实项目里踩过的坑，以及一些可以让你少走弯路的经验。这些内容你从官方文档和论文里很难学到，都是我拿实际项目换来的。

5.1 常见误用一：直接拿 LLM 做批量匹配

我有一个客户，早期用 GPT-4 做“用户问题—FAQ 匹配”，就是把用户问题发给 GPT-4，让它从 1000 条 FAQ 里选出最匹配的回答。准确率确实还可以，但成本离谱：每天 10 万次调用，一次平均消耗 2000 Token，一个月光这个功能就烧掉好几万，而且响应速度平均 3 秒，客户体验也不好。

后来我给他改成：先用 Embedding 召回 top 10 候选 FAQ，再用一个小的 LLM（比如 Qwen-turbo）在这 10 条里选择，每次消耗不到 200 Token，响应时间降到 1 秒以内，准确率不仅没降，还因为上下文里全是高相关候选，幻觉率降低了。这就是典型的“把 LLM 用在该用的地方，把脏活累活交给 Embedding”。

5.2 常见误用二：拿 Embedding 做情感分析、意图分类的“本质判断”

Embedding 不是一个模型，而是一个“度量工具”。它判断的是“语义距离”，不能判断好坏、对错、阴阳怪气。比如“你真厉害”带讽刺语境和真心夸奖，在向量空间里可能距离非常近，因为字面相同。你要是用 Embedding 直接做情感分类，遇到讽刺和反语基本全军覆没。

正确做法是：Embedding 可以把文本转成特征向量，然后你用这些向量训练一个简单的分类头（比如逻辑回归、MLP），或者干脆直接丢给 LLM 做情感判断。前者便宜但需要标注数据，后者灵活但要控制成本。千万别把 Embedding 的余弦相似度结果直接当情感标签输出，那是灾难。

5.3 关于 LoRA 微调 Embedding 模型的实践心得

热词里提到“LoRA 微调 Embedding 模型”，我多说一句。LoRA 本来是给 LLM 做轻量微调的技术（冻结原模型，只训练低秩矩阵），但它同样可以用于 Embedding 模型。

什么时候需要微调 Embedding？当你发现通用模型在你领域数据上的召回率，无论怎么调切块、加 Rerank 都上不去时。比如医疗领域的缩写、疾病名、药品别名非常多，通用模型没学过，向量空间里这些词的分布是混乱的。你可以用几千条专业标注数据（比如“标准问题—相似问法”对），用对比学习的方式来微调 Embedding 模型。数据量不用很大，3 万对以内就能看到明显效果。

微调时注意几个坑：

1. 负样本的选择很关键。只挑那些“字面上像但语义不同”的样本做负样本，模型才能学到真正的语义差异。
2. 学习率要小，LoRA 一般 1e-4 到 5e-5。
3. 微调完一定要重新评估，防止把通用能力弄坏。如果你数据量少于 1000 条，不建议微调，直接加 Rerank 更划算。

5.4 常见问题速查表

我整理了一个速查表，开发和运维时可以直接对照排查。

5.5 我的个人扩展想法

基于 LLM 的毕业设计或者个人项目，我特别推荐“Embedding + Rerank + LLM”这个三段式基础架构。它不复杂，但能一次覆盖检索、精排、生成三大核心机制，做出来东西的完整度和专业性远超“直接调一个 OpenAI 接口”。你有能力的话，甚至可以自己用 LlamaIndex 或者 LangChain 把这条链路写一遍，绝对比单纯套平台模板收获大。

最后分享一个我的心得：不要试图让一个模型解决所有问题。LLM 确实强大，但它不是万能的，也不是最经济的。Embedding 看起来不起眼，却是让大模型在企业数据上“落地生根”的关键一步。理解两者的分工，再谈架构设计，才是正经做法。