企业官网建设流程全解析

1. 从零上手LLM：先搞清楚你手里拿的是什么牌

很多人第一次接触LLM，脑子里蹦出来的第一个问题就是“这玩意儿到底怎么用”。我见过太多人一上来就急着调API、跑模型、搭框架，结果连自己用的模型是什么类型、能干什么、不能干什么都没弄明白，最后踩了一堆坑回头补课。所以这篇东西我打算按实际操作的顺序，把LLM使用过程中真正会遇到的问题一个个拆开讲，不搞那些虚头巴脑的概念堆砌。

先给完全没接触过的朋友一个最直白的定义：LLM就是大语言模型（Large Language Model），本质上是一个用海量文本训练出来的概率模型，你给它一段输入（prompt），它根据训练时学到的统计规律，一个token一个token地往外吐输出。它不是在“思考”，也不是在“查数据库”，而是在做下一个token的概率预测。理解这一点非常关键，因为后面很多使用技巧和坑，根源都在这里。

那LLM能做什么？文本生成、摘要、翻译、代码补全、问答、信息抽取、对话、角色扮演、格式转换，这些是最常见的用法。它不能做什么？不能保证事实准确性、不能做精确数学计算（除非借助工具）、不能访问实时信息（除非外挂检索）、不能记住你上一轮对话之外的东西（除非你把上下文塞进去）。适合谁来学？不管你是开发者、产品经理、运营、研究者还是纯粹的好奇者，只要你想把LLM用起来解决实际问题，这篇内容都适用。

我自己的经验是，把LLM当成一个能力很强但非常 literal 的实习生——你说什么它就做什么，你没说的它不会主动帮你补，你表达模糊它就自由发挥。所以“怎么用”的核心，其实就两件事：怎么把话说清楚，以及怎么给它配上合适的工具和知识。

2. LLM核心概念拆解：Token、上下文窗口与模型选型

2.1 Token到底是什么，为什么它决定了你的钱包和效果

Token是LLM处理文本的最小单位。你可以把它理解成“词片”——一个英文单词可能是一个token，也可能被拆成好几个；一个中文字通常对应1到2个token，具体取决于分词器。比如“我是谁”这三个字，在不同模型的分词器下可能是2到4个token。

为什么要在意token？两个原因。第一，API计费按token算，输入和输出都算钱，你prompt写得越长，成本越高。第二，上下文窗口按token算，模型一次能“看到”的token数量是有上限的，超出部分要么被截断，要么直接报错。

我实测下来，一个粗略的换算经验：英文大约1个token对应0.75个单词，中文大约1个token对应0.5到1个汉字。但这个比例因模型而异，最靠谱的办法是用对应模型的分词器实际跑一下。很多平台都提供了token计数工具，调API之前先数一下，能省不少冤枉钱。

注意：不要用“字数”去估算token，尤其是中英混排、代码、特殊符号混在一起的时候，误差会非常大。我见过有人按字数算预算，结果实际账单翻了三倍。

2.2 上下文窗口：LLM的“工作记忆”有多大

上下文窗口（context window）指的是模型单次推理能处理的最大token数，包括你输入的prompt和它生成的输出。早期模型只有2K、4K，现在主流模型动辄32K、128K甚至更大。

这个参数直接决定了你能怎么用LLM。窗口小，你就只能做短对话、短文本处理；窗口大，你才能塞进去整篇文档、多轮对话历史、甚至一整个知识库的片段。

但这里有个很多人不知道的坑：窗口大不等于效果好。模型在超长上下文里会出现“中间遗忘”现象——放在上下文中间位置的信息，模型回忆起来的准确率明显低于开头和结尾。所以如果你要往上下文里塞大量材料，把最关键的信息放在开头或结尾，中间放次要内容，这是一个非常实用的技巧。

2.3 模型选型：开源还是闭源，大还是小

选模型这件事，没有绝对的最优解，只有适不适合你的场景。我一般按这几个维度来决策：

如果你是做原型验证、效果优先、数据不敏感，直接用闭源API最省事。如果你有数据合规要求、需要离线运行、或者要深度定制，那就走开源自部署路线。开源模型里，参数量从1B到70B甚至更大都有，小模型跑得快但能力有限，大模型效果好但吃硬件。7B到14B这个区间在消费级显卡上比较现实，再往上基本就要考虑多卡或量化了。

关于公开榜单，比如Open LLM Leaderboard这类，我的态度是：参考可以，迷信没必要。榜单测的是通用基准，你的实际任务可能完全不在那个分布里。我见过榜单排名很高的模型在我自己的业务场景里表现平平，也见过排名一般的模型在特定任务上出奇地好用。最终还是要拿你自己的数据去测。

3. Prompt工程实操：把话说清楚比什么都重要

3.1 三个核心要素：Key、Query、Value

热词里提到的“token三个点key我是谁、query我在找什么、value我能提供什么”，其实对应的是信息检索和RAG里的核心概念，但放到prompt设计里同样适用。我把它翻译成prompt语言：

