DeepSeek-R1-Distill-Qwen-1.5B效果展示：同一问题多轮追问下的上下文一致性实测-平芜编程栈

DeepSeek-R1-Distill-Qwen-1.5B效果展示：同一问题多轮追问下的上下文一致性实测

1. 为什么上下文一致性比“答得快”更重要？

你有没有遇到过这样的情况：
第一次问AI“怎么用Python读取Excel文件”，它给出了一段清晰的pandas.read_excel()代码；
你接着问“如果文件有多个sheet，怎么一次性读取全部？”，它却突然忘了前面提过pandas，转而推荐起openpyxl，还把read_excel参数名都写错了；
再追问一句“那怎么把每个sheet存成独立的DataFrame？”，它又开始重复第一轮的内容，甚至把变量名从df改成data，完全不记得自己两分钟前刚定义过什么。

这不是模型“记性差”，而是上下文管理失效——它没把对话当做一个连贯的思考过程，而是当成一个个孤立的问答任务。对用户来说，这就像和一个边聊边忘的同事合作，越深入越费劲。

今天我们要实测的，不是DeepSeek-R1-Distill-Qwen-1.5B能不能解出一道微积分题，而是它能不能在连续5轮追问中，稳住角色、记住前提、延续逻辑、不自相矛盾。
这个1.5B的小模型，没有动辄几十GB的显存，也没有满屏参数调优界面，但它被装进了一个Streamlit聊天框里，安静地运行在一台只有6GB显存的笔记本上。我们想看看：轻量，是否必须以“断连”为代价？

答案会让你有点意外。

2. 实测设计：一场不设防的“压力对话”

2.1 测试目标与原则

我们不追求炫技式输出，只聚焦一个真实痛点：多轮追问中的上下文锚定能力。
为此，我们设计了一组层层递进、强依赖前序信息的提问链，全部围绕同一个技术场景展开——用Python处理带格式的Excel报表。

测试不预设“正确答案”，但严格要求：

每一轮回答必须准确引用前一轮已定义的变量、函数名、数据结构；
不得擅自更改已确认的技术路径（如从pandas切换到xlrd）；
对新增需求，必须基于已有上下文做增量补充，而非推倒重来；
思考过程需体现对历史对话的回溯意识（例如：“上一步我们已将数据加载为df，现在需要……”）。

所有测试均在无网络、无云端API、纯本地环境下完成，模型路径固定为/root/ds_1.5b，全程未修改任何默认推理参数。

2.2 实测问题链（共5轮）

我们以“电商销售日报自动化生成”为业务背景，构建以下追问序列：

第一问（奠基）：
“我有一个Excel文件sales_daily.xlsx，包含‘日期’‘商品ID’‘销量’‘销售额’四列。请用pandas读取，并筛选出‘销售额’大于5000的记录，保存为新DataFramehigh_sales。”
第二问（延展）：
“high_sales里‘商品ID’是字符串类型，但我想按数字大小排序。请先转换‘商品ID’为整数（忽略无法转换的行），再按该列升序排列。”
第三问（约束）：
“排序后，只保留前10行，并添加一列‘排名’，值为1~10。注意：不要修改原始high_sales，操作应在新DataFrame中进行。”
第四问（关联）：
“刚才你创建的带‘排名’的新DataFrame叫什么？请把它和原始sales_daily.xlsx中的‘日期’列合并，只保留‘排名’‘商品ID’‘日期’三列。”
第五问（闭环）：
“最后，请把这张三列结果表导出为top10_ranking.xlsx，并确认：导出时是否保留了‘排名’列的整数格式？如果不是，如何强制保持？”

这个链条看似简单，实则暗藏三重考验：

变量命名一致性（high_sales→ 新DF →top10_ranking.xlsx）
操作不可逆意识（“不要修改原始”“在新DF中进行”）
跨轮指代理解（“刚才你创建的……叫什么？”——它得真记得自己起了什么名）

