企业官网建设流程全解析

1. 能力全景：LLM到底能干什么

学习大语言模型，很多人上来就去啃架构和数学公式，结果越学越懵。我自己的经验是反过来，先建立一张能力地图，搞清楚模型擅长什么、边界在哪里，再去看机制，会顺畅得多。这篇笔记就按这个思路来整理。

所谓大语言模型，本质是一个通过海量语料训练出来的概率系统。它做的事非常朴素——给定一段文本，预测下一个最可能的词或token。但就是这样一个简单的预测任务，在参数规模大到一定程度、训练数据足够丰富之后，涌现出了一系列令人惊讶的能力。我把它拆成六个维度来看。

语言理解与生成。这是最基础的能力，包括阅读理解、文本摘要、改写润色、风格模仿、情感分析等。你给它一段产品描述，它能提炼卖点；给它一段聊天记录，它能总结出用户的核心诉求。这项能力的上限取决于训练数据里文本模式的丰富程度，这也是为什么中文语料质量会对模型表现产生直接影响。

知识问答与常识推理。预训练阶段模型把海量知识以参数的形式"记住"了，所以你可以问它历史事件、科学常识、代码写法、菜谱做法之类的问题。但要记住，它的知识是统计性的，不是像搜索引擎那样检索出来的。所以它给出的答案在大多数情况下是对的，可一旦记错，就会非常自信地说错，这是典型的知识幻觉来源。

上下文学习。这是大模型一个很神奇的特性。你不需要调整任何参数，只需要在提示词里给出几个"输入-输出"的例子，模型就能自动顺着这个模式回答新问题。研究里管这叫in-context learning。实践中，我们经常利用这个特性做少样本分类、信息抽取，省去了微调的麻烦。不过它的稳定性和样本数量、示例质量强相关，不是每次都能成功。

复杂推理与规划。CoT——思维链的出现，让模型可以从"直接给答案"进化到"一步步演算再给答案"。数学应用题、逻辑推断、代码调试、多步骤任务规划，这些都能通过让模型把思考过程写出来而显著提升准确率。但推理深度和准确率会受到上下文长度的限制，步骤太长，后半段就容易"跑飞"。

代码生成与执行。代码是一种天然的、结构化极强的语言。模型在大量代码仓库上训练之后，具备了很强的代码理解和生成能力。从函数补全、Bug修复到根据注释生成整段模块，现在的主流模型已经能做到相当高的可用度。结合工具调用、单元测试反馈，可以组成一个简单的自动编程闭环。

多模态扩展。纯文本模型解决的是文字世界的问题，但真实业务场景里图片、音频、视频同样重要。视觉大语言模型，就是把图像编码器和大语言模型的推理能力结合起来，让模型能"看懂图"。比如给一张UI设计图，让它生成对应的前端代码；给它一张产品照片，让它写一段商品描述。我在本地部署过的几个开源视觉模型，在OCR和简单图表理解上的表现已经非常能打了。

不过，能力再强也有短板。我一开始就是因为被几个"翻车现场"打击过，才痛下决心系统梳理LLM的局限。

2. 机制速通：先懂原理，才知道边界在哪

2.1 训练流水线白话版

大模型的能力不是凭空来的，它背后是一条极其烧钱的训练流水线。理解这条流水线，你就能理解很多表面问题背后的深层原因。

第一步是预训练。模型在海量文本上做下一个词预测，学的是语言规律和世界知识。这里有个关键点，就是训练数据决定了知识上限。模型永远不可能准确回答它在训练语料里没见过、或者出现频率太低的信息。所以我自己用LLM时有个习惯——哪怕是本地部署的模型，它回答"我不知道"的频率，远比回答错误信息的频率健康得多。一个敢承认不知道的模型，比一个什么都能编的模型更值得信任。

第二步是指令微调——SFT。预训练出来的模型只会接龙，不会听命令。需要用一批高质量的"指令-回答"数据对来调整模型行为，让它学会"用户问什么，我就答什么"这个互动范式。这也是为什么有时候两个能力差不多的模型，聊起来体感差异巨大——指令微调数据质量不同，模型"听话程度"就完全不同。我试过一个开源基座模型和它的Chat版本，前者一句人话都不想输出，后者基本能正常交流。

第三步是RLHF或DPO这类偏好对齐。通过人类反馈，让模型的回答更安全、更有用、更符合主流价值观。我在学习和实测中观察到一个现象：对齐做多了，模型的创造性和多样性会下降；对齐做少了，模型又会变得"放飞自我"。如何在有用性和安全性之间取平衡，是各家模型反复调优的核心课题。

2.2 推理机制的省钱方案

如果说训练阶段是"教"，推理阶段就是"用"。我在本地部署和调用API时，对推理机制最有体感的就是KV Cache和温度采样。