• Key（我是谁）：给模型设定角色和身份。“你是一个资深法律顾问”“你是一个Python代码审查专家”——这决定了模型调用哪部分知识和语气。
• Query（我在找什么）：明确告诉模型你要什么。“帮我总结这段合同的风险点”“找出这段代码的bug”——任务指令要具体。
• Value（我能提供什么）：把你手头的信息、约束条件、输出格式要求给清楚。“以下是合同全文……”“输出用表格，三列：风险点、严重程度、建议”。

这三个要素齐了，prompt的基本盘就稳了。缺了Key，模型不知道用什么身份回答；缺了Query，模型不知道你要干什么；缺了Value，模型只能瞎编或者泛泛而谈。

3.2 结构化Prompt的写法与模板

我平时用得最多的prompt结构是这样的：

# 角色 你是一个[具体角色]，擅长[具体能力]。 # 任务 请根据以下[输入类型]，完成[具体任务]。 # 输入 [把你的材料贴在这里] # 约束 - 输出语言：中文 - 输出格式：[JSON/表格/段落] - 不要编造输入中没有的信息 - 如果信息不足，明确说明缺少什么 # 输出 [可以给一个示例]

这个模板看起来简单，但每一条都有用。角色设定让模型收敛到合适的知识区域；任务描述要动词明确；约束条件里“不要编造”这条尤其重要，能显著降低幻觉；给输出示例则是在做few-shot，模型会模仿你给的格式。

3.3 常见Prompt反模式与修正

我踩过的prompt坑，基本都集中在这几类：

反模式一：指令太模糊。“帮我写个方案”——写什么方案？给谁看？多长？什么风格？模型只能猜。修正：把背景、目标、受众、长度、格式都写清楚。

反模式二：一次塞太多任务。“帮我总结这篇文章，然后翻译成英文，再提取关键词，最后写个标题”——模型可能只做前一两步就停了。修正：拆成多轮，或者用明确的编号步骤，并要求它逐步输出。

反模式三：否定式指令。“不要写得太啰嗦”——模型对“不要”的处理往往不如“要”来得稳定。修正：改成正面指令，“用不超过200字，每段不超过3句”。

反模式四：没有给输出格式。你想要JSON，结果它给你一段散文。修正：直接给JSON schema或者示例。

实操心得：如果你发现模型输出不稳定，先别急着换模型，先把prompt改三遍。我大概有七成的问题是通过改prompt解决的，剩下三成才是模型能力或工具链的问题。

4. RAG与知识库：让LLM用上你自己的数据

4.1 为什么需要RAG

LLM的训练数据有截止日期，而且不包含你的私有数据。你问它“我们公司上季度的销售数据”，它要么说不知道，要么编一个。RAG（Retrieval-Augmented Generation，检索增强生成）就是解决这个问题的标准方案：先从你的知识库里检索出相关片段，再把片段塞进prompt里让LLM基于这些片段回答。

RAG的核心流程是：文档切分 → 向量化 → 存入向量库 → 用户提问时检索最相关的片段 → 拼进prompt → LLM生成回答。每一步都有讲究，切分粒度、embedding模型选择、检索策略、重排序，任何一个环节出问题都会影响最终效果。

4.2 LLM Wiki与知识库的搭建思路

热词里反复出现的“LLM Wiki”“LLM Wiki知识库”“LLM Wiki项目”，本质上就是把wiki形态的知识内容做成RAG可用的知识库。我自己的做法是：

1. 文档预处理：把wiki页面转成纯文本或Markdown，去掉导航、页脚这些噪音。
2. 切分：按语义切分，不要按固定字数硬切。一个段落、一个小节为单位比较合理，通常200到500字一段。
3. 向量化：用embedding模型把每段转成向量。中文场景下，选支持中文的embedding模型，别直接用英文模型硬套。
4. 存储：向量库存进专门的向量数据库，同时保留原文和元数据（来源、标题、时间）。
5. 检索：用户提问时，把问题也向量化，做相似度检索，取Top-K个片段。
6. 重排序：如果对精度要求高，加一个rerank模型对检索结果重新排序。
7. 生成：把检索到的片段和用户问题一起拼成prompt，让LLM基于片段回答，并要求它标注信息来源。

4.3 GraphRAG与本体：什么时候值得上

普通RAG是“扁平”的——它检索的是一段段独立的文本片段，片段之间的关系它不知道。GraphRAG则是在此基础上构建知识图谱，把实体和关系抽出来，检索时不仅看文本相似度，还看图谱上的关联。

热词里的“llm ontology”“rag graphrag llm wiki 本体rag”说的就是这个方向。什么时候值得上GraphRAG？当你的问题需要跨文档、多跳推理的时候。比如“A公司的CEO曾经在哪些公司任职，这些公司里有哪些和B公司有合作关系”——这种问题普通RAG很难答好，因为它需要把多个片段里的实体关系串起来。

