模型基础与上下文
理解 Token、上下文与生成过程，为一次可核对的模型请求准备材料。
模型怎样处理文字
大语言模型把输入转换为 Token 序列，再根据已有上下文生成后续内容。Token 可能对应一个词、词的一部分或其他文本片段，不能用“一个汉字等于一个 Token”作为固定换算规则。Hugging Face 的模型基础课程介绍了这一过程。
生成内容与训练中学到的模式有关。回答流畅只能说明表达连贯，事实是否成立仍要与材料、计算结果或外部来源核对。
上下文里应该放什么
一次请求通常需要任务说明、相关材料、用户问题与必要的历史。输入材料和预期输出都需要考虑模型的上下文限制；不同服务对可用输入、输出及缓存的计算方式可能不同，应查看实际接口说明。
在资料问答案例中，可以准备这样的请求清单：
| 内容 | 放入什么 | 本例怎么取舍 |
|---|---|---|
| 任务 | 根据项目材料回答问题 | 明确只能依据本次提供的材料 |
| 材料 | 编号、时间、原文 | 只放与试运行相关的段落 |
| 问题 | 用户的具体疑问 | “试运行安排在哪一天？” |
| 输出要求 | 答案与来源 | 有冲突就列出冲突，缺材料就说明 |
一次手动实验
下面是本站设计的虚构材料：
材料 P-01，版本 1：试运行暂定在 11 月 6 日。
材料 P-02，版本 2：经确认，试运行调整为 11 月 9 日。
任务：仅依据材料回答试运行日期。
回答时说明采用哪个版本，并保留原日期的变更记录。先只提供 P-01，再加入 P-02，比较两次回答。检查模型是否指出版本变化，而不是把两个日期混成一个未经说明的结论。
选模型时比较实际任务
为这个案例挑选模型，可以保留同一份材料和问题，记录来源是否正确、格式是否稳定、响应耗时与实际调用量。先建立一个能完成任务的基线，再决定是否需要更长上下文或更复杂的能力。
不要只比较一次回答。材料换成表格、问法换一种表达，或者问题根本没有答案，都应进入后面的评估集。
动手检查
- 用实际服务的计数方式确认请求规模，为输出留下空间。
- 核对材料编号、版本和原文是否完整。
- 检查答案中的日期、数字和实体是否都能找到依据。
下一步：提示词设计，把这些材料组织成可重复使用的任务说明。