LLM 相关知识（较全）
想搞数仓 AI 应用，就找了好多篇博客学习 LLM。结果东西不搭，青黄不接。此篇只是适当了解，并无深入，但较全。
一、LLM
LLM 是 Large Language Model 的缩写，中文叫“大语言模型”。
LLM 是一个经过大量数据训练之后，能够根据输入内容预测并生成后续文本的模型。
例如输入：
中国的首都是模型会根据已经看到的内容，预测后面可能出现什么，再生成：
北京。模型并不是只会填空。给它不同的要求，它还可以写文章、总结内容、翻译、回答问题或生成代码。它之所以能做这些事，是因为训练时学到了大量语言和内容之间的规律。
可以把 LLM 想成一个读过大量内容、很擅长接话的“文字接龙高手”。但这个比喻也有边界：它不是一个每次回答前都会查资料、核对事实的数据库。所以，回答听起来合理，不代表内容一定正确。
二、Token
Token 是模型处理文字时使用的基本片段。模型不会像人一样直接阅读整句话，而是先把文字切分成一个个 Token。
例如“我喜欢吃苹果”可以示意性地切成：
[我] [喜欢] [吃] [苹果]这只是方便理解的例子。真实模型的切分方式不一定和汉字、词语完全一致；有时一个字是一个 Token，有时几个字会合成一个 Token，也可能一个英文单词被拆成几部分。具体怎么切，取决于模型使用的 Tokenizer（分词器）。
Token 怎么变成模型能处理的内容？
Token 不只是文字片段，分词器还会给每个 Token 对应一个编号。模型内部主要处理的是这些编号对应的数字表示，而不是像人一样直接阅读文字。
以“我喜欢吃苹果”为例，下面的编号只是示意，不是真实模型的编号：
输入文字：我喜欢吃苹果 ↓ 分词器切分并转换成编号 输入编号：[编号1] [编号2] [编号3] [编号4] ↓ 模型根据这些编号处理输入，并生成新的编号 ↓ 分词器把新编号转换成可读文字 输出文字：我也喜欢吃苹果这里的“转换成可读文字”，不是把输入的“我喜欢吃苹果”还原出来，而是把模型新生成的编号转换成我们看得懂的回答。模型生成的是一串 Token，程序把它们解码成文字，最后显示在聊天窗口里。
Token 很重要，因为模型一次能处理多少内容，以及很多模型服务的费用，都会和 Token 数量有关。Token 不等于汉字数，也不等于英文单词数。
所以，最后的流程图为：
输入文字 ↓ 分词器切分 输入 Token ↓ 转换成编号后交给模型处理 模型生成新的 Token ↓ 分词器将生成的 Token 解码成文字 输出文字三、模型训练
不同模型的训练方式不完全一样。入门时可以先了解三个常见阶段。它们可以帮助我们理解：模型怎么先学会语言，又怎么学会按照人的要求回答。
1. 预训练
预训练可以理解为让模型读大量文本，并反复练习“根据前面的内容猜后面的 Token”。
例如看到：
春天到了，树上的花模型要根据前面的内容，预测后面可能是什么。它不是只背这一句话，而是在大量文本中反复练习类似的预测，逐渐学会语言规律、常见表达和内容之间的关联。
预训练主要让模型获得基础的语言能力，但这时的模型不一定很会听从指令。你给它一个问题，它有时可能只是接着你的问题继续写，而不是认真回答问题。
2. 指令微调
指令微调，就是给模型看很多“别人提出的要求”和“符合要求的示范答案”，让它学会按要求完成任务。
例如训练材料可能是：
要求：把“早上好”翻译成英文。 示范答案：Good morning.模型看过大量类似例子后，就更会理解“翻译”“总结”“用列表回答”这类要求。简单说：
预训练：练习根据前文接着生成内容 指令微调：练习看到要求后，按要求给出答案“微调”表示在已有模型的基础上继续训练、调整模型；它和写 Prompt 不同。写 Prompt 是使用模型时给它补充要求，不会因此直接修改模型本身。
3. 偏好对齐
偏好对齐确实和反馈有关，但“反馈”和“偏好对齐”不是同一个东西：
- 反馈：告诉训练者，哪个回答更好、哪个回答不合适。
- 偏好对齐：把这些反馈用于训练，让模型之后更倾向于生成大家偏好的回答。
例如，给模型同一个问题，让它生成两个回答：
问题：用一句话解释什么是 Token。 回答 A：Token 是模型处理文本的单位。 回答 B：Token 是模型处理文字时使用的小片段，可以把它想成模型读写内容时的小积木。如果评估者认为回答 B 对初学者更清楚，就可以把“B 比 A 更好”作为反馈。训练时，模型会利用大量这样的偏好反馈，逐渐学会什么样的回答更有帮助、更清楚或更符合要求。
这和指令微调的区别可以简单看成：
指令微调：给模型看一个问题和示范答案 偏好对齐：给模型看多个回答，并告诉它哪个更好偏好对齐不是说用户在聊天时说一句“不好”，模型就会立刻自动学会。通常需要收集反馈，再经过训练，模型参数才会改变。RLHF、DPO 是实现偏好对齐的不同方法名称，入门时先知道它们和“利用反馈调整模型”有关即可。
四、Context Window
Context Window（上下文窗口）是模型一次能够处理的上下文容量，通常按 Token 数量计算。
可以把它理解成模型这一次能看到的内容。用户的问题、之前的对话、给模型的指令和参考资料，都可能放在里面。模型回答时，会根据这些当前能看到的内容来生成结果。
例如，你先告诉模型：
请用中文回答，最多三句话。之后再提问题，只要这条要求还在模型当前能看到的上下文里，它就可以参考这条要求。
但如果对话变得很长，早期的内容可能因为上下文容量限制而没有继续带给模型。模型没看到的内容，就不一定能在后续回答中记住。
Context Window 是模型这一次能处理的内容，不等于模型的长期记忆。
上下文窗口越大，模型一次可以处理的内容通常越多；但这不代表模型能永远记住这些内容，也不代表它一定能准确利用其中的每个细节。
五、Prompt
Prompt 是提供给模型的任务说明和相关内容。它可以包含问题、背景、规则以及你希望的回答方式。
比如只说：
帮我写 SQL。模型不知道应该查哪些表、允许什么操作、结果要什么格式。把要求补充清楚，就更容易得到符合预期的回答。
下面是一个数仓场景的 Prompt：
你是一名数仓开发工程师。 要求： 1. 只能查询 DWS 层 2. 禁止 SELECT * 3. 禁止 INSERT、UPDATE、DELETE 4. SQL 使用小写 用户问题： 查询昨天销售额最高的10家门店。这段 Prompt 不只是最后的用户问题。前面的角色和规则、需要完成的具体任务，都属于给模型的输入内容。相比只说“帮我写 SQL”，这些要求能让模型更清楚需要做什么、要遵守什么限制。
再看一个简单例子：
请用通俗易懂的语言解释 Python 列表推导式，并给一个简单例子。这比只问“列表推导式是什么？”更具体，因为它还告诉模型：回答要简单，并且要举例。
Prompt 不一定越长越好。重点是把任务、必要背景和要求讲清楚；无关内容太多，反而可能让模型抓不住重点。
六、System Prompt
System Prompt 是给模型设定整体角色或行为要求的一种消息。可以把第五部分的数仓 Prompt 拆开来看：
System： 你是一名数仓开发工程师。 要求： 1. 只能查询 DWS 层 2. 禁止 SELECT * 3. 禁止 INSERT、UPDATE、DELETE 4. SQL 使用小写 User： 查询昨天销售额最高的10家门店。 Assistant： 根据要求生成 SQL。这里，System 里的内容是给模型设定的角色和规则；User 里是用户这次提出的问题；Assistant 是模型生成的回答。
可以把它想成：System 先告诉模型“回答时要遵守什么规则”，User 再告诉模型“这次要做什么”。System Prompt 仍然是输入给模型的指令，不是重新训练模型。不同模型服务的具体消息格式可能有所不同。
七、回答生成
LLM 生成回答时，会根据已经看到的内容，预测下一个 Token；选出一个之后，再把它接到当前内容后面，继续预测下一个。这个过程重复很多次，直到回答结束。
当前上下文 ↓ 预测下一个 Token ↓ 把它接到回答后面 ↓ 根据更新后的上下文，再预测下一个 Token ↓ 重复，直到回答结束例如模型已经生成了：
今天天气很接下来它可能生成“好”，也可能生成“冷”。选出一个之后，模型会把它放回当前内容里，再决定接下来生成什么。
所以，LLM 不是每次都先找出一个完整的标准答案再回复，而是一步步生成内容。这是它能够写出新句子的原因，也是它有时会偏离主题或生成错误内容的原因之一。
八、Temperature
Temperature 是影响模型生成方式的参数之一。可以先把它理解为：它会影响模型选择下一个 Token 时，是更倾向于选最常见、最可能的内容，还是允许更多不同选择。
Temperature 较低：选择通常更集中，回答往往更稳定 Temperature 较高：选择可能更多样，回答变化也可能更大比如让模型给一个程序变量命名：
- Temperature 较低时，可能更常给出
user_name这类常见名字。 - Temperature 较高时，可能给出更多不同风格的名字。
这只是帮助理解的例子，实际效果还会受到模型和任务影响。Temperature 不是“正确性旋钮”：调低不保证答案正确；它也不是简单的“创造力旋钮”：调高不一定让答案更有创意。
Top-p、Top-k 也是影响模型如何选择下一个 Token 的参数。可以先知道它们和生成选择有关，后续需要调参时再深入了解。
九、幻觉
幻觉是指模型生成了听起来合理、表达流畅，但实际上错误或没有依据的内容。
例如，模型不知道某家公司内部的销售额口径，却根据常见说法编出一个答案。它可能说得很肯定，但内容并不符合这家公司的实际规定。
为什么会出现幻觉？因为模型主要是在根据上下文生成“看起来合适”的内容，并不会自动核实自己说的每件事。如果问题缺少背景、说法含糊，或者需要模型回答它并不知道的事实，它就可能用一个看似合理的答案把空白补上。
LLM 很会组织语言，但它不会自动核实自己说的每一件事。
因此，不能只看回答是否通顺、语气是否肯定，还要检查内容有没有依据。尤其是精确数字、业务规则和重要事实，不能因为模型回答得流畅就直接当成事实。
十、模型不是越大越好
这也是 AI 应用开发很重要的认知。
假设有两个模型：
模型 A：100 元 / 1M Tokens 模型 B：10 元 / 1M Tokens以上价格只是举例，不代表实际模型报价。
如果任务只是判断用户输入是不是“查询销售数据”，就没必要上最贵的模型。一个小模型做好分类就够了：
用户输入 ↓ 小模型分类 ↓ 是不是查询销售数据但是，如果用户说：
帮我分析过去三年的销售数据，并找出异常原因。这个任务需要理解更长的上下文、分析数据并解释原因，可能就需要能力更强的模型。
所以，做 AI 应用时，要结合业务需求选择模型，再设计 Prompt、Context，以及需要使用的 RAG 或工具：
业务需求 ↓ 选择模型 ↓ Prompt ↓ Context ↓ RAG / Tool ↓ LLM ↓ 结果到这里，应该形成一个重要的认识：
LLM 不等于 AI 应用。
LLM 更像一个很强的“通用智能能力组件”。AI 应用开发者要做的是把它和业务需要的知识、工具及系统连接起来：
AI 应用 │ ┌──────────────┼──────────────┐ ↓ ↓ ↓ RAG Tool Calling Agent │ │ │ └──────────────┼──────────────┘ ↓ LLM ↓ 数据库 / API / 文件