但GraphRAG的代价也很明显：构建图谱需要额外的抽取和校验成本，维护复杂度高，而且不是所有场景都能带来明显提升。我的建议是：先用普通RAG跑起来，遇到多跳推理的瓶颈再考虑GraphRAG，不要一上来就上重型方案。

5. 部署与工具链：从API调用到本地运行

5.1 API调用：最省事的起步方式

如果你只是想快速用起来，调API是最短路径。基本流程就是：注册平台 → 拿API key → 按文档发请求 → 解析返回。大多数平台都兼容OpenAI风格的接口，所以你会了一个，基本能套用到其他家。

# 以OpenAI风格接口为例的调用示意 from openai import OpenAI client = OpenAI(api_key="你的key", base_url="平台地址") response = client.chat.completions.create( model="模型名称", messages=[ {"role": "system", "content": "你是一个专业助手。"}, {"role": "user", "content": "用三句话解释什么是token。"} ], temperature=0.7, max_tokens=500 ) print(response.choices[0].message.content)

几个关键参数：temperature控制随机性，0更确定，1更发散，做事实问答用低值，做创意写作用高值；max_tokens限制输出长度；top_p是另一种采样控制，一般和temperature二选一调。

5.2 本地部署：ONNX与量化

热词里提到“onnx部署llm模型”，ONNX是一种模型交换格式，好处是跨框架、跨硬件，推理时可以用ONNX Runtime做加速。把LLM导出成ONNX再部署，适合对推理性能有要求、又不想绑定特定框架的场景。

但说实话，LLM的ONNX部署比传统模型麻烦不少，因为LLM有动态shape、KV cache、注意力机制这些复杂结构。我的经验是：小模型（1B到7B）用ONNX部署比较现实，大模型还是用专门的推理框架更省心。

量化是另一个绕不开的话题。把模型权重从FP16降到INT8甚至INT4，显存占用能降一半到四分之三，速度也能提升，代价是效果会有一定损失。INT8量化通常损失很小，INT4就要看具体模型和任务了。消费级显卡跑本地模型，量化基本是必选项。

5.3 LLM网关：多模型统一管理

“llm 网关”这个词指的是在多个LLM之上加一层代理，统一接口、统一鉴权、统一计费、统一路由。比如你同时用好几家模型，网关可以让你用同一套代码调用不同模型，还能做负载均衡、失败重试、限流。

自己搭一个简单网关并不难，核心就是转发请求加上一些中间逻辑。但如果团队规模不大、模型数量不多，直接用各家SDK也不是不行。网关的价值在模型多、调用量大、需要统一治理的时候才明显。

6. 常见问题与排查技巧实录

6.1 模型胡说八道怎么办

幻觉是LLM的固有特性，不可能完全消除，但可以显著降低。我的排查顺序是：

1. 检查prompt是否给了足够信息。如果模型没有依据，它只能编。
2. 加约束。“只根据以下材料回答，材料中没有的信息说不知道。”
3. 降低temperature。高温会增加发散和编造的概率。
4. 上RAG。把事实性内容通过检索注入，而不是靠模型记忆。
5. 要求引用来源。让模型标注每句话来自哪个片段，方便你核查。

6.2 输出格式不稳定怎么办

明明要JSON，它给你加了一段“好的，以下是JSON：”。解决办法：

• 用few-shot，给一个完整的输入输出示例。
• 用结构化输出功能，如果平台支持的话。
• 在prompt里明确“只输出JSON，不要任何其他文字”。
• 后处理时用正则把JSON部分抠出来。

6.3 速度慢、成本高怎么优化

6.4 常见问题速查表

避坑技巧：每次改完prompt或检索策略，固定一组测试问题跑一遍，对比前后效果。凭感觉调参很容易越调越乱，有基准测试才能知道到底有没有变好。

7. 一些实际用下来的体会

LLM这个东西，上手容易精通难。最容易犯的错误是把它当成万能工具，指望它解决所有问题。实际上它更像是一个能力很强但边界清晰的组件，你需要围绕它设计整个流程——prompt怎么写、知识怎么注入、输出怎么校验、失败怎么兜底。

我自己的习惯是，任何要上生产的LLM应用，先做小规模人工评估，攒个几十上百条真实case，人工标注好坏，再决定要不要继续投入。别一上来就追求全自动、全链路，先把单点跑通，再逐步扩展。

另外，模型迭代很快，今天的最优解下个月可能就变了。所以架构上尽量把模型调用层抽象出来，换模型的时候不用改上层业务逻辑。这个投入在长期看非常值。

最后分享一个我常用的调试方法：当你不知道模型为什么输出某个结果时，把完整的prompt打印出来，自己读一遍。很多时候你会发现，如果换成你是一个完全不了解背景的人，看了这个prompt也会给出类似的“错误”回答。问题往往不在模型，而在我们以为自己说清楚了，其实没有。