基础能力：模型、上下文与推理

本页解释所有后续内容的共同底座。若不了解这些概念，很容易把“模型能力不足”“上下文不够”“检索没找到”“推理服务太慢”混为一类问题。

LLM：生成与推理的主体

问题	说明
是什么	基于 Transformer 的语言模型，根据已有 token 预测下一个 token。
解决什么	理解/生成文本、代码、结构化输出，以及基于给定上下文进行归纳和推理。
输入	系统规则、用户问题、对话历史、RAG 召回内容、工具结果。
输出	文本、结构化数据、工具调用请求或拒答。
不擅长什么	实时事实、私有知识、精确关系和未经提供的证据；这些需要外部知识系统。

模型参数中存的是训练得到的“能力与通用模式”，不是一套可精确查询、可随时更新的企业数据库。因此新规程、新设备、现场案例通常通过 RAG 或结构化系统注入，而不是只靠换一个更大模型。

Token、Prompt 与生成参数

Token 是模型处理文本的最小单元，不等同于汉字或单词。Prompt 是发给模型的完整输入，包含系统提示、用户问题、示例和上下文。

参数	改变什么	常见误区
Temperature	输出随机性；越高越发散。	不能修复没有检索到证据的问题。
Top-P	限制采样候选范围。	不应和 Temperature 一起盲目调大。
Max tokens	最大输出长度。	设太小会截断答案，设太大增加成本和等待。
System Prompt	长期规则、角色和输出边界。	不是知识库；写太长会挤占上下文。

Context：模型当前能看到的信息

Context 包含系统提示、聊天历史、工具返回和 RAG 片段。Context Window 是一次请求可容纳 token 的上限。

Context 越长，不代表回答必然越好：它会提高显存/成本，并可能让关键信息被噪声淹没。正确做法是用检索、压缩和结构化信息把“最相关且可信的少量证据”放入上下文。

KV Cache：为什么长上下文和并发吃显存

模型生成下一个 token 时会参考之前所有 token。KV Cache 保存历史 token 已计算出的注意力键和值，避免每次重复计算，因此可以加速逐 token 生成。

代价是：上下文越长、并发请求越多、模型层数/维度越大，KV Cache 占用越高。vLLM 的 PagedAttention 和 Ollama 的并发/上下文设置，本质上都在管理这部分内存。

Embedding 与 Reranker：不是回答模型

组件	输入与输出	解决什么
Embedding 模型	文本 → 固定维度向量	用“语义距离”找候选文档。
向量库	查询向量 → Top-K 候选片段	在大量片段中快速召回。
Reranker	问题 + 候选片段 → 相关性排序	从候选中找出最适合放入 Context 的证据。
LLM	问题 + 最终上下文 → 回答	组织答案、解释和引用。

这四者串成 RAG。若答案错误，需先定位是哪一环失败，而不是默认“模型不够聪明”。