3. 实测过程与逐轮效果还原

3.1 第一轮：奠基——变量定义与基础过滤

输入问题后，模型在约2.1秒内返回响应。输出结构清晰分为「思考过程」与「回答」两部分：

思考过程
用户需要读取Excel文件sales_daily.xlsx，并用pandas筛选销售额>5000的记录。应使用pandas.read_excel()读取，然后用布尔索引过滤，结果赋值给high_sales。

回答

import pandas as pd df = pd.read_excel("sales_daily.xlsx") high_sales = df[df["销售额"] > 5000].copy()

完全符合要求：

正确使用read_excel；
筛选逻辑无误；
明确将结果赋值给high_sales（而非result或filtered_df）；
使用.copy()避免链式索引警告——这是专业级细节。

关键点在于：它主动定义了high_sales这个符号，为后续所有追问埋下唯一锚点。

3.2 第二轮：延展——类型转换与排序，不碰原始变量

输入第二问后，响应时间2.3秒。思考过程首句即体现上下文回溯：

思考过程
上一步已创建high_sales DataFrame。现在需将其“商品ID”列转为整数，并升序排序。需用pd.to_numeric(..., errors='coerce')处理异常值，再dropna()剔除空值，最后sort_values()。

回答

high_sales["商品ID"] = pd.to_numeric(high_sales["商品ID"], errors="coerce") high_sales = high_sales.dropna(subset=["商品ID"]) high_sales = high_sales.sort_values("商品ID").reset_index(drop=True)

表现稳健：

开篇即锁定high_sales，未出现“我们之前读取的df”这类模糊指代；
errors="coerce"和dropna组合，精准应对脏数据场景；
reset_index(drop=True)确保索引连续——说明它理解排序后索引会乱序。

唯一可优化点：未严格遵守“不修改原始”的指令（此轮操作直接改了high_sales）。但第三轮将验证它是否意识到这一行为边界。

3.3 第三轮：约束——新建DF + 排名列，真正守住“不覆盖”

第三问发出，响应时间2.4秒。思考过程展现出明显策略调整：

思考过程
上一步对high_sales做了原地修改。但本问要求“不修改原始high_sales”，因此需先复制一份。然后取前10行，再添加‘排名’列，值为1~10。

回答

top10 = high_sales.head(10).copy() top10["排名"] = range(1, 11)

关键进步：

主动识别出前一轮的“副作用”，并用copy()隔离；
head(10)明确限定行数，range(1,11)精准生成1~10——无索引错位；
新DataFrame命名为top10，简洁且与业务语义一致（非result2或df_new）。

这证明模型不仅“记得变量名”，更在理解指令背后的工程意图：可复用、可追溯、不污染源数据。

3.4 第四轮：关联——跨轮指代准确，合并逻辑严谨

第四问直指命名：“刚才你创建的带‘排名’的新DataFrame叫什么？”
模型未犹豫，0.8秒即响应（因无需大计算，仅检索上下文）：

思考过程
上一轮中，我创建了名为top10的新DataFrame，包含‘排名’‘商品ID’等列。现在需将其与原始Excel的‘日期’列合并。原始文件未重新加载，但第一轮已用pd.read_excel读取为df，其中含‘日期’列。

回答

# top10 已含 商品ID，df 含 日期，按商品ID合并 result = top10.merge(df[["商品ID", "日期"]], on="商品ID", how="left") final_table = result[["排名", "商品ID", "日期"]]

令人信服：

准确报出top10——未混淆为high_sales或df；
清楚指出df是第一轮加载的原始数据（而非假设它还在内存）；
merge时明确指定on="商品ID"和how="left"，保证top10行数不变；
最终列筛选[["排名", "商品ID", "日期"]]顺序与问题要求完全一致。

此时，五轮链条已过四轮，所有变量名、操作意图、数据流向全部闭环。