没有KV Cache，模型每次生成一个token都要重新计算之前所有token的注意力，代价非常大。有了KV Cache，之前算好的Key和Value被缓存下来，后面生成就只算新token，速度能提升一个数量级。这是为什么长对话越聊越卡的问题可以通过缓存优化来解决，也是为什么大上下文模型需要做显存优化的关键点。

温度参数控制的是输出的随机性。温度越低，模型越倾向于选择高概率的token，确定性越强，适合代码生成、知识问答和分类任务；温度越高，输出越有创造性和多样性，适合文案创意、头脑风暴和角色扮演场景。我通常会把技术任务的温度设在0.1到0.3，创意任务设在0.7到1.0之间。这里有个小坑：很多人只调温度，却忘了同时调整top_p和重复惩罚参数，结果发现温度调了也没用，其实是因为几个采样参数互相耦合。经验是，固定top_p=0.9，再通过温度控制自由度，整体效果最稳。

2.3 为什么模型会一本正经地胡说八道

幻觉，是使用大模型时遇到最多的坑。它的本质不是模型"故意说谎"，而是模型在生成时根本没有"事实核查"这个环节。它输出的每一个token，都是根据前文"统计上最合理"的候选，而不是经过验证的真命题。

训练数据里互相矛盾的表述会让模型学到混合分布，这时候随便给一个问题，它可能选了一条不该选的路径。所以我做Agent的时候有个强制约束：凡是涉及事实判断的任务，绝对不允许模型直接回答，必须要求它先调用工具检索资料，再基于检索结果作答。把事实核查从模型内部搬到外部，是目前克制幻觉最有效的路线。

3. 核心局限：那些踩过的坑和翻过的车

3.1 数学与精确计算的薄弱环节

大模型对"约等于"很擅长，对"精确等于"很头疼。我做过一个测试，让当时的几个主流模型计算2387乘以456，直接答基本都会错，但让它们分步骤列竖式，正确率会大幅提升。模型本质是语言模型，不是计算器，它的算术能力是通过语言模式学到的，而不是通过精确规则实现的。

生产环境里要求精确计算的地方，我从来不让模型直接算。正确做法是，用代码解释器或者工具调用来处理数值运算，模型只负责把自然语言问题翻译成计算步骤。很多框架里内置的Python工具就是干这个的。思维链能让简单数学习题的正确率上来一些，但三位数乘三位数这种，老老实实交给计算器最靠谱。

3.2 上下文窗口的物理限制

上下文窗口看起来一直在变大——从早期的4K、8K，到现在的128K、200K甚至1M——但"窗口大"和"用得好"完全是两回事。实测下来，超过一定长度后，模型对中间部分内容的注意力会明显衰减，这就是"lost in the middle"效应。用户给了一份200页的资料，真正起决定作用的细节藏在第120页，模型往往视而不见。

所以我做长文档问答系统时，不会盲目地把整篇文档塞进上下文。而是先做切片和向量化，用检索召回最相关的片段，再拼装成一个精简提示词。这样既控制了上下文长度，又保证重点信息被模型"看见"。这个思路，就是现在RAG的底层逻辑。对普通用户也一样，你要问一本书的问题，最好先指出问题在哪一章，而不是把整个PDF丢给模型让它自己找。

3.3 知识截止与实时性问题

所有静态模型都有知识截止日期，训练完成的那一刻，它的世界就冻结了。你问它最新新闻、最新产品、最新政策，它要么答错，要么坦诚地说不知道。但很多人没意识到的是，知识截止不只是"日期"的问题，还包括数据覆盖率的问题。即便是截止日期之前的知识，冷门领域、小众语言、低频话题，依然可能是它的盲区。

解决思路有两个方向。一是接外部知识源，用搜索API或知识库工具实时获取，常见于RAG系统；二是用微调把私有知识注入模型。前者成本低见效快，适合大多数场景；后者成本高且需要持续维护，一般只用于垂直领域。我自己在做本地部署时，更偏好第一种方案——精准、可控、不污染模型原有能力。

3.4 推理链条长度与错误累积

思维链是当前提升复杂推理能力最有效的手段之一，但它的边际收益是递减的。推理步骤越多，链条越长，中间任何一个环节出错，错误就会被放大传导到最终结果。这就是为什么你让模型做十步逻辑推理，它能对；做五十步的时候，它给出的答案可能完全偏离逻辑方向。

为了缓解这个问题，业界尝试了各种方案——自我反思、ReAct模式、外部验证器——但都不存在银弹。我现在最常用的做法是"分而治之"：把大任务拆成若干小任务，让模型分步执行，每步产出中间结果并做校验，而不是让模型一次性走完全程。把50步的推理变成5个10步的推理，准确率会有质的提升。

3.5 定式化表达与多样性衰减

