5.0 KiB
“九歌·推敲”类书数据接入与使用逻辑说明
1. 背景与目标
在“九歌·推敲”小程序的学术理念中，最核心的贡献之一是“可解释的知识引导推荐”。现有的AI诗歌生成往往是“黑盒”输出，而“九歌·推敲”致力于让AI成为“雕琢者”，为用户的修改提供坚实的文学与语言学依据。 当前目录下的《海录碎事》《白孔六帖》《初学记》《渊鉴类函》等古籍类书（古代百科全书）的JSON数据，正是构建这一“显性依据（Explicit Evidence）”的底层知识库。类书按门类（如“天”、“地”、“人”、“物”）汇编了历代典故、词藻、名句，是古代诗人作诗时最常翻阅的“参考书”。在数字化时代，我们将它们作为AI大模型之外的“外挂知识引擎”。
2. 数据结构解析
经过整理的JSON文件通常呈现如下树状/字典结构： { "metadata": { "title": "白孔六帖", "author": "白居易、孔传", "dynasty": "南宋" }, "categories": { "天": [ { "volume": 1, "content": "白髙眀柔克(髙明天也柔克寒暑不干)隂隲下民..." } ], "地": [...] } } 核心要素：
- Category (门类)：如“天部”、“地部”。这是天然的语义标签（Semantic Tags）。
- Content (内容)：包含了具体的词藻（如“白髙”、“柔克”）、典故、出处说明及古人的注释。这些是推敲建议的实证来源。
3. 在小程序中的核心使用逻辑
类书数据在小程序中主要扮演“灵感库”与“解释器”两个角色。其核心业务逻辑可拆解为以下三个层面：
3.1 词汇与意象的横向拓展（灵感启发）
当用户对诗句中的某一个字或词进行“锁定”或点击“推敲”时：
- 逻辑：提取该词，在类书JSON的 categories 中进行映射（或通过向量检索寻找相关类目）。
- 用途：系统不仅推荐AI生成的候选词，还可以直接从类书中调取同一门类下的同义词、意象词。
- 体验：用户在写“云”时，系统可以从类书中关联出“白衣狗”、“纤尘”、“朝隮”等更具古典文学色彩的意象，打破现代人的词汇匮乏。
3.2 推荐结果的“白盒”解释（显性依据）
这是契合论文核心创新点的重要逻辑。
- 逻辑：当大模型（后端AI）生成了一组候选词（例如建议把“看”改为“望”或某个更雅致的字）时，系统在后台对该字或该词组进行类书倒排索引检索。
- 用途：如果在《海录碎事》或《白孔六帖》的 content 中匹配到了包含该词的古典语料，系统会将该条语料作为“解释线索（Clue）”随推荐结果一起返回。
- 界面呈现：在UI上，除了高频搭配和PPL名句，用户会看到一个【古籍溯源】的卡片，显示：“该用法见于《白孔六帖》天部：‘……’”。这就为AI的建议提供了不可辩驳的古代文献依据。
3.3 诗歌典故的自动挖掘与校验
- 逻辑：利用类书本身自带的经史子集注疏，作为校验器。
- 用途：当用户自行输入一句诗时，系统通过实体识别与类书匹配，如果命中类书中的某个典籍片段，可以自动高亮该词，告诉用户“此处暗合了某某典故”。这极大增强了爱好者的“创作满足感”。
4. 技术实现与工程流水线建议
为了让这些JSON文件在小程序中高效运转，建议采用以下架构： 第一步：知识库向量化与索引化 (RAG 架构基础) 原始JSON文件体积较大，不适合每次全量遍历。
- 方案：将 content 按照短句或标点进行切分（Chunking），并附带其所属的 title（书名）和 category（门类）元数据。
- 存储：将这些片段存入 Elasticsearch（用于字词的精准匹配/倒排索引）和 向量数据库（如 Milvus / Qdrant，用于大模型生成的语义相似度检索）。 第二步：与 AI 生成模块的协同 (Pipeline)
- 触发推敲：用户在小程序前端框选诗句“落霞与孤鹜齐飞”，对“飞”字请求推敲。
- AI生成：大模型生成候选字，如“翔”、“舞”、“落”。
- 知识库校验 (Retrieval)：后端拿着候选字“翔”，去类书数据库中检索带有“孤鹜”和“翔”或同类意象的原文片段。
- 组装返回： { candidate: 翔, reasoning: { collocation: 高频搭配, leishu_clue: 《渊鉴类函》鸟部：'……飞翔……' } } 5. UI渲染：小程序前端解析该JSON，展示带有依据的修改建议卡片。
5. 总结
在“九歌·推敲”中引入这些处理好的类书JSON，本质上是用中国古代分类学（类书）的智慧，去约束和解释现代的大规模语言模型（LLM）。这不仅解决了AI生成内容不透明、不可控的问题，还将“推敲”这一古典文学实践，通过知识图谱和文本检索的技术手段，原汁原味地还原给了当代诗歌创作者。