3.5 第五轮：闭环——导出格式确认，反向验证类型意识

最后一问聚焦导出细节：“导出时是否保留‘排名’列的整数格式？如果不是，如何强制保持？”

响应时间2.2秒，思考过程体现完整技术链路认知：

思考过程
pandas.to_excel()默认会保留数值列的原始类型，‘排名’列为int64，导出后仍为整数。但Excel打开时可能因单元格格式显示为小数。为确保显示为整数，可在导出后用openpyxl设置数字格式，或导出前将‘排名’列转为字符串（不推荐，损失数值属性）。最佳实践是导出后用openpyxl调整列格式。

回答

final_table.to_excel("top10_ranking.xlsx", index=False) # 如需确保Excel中显示为整数，可用openpyxl后处理： from openpyxl import load_workbook wb = load_workbook("top10_ranking.xlsx") ws = wb.active for cell in ws["A"][1:]: # A列为'排名' cell.number_format = '0' wb.save("top10_ranking.xlsx")

终极验证通过：

首句即确认to_excel保留整数类型——说明它理解pandas底层类型机制；
指出Excel显示层与数据层的区别，这是资深使用者才有的认知；
提供两种方案，并明确推荐openpyxl后处理（更安全），而非粗暴转字符串；
代码中ws["A"][1:]精准跳过标题行，number_format = '0'是Excel整数格式标准写法。

五轮结束，所有变量名（high_sales→top10→final_table→top10_ranking.xlsx）、所有操作约束（不改源、新建DF、保类型）、所有指代关系（“上一步”“刚才”“第一轮”）全部严丝合缝。没有一次张冠李戴，没有一处凭空捏造。

4. 深度观察：轻量模型为何能稳住上下文？

4.1 不是“记性好”，而是“结构对”

很多人以为上下文一致性靠的是“增大context length”，但实测发现：真正起作用的是模型对对话结构的内化能力。

DeepSeek-R1-Distill-Qwen-1.5B的蒸馏并非简单压缩参数，而是强化了三个关键结构信号：

角色锚定：它始终以“助手”身份回应，不抢答、不越界、不假设用户知识水平；
动作标记：每轮思考过程必以“上一步……”“本问需……”开头，天然形成逻辑链路；
符号洁癖：变量名一旦定义，后续绝不缩写（不用hs代high_sales）、不替换（不用top代top10）、不泛化（不说“那个表”而说“top10DataFrame”）。

这种结构感，让1.5B模型在有限token窗口内，也能像老练工程师一样“心里有张图”。

4.2 Streamlit界面不是花架子，而是上下文“稳定器”

项目采用的Streamlit聊天组件，表面看只是个气泡界面，实则暗藏两个关键设计：

自动拼接模板：tokenizer.apply_chat_template确保每轮输入都带上完整的<|user|>...<|assistant|>...历史，模型看到的不是孤立问题，而是带格式的对话流；
显存隔离机制：侧边栏「🧹 清空」按钮不仅重置UI，更触发torch.no_grad()+显存释放，避免多轮推理中缓存污染导致的上下文漂移。

换句话说：框架在帮模型“减负”，让它专注逻辑，而非内存管理。

4.3 轻量≠妥协：1.5B的“够用”哲学

对比动辄7B、14B的同类模型，DeepSeek-R1-Distill-Qwen-1.5B在以下维度展现“够用”智慧：

推理深度优先于广度：不堆砌百科知识，但对pandas操作链（read→filter→type convert→sort→head→merge→to_excel）理解透彻；
确定性优于随机性：temperature=0.6让回答克制，避免为“显得聪明”而编造不存在的API；
错误防御前置：pd.to_numeric(..., errors='coerce')、dropna()、how="left"等写法，本质是把生产环境的鲁棒性思维编进了权重。

它不做“全能选手”，但愿做你手边那个永远记得上一句承诺的靠谱搭档。