对齐做得越好，模型的表达风格就越趋向于"标准答案"。你问十个问题，它可能用完全一样的句式结构回答；你让它写一封邮件，它给出的版本和网上模板极其相似。尤其是一些强对齐的商业模型，输出的文本带有非常明显的"AI味"——排比句、官方腔、面面俱到但空无一物。

这个问题的根源在于对齐训练过程中，模型被反复引导向"人类标注员更喜欢"的输出风格，而标注员偏好高度集中的结果是分布坍缩。破局手段有三：调高温度引入多样性；在提示词里明确风格约束、禁用套话；或者对回答做后处理改写。如果你在用开源模型，还可以选择多样性较好、对齐较轻量的基座模型自行微调。

4. 工程化实践：从原理到落地的关键动作

4.1 高质量输入的结构化设计

同样的模型，不同的提示词，效果可以天差地别。我自己早期也是吃了不少"提示词玄学"的亏，后来用结构化Prompt之后，稳定性一下子好了很多。核心做法是给模型一个清晰的上下文框架：角色定义、任务目标、输入数据、输出格式、限制条件、若干示例。这六个要素，基本能涵盖80%以上的业务场景。

我常用的一个提示词模板是这样：

你是一个资深的XX领域专家。 请完成以下任务：XXX。 输入资料：XXX。 输出要求：以JSON格式输出，字段包括：result、reason、confidence。 限制条件：不要输出与问题无关的内容，不要编造数据。如果是你不确定的信息，请在result中返回"UNKNOWN"。 参考示例：略（这里贴2到3个少样本示例）。

这套结构看起来朴素，但它解决了一个重要问题——把模型的"自由发挥空间"压缩到最小，把任务约束显式化。模型不是越聪明越能猜中你在想什么，而是你把边界画得越清晰，它越稳定。尤其是写代码生成和结构化数据提取任务，效果立竿见影。

4.2 工具调用与Agent模式

要做好一个由LLM驱动的智能体，核心问题不是选多强的模型，而是把"模型决策"和"工具执行"可靠地编排起来。经典做法是ReAct模式：让模型循环交替执行Thought（推理下一步）、Action（选择一个工具）、Observation（观察执行结果），直到完成目标。

我在实践中的一个体会是：工具定义越明确，模型调用的准确率越高。给每个工具写清晰的名称、描述、参数schema，模型才能正确选择。这相当于给模型的"手"装上规范的操作接口。有个常见错误是把所有工具一股脑丢给模型让它自己试错，结果模型在复杂场景下频繁选错工具、传错参数、形成死循环。正确的做法是给工具分级：核心工具永远优先，辅助工具只在特定条件下开放，并且对工具调用次数设置上限。

还有一个容易被忽略的工程细节——纠错机制。Agent如果犯了错，比如一段返回的JSON解析失败，系统需要有自动重试或降级策略，而不是直接把错误抛给用户。我在实际Agent中加入了Trace日志和重试策略，整体成功率能提升十几个百分点。

4.3 本地部署：以GGUF与推理框架为例

本地部署大模型在热词里出现了很多次，确实，现在自己电脑上跑一个7B或13B模型已经很常见了。这种操作的核心思路是量化——把模型的权重从FP16压缩到INT8、INT4等低精度格式，换取更低的显存占用和更快的推理速度。GGUF就是目前最主流的量化存储格式之一，能在消费级显卡甚至纯CPU环境下运行模型。

我自己在M系列芯片的笔记本上用过llama.cpp和Ollama跑7B级别的模型。量化到Q4_K_M之后，一个7B模型文件大约4GB左右，在16GB内存的机器上可以流畅运行，速度大概在每秒20到40个token之间，体感完全可接受。这里要提醒的是量化的取舍：Q8比Q4的精度更高，但是显存占用几乎翻倍；超大上下文长度会显著增加KV Cache显存消耗，所以设置max context时要根据自己的硬件上限来定。

本地部署的好处是数据不出设备、隐私安全、无API调用成本、可以自由微调。但代价是模型能力通常弱于商业大模型，尤其是复杂推理和长文本理解方面。所以我的建议是：日常闲聊、隐私敏感任务、离线场景走本地模型；复杂专业任务还是用云端API模型。两者互为补充，不必非黑即白。

在配置工具时，YAML确实已经成为主流做法之一。像Ollama的Modelfile、Llama.cpp的启动脚本、以及LangChain等框架的Agent配置，都能看到YAML或TOML格式的身影。相比直接在命令行里堆参数，把模型路径、量化等级、上下文长度、系统提示词都写进配置文件的好处是可以版本化管理、批量修改、复用环境。我自己的习惯是本地跑实验时先写好default.yaml，再为不同项目维护对应的profile，切换场景就是切换配置文件的事。

4.4 数据标注与微调的必要性

