DeepSeek 生成全量字典与混合方案实验报告

前一轮实验把 DeepSeek 放在“查询时过滤候选概念和关系”的位置，结果说明它很适合做噪声过滤器。这一轮继续往前推一步：如果不只在查询时调用模型，而是让 DeepSeek 直接参与“全量标准字典生成”，字典本身会不会变得更干净？如果再叠加查询时过滤，能不能得到更稳定的检索排序？

本文保留实验方法、核心指标和结论，但不公开本地路径、运行日志路径和内部产物路径。

一、实验目标

本轮实验分两步。

第一步让 DeepSeek 直接参与“全量标准字典生成”：

基于 595 条资源目录生成新的全量字典。
保留原有概念 ID 和表覆盖范围，保证可以和前面实验直接对比。
让 DeepSeek 重写概念名、描述、别名、字段关键词和关系。
使用同一套 100 条评测问题重新评估。

第二步验证混合方案：

1
2
3

DeepSeek 离线生成全量字典
+ 查询时 DeepSeek 过滤候选概念和关系
= 混合方案

也就是说，既让字典本身更干净，又让模型在具体问题上继续做一次“是否真相关”的判断。

二、实验产物

本轮实验涉及三类产物：

产物	说明
DeepSeek 生成全量字典	由 DeepSeek 基于工程规则种子字典改写后得到
DeepSeek 生成字典评测结果	使用 100 条评测问题评估离线生成字典效果
混合方案评测结果	在 DeepSeek 生成字典基础上，再加入查询时 DeepSeek 候选过滤

公开文章里不列具体产物路径，只讨论方法、指标和可复用结论。

三、生成方法

DeepSeek 生成字典时使用了原工程全量字典作为种子，但不是简单复制。处理逻辑如下：

  flowchart LR
  A["595 条资源目录"] --> B["工程规则种子字典"]
  B --> C["按批次发送给 DeepSeek"]
  C --> D["重写概念名、描述、别名、字段关键词"]
  D --> E["保留 preferredTables 和 catalogEntries"]
  E --> F["按业务域生成高置信关系"]
  F --> G["DeepSeek 全量字典"]
  G --> H["100 条问题评测"]
  G --> I["查询时 DeepSeek 过滤候选"]
  I --> J["混合方案评测"]

这样做的原因是：如果完全让大模型自由生成，概念 ID、表覆盖范围和评测任务很难对齐；保留 ID 和表覆盖后，实验结果更可比较。

四、字典规模

项目	数量
资源目录条数	595
概念数	488
DeepSeek 成功生成概念数	372
fallback 概念数	116
唯一优先表数	577
alias 总数	3380
唯一 alias 数	2569
字段关键词数	1461
唯一字段关键词数	842
关系数	171
生成错误数	2

其中 2 个批次出现网络请求失败，脚本保留了 fallback 结果，所以全量字典仍然完整覆盖 488 个概念和 577 张唯一优先表。

五、指标对比

模式	P@1	P@3	P@5	P@10	R@5	MRR	conceptRecall	relationAccuracy
无字典	0.800	0.397	0.264	0.143	0.849	0.848	-	-
工程规则标准字典	0.790	0.333	0.210	0.127	0.746	0.822	0.880	0.120
工程规则关系增强字典	0.790	0.333	0.210	0.127	0.746	0.822	0.880	0.860
DeepSeek 生成标准字典	0.800	0.353	0.240	0.147	0.796	0.831	0.850	0.120
DeepSeek 生成关系字典	0.800	0.353	0.240	0.147	0.796	0.831	0.850	0.137
运行时 DeepSeek 辅助字典	0.860	0.403	0.266	0.158	0.862	0.887	0.860	0.186
混合方案	0.890	0.453	0.298	0.166	0.895	0.913	0.840	0.133

六、结果解读

DeepSeek 生成字典比工程规则字典更好。它的 P@5 从 0.210 提升到 0.240，R@5 从 0.746 提升到 0.796，MRR 从 0.822 提升到 0.831。

