检索与生成融合的诗歌接龙：韵脚约束与打分排序实践

简介围绕自然语言处理与诗歌接龙实战展开的Python项目压缩包面向希望把分词、拼音转换、韵律匹配与接龙算法落到代码中的NLP学习者也适合作为课程设计或简历项目的参考案例。包内共17个文件以4个py源代码、docx说明文档、xml配置及dat/pk数据文件为主另含exe与txt等辅助内容整体约5.86MB目录围绕poem Solitaire项目组织便于按源码、文档与数据模块查阅。已有499人学习说明其作为入门到进阶实战素材具有一定参考价值。读者可从中获得诗歌接龙项目的完整实现思路包括基于pypinyin的尾字音韵匹配、jieba分词处理、规则与统计方法结合的接龙策略说明文档还梳理项目背景、目标、实现过程与常见问题并可据此复现数据处理、规则调用与结果验证过程适合对照源码理解NLP文本处理流程并二次改造。1. 需求不是“生成一首诗”而是“接得住上一句”做过 python NLP 项目的人多半碰过这种场景给定一句诗让程序接出下一句。听上去像个小功能真跑起来问题一串——接龙结果直接把训练集原句背出来换个自己写的半句就接得既不押韵也不合格律。诗歌接龙这个题目表面考文本生成实际考的是“约束条件下的候选筛选”韵脚要对、平仄要顺、语义要接得上还不能是查表抄来的。这套方案就是围绕这件事搭的一份可检索的结构化诗库、一条检索式接龙通路、一条字符级生成通路外加一层打分融合和一套能拿去答辩的验收脚本。适合正在做 NLP 毕设、课程设计的学生也适合要交付一个“小而完整”的文本生成 demo 的开发者。下面的结构按“需求 → 架构 → 语料 → 实现 → 避坑 → 验收”推进能照着改。2. 总体架构检索与生成两条腿走路2.1 为什么纯生成式方案在这个题目上会翻车字符级语言模型在诗词上很容易“学得像”但学得像和接得住是两回事。训练语料规模通常只有几万到几十万句模型参数量一旦上去很快就进入过拟合区间给“床前明月光”能接“疑是地上霜”给“窗外雨声急”就开始胡言乱语。更麻烦的是不可控——你要它押“ang”韵它给你一个“eng”你要它五言它吐七个字。检索式通路的优势恰好在这里候选句来自真实诗库格律天然正确只要召回和打分做对输出质量的下限非常高。缺点是“死板”遇到诗库里没有相似语境的上句就容易接不上。所以这套方案的核心判断是检索负责保底与格律正确生成负责兜底与多样性融合层负责在两者之间做取舍。这个思路在工程上还有一个额外好处——两条通路可以独立开发和独立验收答辩演示时任何一条挂了另一条还能撑住场面。2.2 四层结构与模块职责整个系统按职责拆成四层层与层之间只通过明确的数据结构通信避免代码写成一锅粥。层级模块输入输出职责边界数据层语料清洗、句对构建、韵表加载原始诗词文本结构化句对 韵脚字典只负责“把脏数据变干净”索引层倒排索引、向量索引结构化句对候选句 ID 列表只负责召回不负责排序算法层检索打分、生成模型、融合排序上句 候选带分数的候选列表只负责打分不碰 IO服务层接口封装、缓存、日志HTTP 请求JSON 响应只负责协议转换与资源管理这样切分之后调试路径非常清晰接龙结果不对先看索引层召回里有没有正确答案有就是打分问题没有就是索引或语料问题。少了很多“到底是模型不行还是数据不行”的玄学排查。2.3 技术选型与依赖清单选型原则是“能在普通笔记本上跑完训练和推理”不追求 SOTA。# requirements 核心依赖版本区间按兼容性给不锁死小版本 torch1.12 # 生成通路的训练与推理 flask2.0 # 服务层够轻 jieba # 只用于辅助关键词抽取诗词本身按字符切 numpy # 向量运算与打分矩阵 tqdm # 语料处理进度长任务必备几点说明。第一诗词不做分词。现代汉语分词工具在古诗词上会把“长安一片月”切成奇怪的组合字符级处理反而更贴近格律单位五言七言本身就是按字数的。jieba只在“主题关键词召回”这种辅助场景用一下。第二选 PyTorch 不选 TensorFlow原因是字符级小模型的训练循环里需要频繁改解码逻辑加韵脚约束、加长度约束动态图改起来省事。第三不用预训练大模型微调。一是显存不够二是小语料微调大模型极易过拟合到原句复现反而不如从零训一个小模型可控。这条经验在课程设计场景里尤其重要——评委问“为什么不用 BERT”你能答出“语料规模支撑不了且格律约束用规则更可靠”比硬上大模型有说服力。提示如果你的机器连字符级 LSTM 都训不动把生成通路降级为“模板 随机槽位填充”也能交差架构不变只是算法层换个实现。3. 语料工程把诗集拆成可检索的结构化样本3.1 清洗与分句从整首诗到句对语料是这套方案里最容易被低估的部分。一份公开的古诗词语料拿到手通常混着标题、作者小传、注释、异体字、全角半角混排。直接丢进模型训出来的东西会带一堆脏尾巴。清洗流程按顺序做四件事去注释行、统一标点把全角逗号句号统一成半角再统一回目标格式、按标点切句、按句长过滤。import re # 只保留汉字与常见断句标点其余字符注释标记、序号、拉丁字母一律剔除 CLEAN_RE re.compile(r[^\u4e00-\u9fa5。、]) SPLIT_RE re.compile(r[。]) def clean_and_split(raw_line: str): 输入一行原始文本输出清洗后的句子列表 line CLEAN_RE.sub(, raw_line) if len(line) 6: return [] parts [p for p in SPLIT_RE.split(line) if p] # 只保留五言、七言其余长度丢弃这是格律约束的第一道闸门 return [p for p in parts if len(p) in (5, 7)] def build_pairs(sentences): 相邻两句构成一个句对作为接龙的监督样本 pairs [] for i in range(len(sentences) - 1): cur, nxt sentences[i], sentences[i 1] if len(cur) len(nxt): # 上下句字数相同符合对句习惯 pairs.append((cur, nxt)) return pairsCLEAN_RE里的字符集是“汉字区间 中文标点白名单”这个白名单一定要显式列出用\W之类的反向写法会把大量汉字误杀。build_pairs里加了len(cur) len(nxt)的约束是因为五言接七言读起来别扭而且会让后面的长度打分失去意义。通常的做法是把清洗好的句对落成一个 JSONL每行{prev: ..., next: ..., prev_rhyme: ..., next_rhyme: ...}韵脚信息在构建阶段就算好避免运行时反复计算。3.2 韵脚字典与平仄标注韵脚判定是这套方案里最“看起来简单、做起来出问题”的环节。古韵平水韵和今韵中华新韵差别很大“斜”在古诗里读 xiá押“麻”韵按普通话读 xié 就跑到“皆”韵去了。我的处理是双轨制默认用中华新韵按普通话韵母归并提供配置项切到平水韵表。课程设计场景下用新韵足够答辩时能说清这个取舍就够了。# 新韵韵母归并表把复韵母折叠到韵部key 是韵母value 是韵部代号 RHYME_MAP { a: A, ia: A, ua: A, o: O, e: O, uo: O, i: I, er: I, v: V, u: U, ai: AI, uai: AI, ei: EI, ui: EI, ao: AO, iao: AO, ou: OU, iu: OU, an: AN, ian: AN, uan: AN, van: AN, en: EN, in: EN, un: EN, vn: EN, ang: ANG, iang: ANG, uang: ANG, eng: ENG, ing: ENG, ong: ONG, iong: ONG, } # 平仄简化判定一二声为平三四声为仄。多音字取常见读音误差在可接受范围 def tone_of(pinyin_tone: int) - str: return 平 if pinyin_tone in (1, 2) else 仄说明两点。RHYME_MAP用韵部代号而不是直接比较韵母是因为“an/ian/uan”这三个韵母在听感上押韵但字符串比较不相等归并后rhyme(山) rhyme(天)才成立。平仄只按声调粗判确实不严谨——古诗里的入声字在普通话里已经散到四声中了——但作为打分的一个加分项而不是硬性门槛这个精度够用。真要做严谨就得引入带声调的拼音词典成本翻几倍收益不明显。3.3 倒排索引与候选召回索引的设计决定了召回质量。诗歌接龙有两种玩法索引要同时支持对句式给定上句接下句。召回靠“尾字韵部 句长 语义相似”。顶针式上句尾字作为下句首字。召回靠“首字精确匹配”这就是标准倒排。from collections import defaultdict class PoetryIndex: def __init__(self): self.by_first_char defaultdict(list) # 首字倒排服务顶针接龙 self.by_rhyme defaultdict(list) # 韵部倒排服务对句接龙 self.by_length defaultdict(list) # 句长倒排做长度过滤 self.sentences [] # id - 句子内存足够时直接存 def add(self, sent_id: int, sentence: str, rhyme: str): self.sentences.append(sentence) self.by_first_char[sentence[0]].append(sent_id) self.by_rhyme[rhyme].append(sent_id) self.by_length[len(sentence)].append(sent_id) def recall(self, prev: str, topk: int 200): 三级召回先按韵部取再按长度过滤最后做首字命中加权 rhyme get_rhyme(prev[-1]) cand self.by_rhyme.get(rhyme, []) cand [i for i in cand if len(self.sentences[i]) len(prev)][:topk * 4] # 首字相接的候选顶针玩法额外加分混在候选池里一起排序 cand list(dict.fromkeys(cand self.by_first_char.get(prev[-1], []))) return cand[:topk]by_rhyme是主力召回通道by_first_char是顶针玩法的补充。两个列表用dict.fromkeys去重这一步很容易漏——漏了就会出现同一句诗在候选池里出现两次融合排序时被重复加权最后两个候选一模一样。召回数量给topk * 4再截断是给后面的打分层留余量韵部召回可能返回几百句但真正能排进前十的往往只有几句多留一些避免早截断。注意self.sentences用列表按下标存索引里存的都是 id别直接存字符串。字符串在 Python 里开销不小几十万句全存两份内存会炸。4. 双通道接龙检索打分与字符级生成的融合4.1 检索通路的打分函数召回只是给候选排序才是决定输出质量的地方。打分设计成四个维度的加权和每个维度都能单独关掉做消融实验——这一点在答辩时很加分评委问“这个模块到底有没有用”你现场关掉跑一遍对比即可。def score_candidate(prev: str, cand: str, prev_rhyme: str, cfg) - float: 四个维度加权韵脚、平仄、语义、重复惩罚 s 0.0 # 1) 韵脚押韵得满分不押为 0。权重最高因为它最影响听感 s cfg.w_rhyme * (1.0 if get_rhyme(cand[-1]) prev_rhyme else 0.0) # 2) 平仄上下句对应位置平仄相反为佳按相反比例给分 same sum(1 for a, b in zip(prev, cand) if get_tone(a) ! get_tone(b)) s cfg.w_tone * (same / len(prev)) # 3) 语义用字向量平均后算余弦缓解“押韵但不搭”的问题 s cfg.w_sem * cosine(vec(prev), vec(cand)) # 4) 惩罚项与上句字符重合度过高说明是复读直接扣分 overlap len(set(prev) set(cand)) / len(set(prev) | set(cand)) s - cfg.w_rep * overlap return s四个权重建议从w_rhyme0.4, w_tone0.2, w_sem0.35, w_rep0.35起步。为什么重复惩罚的权重接近韵脚因为在实际测试里“复读”是最刺眼的失败模式——接出来的句子跟上句共享一半的字一眼假。惩罚项用 Jaccard 而不是简单的交集计数是为了让长句短句处在同一量纲上。语义向量这块课程设计场景不必上 BERT。用字向量查表求平均就够了训练生成模型时会顺带得到字向量直接复用省一套依赖。4.2 生成通路的模型结构与训练生成通路用的是字符级 LSTM结构不复杂但要跑通得注意几个细节。import torch import torch.nn as nn class CharLM(nn.Module): def __init__(self, vocab_size, emb256, hidden512, layers2): super().__init__() self.emb nn.Embedding(vocab_size, emb, padding_idx0) self.lstm nn.LSTM(emb, hidden, layers, batch_firstTrue, dropout0.3) self.head nn.Linear(hidden, vocab_size) def forward(self, x, hNone): # x: (batch, seq_len)输出每个位置对所有字的打分 e self.emb(x) out, h self.lstm(e, h) return self.head(out), h训练样本就是把句对拼起来喂进去[CLS] 上句 [SEP] 下句 [EOS]损失只在“下句”部分计算。这一点很关键——如果连上句也一起算损失模型会把大量容量花在记忆上句上接龙能力反而下降。超参数方面emb256, hidden512, layers2配上几万句语料的规模在单卡上几十分钟能收敛到一个“能看”的水平。dropout0.3比常规的 0.5 低一些是因为字符级模型的参数量本来就不大压太狠会欠拟合输出变成高频字堆砌。训练时按 8:1:1 切训练集、验证集、测试集验证集上盯的是 perplexity但不要只看 perplexity。字符级中文模型的困惑度很容易刷得很低因为高频字之、不、人、山、月占比太高。真正要盯的是“押韵命中率”下一节会讲怎么在解码时强约束。4.3 融合排序与约束解码两条通路的输出怎么合取决于场景。我的做法是检索通路先给出 top-N 并附分数生成通路给出 top-M 候选并附对数概率两者归一化到同一量纲后加权检索权重给 0.65生成给 0.35。生成通路的解码必须加约束否则押韵全靠运气。def constrained_decode(model, prefix, rhyme_pool, max_len7, topk5): 在解码时把词表限制在韵脚候选集内保证输出必然押韵 ids encode(prefix) out [] h None for step in range(max_len): logits, h model(step_forward(ids out), h) logits logits[:, -1, :] # 关键最后一步只允许从同韵部的字里选 if step max_len - 1: mask torch.full_like(logits, float(-inf)) mask[:, rhyme_pool] 0.0 logits logits mask probs torch.softmax(logits / 0.8, dim-1) topk_ids torch.topk(probs, topk).indices out.append(int(topk_ids[0, torch.randint(0, topk, (1,))])) return decode(out)这里的两个设计点值得说清楚。第一约束只在最后一个字上施加中间位置不加否则整句会被韵脚字带偏读起来像凑韵。第二温度取 0.8 而不是 1.0稍微压一点随机性避免生成出过于生僻的组合。topk采样而不是贪心是为了让同一个上句多次请求能给出不同下句演示时更有说服力。韵脚候选集rhyme_pool从 3.2 的韵表里反向查出来是一个字符 id 列表。如果某个韵部在词表里几乎没有字生僻韵直接降级走检索通路别硬生成。5. 避坑与排查上线前最容易翻车的五个点这一章按“现象 → 原因 → 解决”写都是我在这类项目里真踩过的。5.1 现象接龙结果全是语料里的原句原因召回池太小加上语义打分权重过高。语义向量用字向量平均同一首诗里的句子平均下来天然接近于是原句永远排第一。解决在打分函数里加一条“与原句完全相同的候选直接置零”同时把召回池从 50 扩大到 200。另外检查训练集和测试集有没有重叠——句对构建时按整首诗切分不要按句随机切否则同一首诗的上句在下句在训练集、下句在测试集模型等于提前看过答案。5.2 现象押韵判定时对时错原因多音字。同一个字在不同语境下读音不同取默认读音就会判错。这类问题在“看”“听”“相”“长”这些字上特别集中。解决给高频多音字建一张手工修正表二十来个字就能覆盖绝大多数场景。判定时先查表查不到再走默认规则。不要试图用程序自动判定多音字投入产出比极低。5.3 现象生成结果长度失控或出现乱码原因没有 EOS 约束或者词表里有未登录字符。中文诗词语料里偶尔混进异体字这些字在训练集出现次数极少向量训练不充分解码时容易连着吐几个。解决词表构建时设最小词频阈值比如出现少于 3 次的字直接归到 UNK解码时对 UNK 概率做惩罚。同时硬性截断最大长度五言就截到 5别让模型自己决定什么时候停。5.4 现象接口偶发超时演示现场卡住原因每次请求都重新加载模型或者重建索引。索引构建在几十万句规模下要几秒模型加载也要时间HTTP 请求里做这些必然超时。解决模型和索引在应用启动时加载成全局单例请求处理只做推理。再用一个 LRU 缓存把“上句 → 结果”存起来同一个上句第二次请求直接命中演示时连点几次都不会卡。5.5 现象同样的输入两次结果不一样没法复现问题原因采样用了随机数但没设种子加上 Python 的字典遍历顺序在不同进程里可能不同导致候选排序不稳定。解决调试模式下固定随机种子候选排序时显式按(分数, 句子 id)双键排序保证同分时顺序确定。这个改动很小但没有它你在答辩现场根本没法向评委解释“为什么刚才那个结果和现在不一样”。6. 验收与答辩用一张表和一段脚本证明它能用验收这件事最忌讳只说“我试了试感觉还行”。评委要的是可量化的证据。我的习惯是搭一张四列的表指标、怎么测、合格线、对应模块。指标测法合格线对应模块押韵命中率随机抽 200 个上句统计接句尾字同韵部比例≥ 85%韵脚约束格律合规率上下句字数一致且平仄相反对应比例 ≥ 60%≥ 90%打分/解码原句复现率输出与语料中任意句子完全相同的比例≤ 5%重复惩罚语义相关性人工 5 分制抽样打分取均值≥ 3.5语义打分平均响应时间100 次请求取 P95≤ 300ms服务层这些数字不用写进论文正文但一定要在演示前跑一遍心里有底。前三个指标可以脚本全自动算最后两个人工抽样就行。批量评测脚本大概长这样import random, time def evaluate(system, samples, n200): samples 是 (上句, 参考下句) 列表返回各项指标 random.seed(42) # 固定种子保证结果可复现 picks random.sample(samples, min(n, len(samples))) hit, charm, dup, lat 0, 0, 0, [] for prev, gold in picks: t0 time.time() cand system.next_line(prev) lat.append(time.time() - t0) hit int(rhyme_of(cand[-1]) rhyme_of(gold[-1])) charm int(len(cand) len(prev)) dup int(cand in system.corpus_set) return { rhyme: hit / len(picks), length: charm / len(picks), dup: dup / len(picks), p95_ms: sorted(lat)[int(len(lat) * 0.95)] * 1000, }random.seed(42)那一行不是装饰是让同一份代码跑两次得到同一批样本方便对比改版前后的差异。system.corpus_set是语料句子的集合用于查复现。p95取排序后的 95 分位而不是平均值是因为平均值会被大量缓存命中的快请求拉低掩盖真实的长尾。答辩演示我还有个小技巧准备三组输入一组是名句验证基本功能一组是自己编的半句验证不是查表一组故意用生僻字结尾验证降级逻辑不崩。三组跑完基本就把方案的能力边界讲清楚了。从那以后我每次交这类带生成的方案都会在动手写模型之前先把评测脚本写出来——先有尺子再做东西比做完再找尺子省事太多。希望帮到你。本文还有配套的精品资源点击获取