大语言模型
LLMLarge Language Model
用海量文本训练出来的“下一个 token 预测器”，它把语言规律和常识压进了参数里。
类比：一个读遍图书馆、特别会接话的人。
在本作品：真实的“生成”这一步由 LLM 完成；本页用规则引擎模拟，保证离线可跑。
作业一 · 查资料小助手
把运动手册，变成
把运动手册，变成
一个会查资料的教练
我是「燃动」。你把训练问题丢给我，我先在内置的 71 条运动资料里检索最相关的片段，再按「结论—步骤—注意」回答，并标明依据。 不联网、不上传，双击这个 HTML 文件就能用。
所有检索与回答都在你的浏览器里完成，关掉网络也能运行。
燃动教练
本地知识库已就绪
Enter 发送 · Shift+Enter 换行
回答仅基于手册资料，找不到会直说
运动手册 · 知识库
这些就是小助手的“资料库”：全部内嵌在本网页里，按主题分好，随时可查。共 71 条、11 个主题，覆盖训练、营养、伤痛与特殊人群。
71 条资料
11 个概念，读懂它在想什么
从“拆字”到“查资料”的四个关卡：Token → 上下文 → 提示词 → RAG。每个词都配了生活类比，以及它在本作品里的位置。
词元
TokenToken
模型读写文本的最小单位。可能是一个字、半个词、一个标点，甚至一个 emoji。
类比：乐高积木，句子由一块块积木拼成。
在本作品：侧栏的上下文占用、每条资料的规模，都按 token 估算。
分词器
TokenizerTokenizer
把字符串切成 token 的程序。不同模型的词表不同，切法也不同，所以同一个句子在不同模型里 token 数可能不一样。
类比：同一根萝卜，不同厨师切出来的块大小不同。
在本作品：下方的“拆解器”演示了切分过程（简化版，非真实 BPE）。
文本 ↔ token
Encode / DecodeText ↔ Token
文本变成 token id 叫编码；模型算完 token id 再变回文字叫解码。模型看到的从来不是“字”，而是数字。
类比：摩斯电码，点和划对应字母，收发双方用同一张表。
在本作品：资料入库前先分词建索引，回答时再把结果还原成人话。
上下文
ContextContext
模型这一次能看到的全部内容：系统提示、历史对话、检索到的资料、你刚问的问题。
类比：开卷考试时，摊在桌上的所有纸。
在本作品：点开「Prompt 预览」，三段合起来就是这次完整的上下文。
上下文窗口
Context WindowContext Window
一次能装下的最大 token 数。超出上限的内容会被截断或“忘记”，这就是聊久了它不记得开头的原因。
类比：一张只能贴 N 张便利贴的桌子，贴满了就得撕掉旧的。
在本作品：侧栏的 128K 进度条，以及下面可以拖动的滑杆。
提示词
PromptPrompt
你发给模型的指令文本，是它这次任务的输入。同一个模型，换个说法，输出可能完全不同。
类比：点菜单上写的那几行字。
在本作品：输入框里的每个问题，都是一个 prompt。
提示工程
Prompt EngineeringPrompt Engineering
用角色、任务、约束、输出格式、示例把指令写清楚，让模型的输出更稳定、更符合预期。
类比：把“随便弄一下”改成一份写得清清楚楚的需求文档。
在本作品：System Prompt 里的 5 条规则和「结论—步骤—注意—依据」格式。
用户提示词
User PromptUser Prompt
本次对话里的具体请求，通常放在最后。它优先级低于系统提示，不能推翻系统设定的边界。
类比：这一单具体点什么菜。
在本作品：你输入的内容会原样进入【用户问题】段落。
系统提示词
System PromptSystem Prompt
设定人设、能力边界与输出规则的“底层设定”，贯穿整段对话，优先级最高。
类比：员工手册，决定“你是谁、能做什么、不能做什么”。
在本作品：「燃动」教练人设、只依据资料、不诊断、不编造。
检索增强生成
RAGRetrieval-Augmented Generation
先从知识库检索相关片段，再把片段放进上下文，让模型“开卷”回答，并标注依据。
类比：开卷考试，先翻书找到那一页，再动笔答题。
在本作品：BM25 检索 → 取前 2 条 → 拼进 Prompt → 回答并标注来源。
动手试试：4 个小实验
概念看一遍不算会，拖一拖、点一点，感受会更具体。
Token 拆解器 关卡 1
输入一句话，看它被切成多少块。真实 Tokenizer 用 BPE，这里用简化词表演示“切分”这件事。
0 块（演示分词）
0 tokens（估算）
估算按“1 个汉字 ≈ 0.68 token、1 个英文单词 ≈ 1.25 token”粗略计算。同一个词在不同模型里可能被切得不同，这也是为什么“按 token 计费”时中英文价格不一样。
上下文窗口 关卡 2
把窗口想成一张便利贴桌子。拖动“对话轮数”，看它什么时候装不下。
8 轮 · 7.6K
桌子还很空，所有内容都在窗口里。
演示按每轮约 900 tokens 估算，上限 128,000。真实产品常见 64K / 128K / 200K，窗口越大越贵，也越容易“抓不住重点”。
同一条需求，两种 Prompt 关卡 3
目标一样，写清楚角色、约束和格式，输出就更能直接用。
PROMPT A · 直白版
给我一个减脂计划。
模型不知道你是谁、能练几天、有没有器械、哪里受过伤，只能给一份“放之四海而皆准”的套话。
PROMPT B · 结构化版
角色：带过 200 名上班族的健身教练。 任务：给 30 岁、每周只能练 3 次、每次 40 分钟的人，排 4 周减脂计划。 约束：只有一对哑铃和自重；不节食；每周减重不超过 1%；有膝痛史，避免跳跃。 输出：表格，列为「周次 / 训练日 / 动作与组次 / 有氧 / 饮食要点」。
角色决定语气与取舍，约束让方案可执行，格式让结果可直接抄进日程表。
RAG 的四步流水线 关卡 4
“先查资料、再回答”，比直接问靠谱。小助手每次回答都会走这四步。
1
问题分词
把问题切成词元，并扩展同义词。
2
BM25 检索
在 71 条资料里算出最相关的 Top-K。
3
拼进 Prompt
资料编号后放进上下文，交给模型。
4
带依据回答
结论、步骤、注意，末尾标来源。
找不到怎么办？ 检索分数低于阈值时，小助手会直接说“没有找到足够相关的资料”，而不是硬编一个答案——这是 RAG 比“裸问”更可靠的地方。