很多人问过我一个问题："直接用提示词不就能解决了吗？为什么要做微调？"我的回答是：提示词适合描述"规则"，微调适合灌输"偏好"和"私有知识"。当你的任务场景高度垂直、输出格式高度固定、且需要稳定复现时，微调的上限远高于提示词工程。

微调的前提是数据标注。可以选商业标注平台，也可以自己用小模型辅助标注。我踩过一个很大的坑是在数据质量上——一开始贪多，凑了两万条数据送进去做微调，结果效果反而不如只挑三千条高质量数据的版本。微调数据宁缺毋滥，每条数据都得保证输入输出对齐、格式统一、覆盖边界情形。清洗阶段花三小时，胜过后处理花三天。这是用真金白银买来的经验。

另外还有一点值得注意：微调不是解决所有问题的万能钥匙。模型自身已经具备的能力，微调可以激发和引导；模型根基里就不具备的能力，比如数学推理或者复杂代码逻辑，微调很难无中生有。评估自己做微调前，先问一个问题：这个问题，换一种提示词写法是不是就已经能解决了？如果是，就不要微调。

5. 伦理边界与数据隐私问题

大模型的伦理问题不是抽象思辨，而是工程实践中绕不开的合规约束。我在做Agent和知识库项目时，对以下几类问题特别敏感：训练数据里可能包含偏见和歧视性内容的延续；模型可能被诱导生成有害信息；模型可能泄露训练语料中包含的个人隐私。

实际业务中，部署一个面向C端用户的LLM应用，不是"模型回答正确"就够了。还需要在输入侧做内容过滤和Prompt注入防护，在输出侧做敏感词检测和风险内容拦截。RAG系统里尤其要注意知识库文档的身份校验——如果检索到的文档本身被污染，模型的回答也会被带偏。我见过不止一次因为知识库里混入了低质量甚至错误文本，导致模型"一本正经地用错误信息回答问题"的案例。

更理性的视角是：LLM本质上是一个"人类知识的压缩库"，它反映的是训练数据的统计规律，不代表"客观真理"。当它作为辅助工具嵌入人类决策流程时，需要人为设置"安全阀"——比如在医疗、法律、金融等高风险场景，模型输出必须由专业人员复核，这是对用户负责，也是对自己负责。

6. 向量检索与知识库：让模型学会"查阅资料"

我在前文反复提到RAG，这里展开来说说。RAG系统的基本链路是：用户提问 -> 向量化问题 -> 在知识库向量数据库中检索相关片段 -> 把片段和问题拼装成提示词 -> 交给模型生成回答。它解决的最大问题，就是让模型"看过相关资料再回答"，而不是"凭记忆瞎猜"。

向量化就是把文本变成长度固定的向量数组，语义相近的文本在向量空间里距离也相近。这里有几个参数值得注意：chunk_size决定每段文本的切分长度，它会影响检索粒度；overlap_size让相邻片段之间保持部分重叠，避免关键信息被从中间切断；embedding模型的选择则决定了"语义匹配"的质量。我常用的经验值是chunk_size=500到800字符、overlap=50到100字符，但这个值需要根据文档类型灵活调整。

我在做知识库项目时反复踩过的坑有三个——第一，切分点不能盲目按固定长度切，最好按Markdown标题、段落等自然边界来切；第二，检索结果不能只取Top1，通常取Top3到Top5做融合，否则容易漏关键上下文；第三，问答时要在提示词里明确告诉模型"如果检索片段中没有答案，就直接说不知道，不要编"——这是一个简单但非常有效的幻觉抑制手段。

7. 总结与学习路线建议

写到这里，能力地图和局限图谱基本就清晰了。大语言模型的本质是"语言接龙大师"，它擅长模式识别、知识复述、内容生成、语言翻译、代码辅助，但也仅仅擅长这些。它不擅长精确计算、实时知识、长链条推理、事实核查——而这些短板，恰好是人类工程师通过架构设计和工具调用来弥补的空间。

根据我自己的学习和实践路径，给后来者三个建议。第一，不要只当"调用者"，要理解背后的训练机制和推理代价，这样才能在模型选型和方案设计时做出合理的判断；第二，一定要亲手跑一遍本地部署、RAG搭建和Agent编排，所有纸面上的理解都只有在上手之后才会真正内化；第三，保持对模型输出的警惕心，把"质疑"变成使用习惯——不是所有看起来合理的答案都是对的，多验证、多交叉核对。

我个人在实际操作中最深的体会是：大模型真正的价值不在模型本身，而在于你如何设计围绕它的系统。一个结构良好的Prompt、一条经过检验的RAG链路、一套可靠的Agent工具编排，远比换一个更强的模型更能提升最终效果。模型会持续升级，这些实践方法论却可以一直复用。希望这篇笔记能帮你在学习和实战中少走一些弯路。