这说明 DeepSeek 在“整理别名、减少字段关键词噪声、重写概念描述”方面有帮助。DeepSeek 生成字典的字段关键词数从工程规则字典的 4550 降到 1461，说明它确实做了收敛和去噪。

但是 DeepSeek 生成字典仍然没有超过无字典，也没有超过“运行时 DeepSeek 辅助字典”。原因主要有四个：

生成字典是离线静态产物，它不知道每个用户问题的具体意图。
运行时 DeepSeek 可以看到当前问题，因此能判断哪些概念该保留、哪些概念该拒绝。
离线关系生成比较保守，只生成了 171 条关系，关系覆盖明显低于工程规则关系增强字典。
116 个概念因网络失败走了 fallback，仍然保留了一部分工程规则噪声。

混合方案是本轮最佳结果。相比“运行时 DeepSeek 辅助字典”，混合方案继续提升：

指标	运行时 DeepSeek 辅助	混合方案	提升
P@1	0.860	0.890	+0.030
P@3	0.403	0.453	+0.050
P@5	0.266	0.298	+0.032
R@5	0.862	0.895	+0.033
MRR	0.887	0.913	+0.026

这说明“离线字典质量”和“运行时问题理解”是互补的：

离线 DeepSeek 生成字典减少了通用字段词和弱别名噪声。
运行时 DeepSeek 根据具体问题继续过滤候选概念。
两者结合后，正确表更容易排到前 1、前 3、前 5。

七、和前一轮 DeepSeek 辅助的区别

方案	DeepSeek 做什么	优点	缺点
DeepSeek 生成全量字典	离线生成概念名、别名、字段关键词、关系	字典本身更干净，可复用	不知道具体问题，过滤能力有限
运行时 DeepSeek 辅助字典	针对每个问题判断候选概念和关系	最贴合当前问题，排序最好	每次查询都要调用模型，成本更高

因此，当前实验支持混合方案：

1
2
3

DeepSeek 离线生成更干净的标准字典
+ 查询时再用 DeepSeek 做候选过滤
= 覆盖、质量和排序效果更均衡

混合方案的运行时判定也更保守：

项目	数值
平均接受直接概念数	0.91
平均接受关系概念数	0.03
LLM 任务错误数	0
LLM 阶段错误数	0

这说明 DeepSeek 生成字典本身已经比工程规则字典更干净，运行时模型不需要接受太多候选概念，就能得到更好的排序。

八、单条样例观察

在一个教学质量管理相关样例中，用户希望定位“学生期末评价完成状态”相关数据。DeepSeek 生成字典仍然只在 Top 5 命中 1 个正确表，但混合方案能命中 2 个：

模式	P@5	R@5	MRR
无字典	0.000	0.000	0.000
工程规则标准字典	0.200	0.500	1.000
DeepSeek 生成标准字典	0.200	0.500	1.000
运行时 DeepSeek 辅助字典	0.400	1.000	1.000
混合方案	0.400	1.000	1.000

这个样例说明：仅靠离线生成字典，还不能完全解决“同一概念下多张优先表成组前置”的问题。运行时 DeepSeek 之所以更好，是因为它在当前问题里拒绝了泛化概念，只保留了精确概念。混合方案继承了这个优点，同时整体指标更好。

九、结论

本轮实验结论：

DeepSeek 可以生成全量字典，覆盖 595 条资源目录和 488 个概念。
DeepSeek 生成字典比纯工程规则字典更干净，排序指标也更好。
但离线生成字典不如运行时 DeepSeek 辅助过滤。
混合方案取得当前最好结果，P@1 = 0.890、P@5 = 0.298、R@5 = 0.895、MRR = 0.913。
最合理的方向是“离线 DeepSeek 生成字典 + 在线 DeepSeek 过滤候选 + 人工复核关键样本”。

下一步建议：

对 fallback 的 116 个概念单独重跑生成，减少工程规则残留。
在排序逻辑里增加“高置信概念的 preferredTables 成组前置”。
把混合方案接入人工复核页，优先复核 DeepSeek 接受概念少但排序提升明显的样本。