从检诗找句到文海问津：古籍问答检索系统的落地复盘

1. 立项前的那几场争论：需求是怎么从"检诗找句"变成"文海问津"的

我们六个人第一次坐进学院小会议室的时候，谁也没想到这个选题能讨论两星期。团队里四个汉语言文学方向、两个计算机方向，本来凑到一起是想做一个给文学院研究生用的"诗词检索工具"，原因是大家写论文时最烦的就是为一句诗翻遍《全唐诗》《全宋诗》电子版，还经常翻错卷次和版本。但第一场讨论刚进行半小时我就发现，每个人心里想要的工具根本不是同一个东西。有人想要"输入诗句查出出处"，有人想要"问某字在古代韵书里的反切"，还有人直接说"最好能整段翻译成白话文"。这种需求发散的情况在创新实训项目里太常见了，真正麻烦的不是收集需求，而是把十几种想象收敛成三句能落地的话。

我们做这件事有个前提：团队里没人能负担从零训练模型，也不打算把项目做成一个"看起来什么都会、实际上什么都答不完整"的聊天机器人。于是前两周基本没写代码，一直在做需求访谈和资料调研。这里我把整个过程记录下来，既作为项目记录的第一篇，也供其他做文史方向加NLP应用的团队参考。如果你想了解一个跨学科小团队如何把古籍文本从零变成一个可用的问答检索原型，这篇应该能给你一条相对完整的路径。

1.1 最初的对话里，十个人有十种"想要的东西"

需求调研第一轮，我们做了三件事：采访十一位文学院研究生和三位老师，翻看他们在纸质书里做批注的照片，再把日常提问按照"查原文、查释义、查关系、查争议"四个类别做统计。统计结果很有意思，接近一半的问题属于"查原文"，比如"这句话最早出现在哪里""这个典故在《史记》里有没有记载"；另外大约三成是"查释义"，但不是简单的字词翻译，而是想知道朱熹怎么注、清人怎么辨、今天的教材又采用哪种说法；剩下两成才是"查关系"和"查争议"。

这段调研直接否掉了我们最早设想的"诗词搜索引擎"方向。因为用户真正不舒服的环节，不是找不到某一句诗，而是找到了之后还要自己核对多个版本、翻注疏、判断哪种解释更可靠。他们缺的不是一个更大的数据库，而是一条从原文出发、能串联起版本与注疏的研读路径。这个发现后来成为项目定位的关键：我们不负责替用户下结论，只负责把相关材料用更清晰的方式摆到他面前。

1.2 四轮访谈之后，我们把需求收敛成了三个关键词

需求收敛不是一次完成的。第二轮访谈把范围缩小到先秦到唐宋的常见典籍，第三轮用纸质原型让人试用，第四轮把我们预想的"功能大而全"逐条打回。最终留下来的核心需求可以归纳为三个关键词：定位、对照、解释。

"定位"指的是从一句引文或一个模糊表述出发，找到它在典籍中的确切位置，包括篇名、章节和上下文；"对照"指的是同一句话在不同版本里的异文差异，以及不同注家对同一处字句的解释差别；"解释"则是围绕某个字词、人名、事件或思想概念，把分散在原文各处的相关材料汇总给用户看。三件事听起来容易，真正做起来就会发现每一件都需要精细的文本结构和领域知识，不是单纯把文档丢给大模型就能解决的。

我们把项目命名为"文海问津"，也是出于这三个关键词。"文海"是对象，指向浩瀚的典籍文本；"问津"取自"使子路问津焉"里的探路之意，强调的是在文本海洋里找到门径，而不是让系统替用户把书读完。这个名字从一开始就在提醒我们：系统守得住边界、给出确定出处，比"聊得开心"重要得多。

1.3 一个跨学科团队的分工前提：文科生负责问对问题，计算机方向负责把问题变成流程

团队分工也经历了磨合。最开始两个计算机方向的同学习惯性问"你们要什么接口"，四个文科方向的同学则回答"我们都想要"。后来我们采用了一个非常老套但有效的办法：每个需求必须附带一个真实场景、一条验收标准和一条放弃理由。比如"输入'学而时习之'能查到《论语》原文"这个需求，验收标准是"返回结果必须包含书名、篇名和首句，不能只给一段孤立文字"。这样一来，文科生被迫把直觉变成规则，计算机同学也能在规则里做系统设计。

让我特别提醒一句：跨学科团队最大的风险不是技术难，而是双方在需求语言上互相听不懂。解决方式不是做更多抽象讨论，而是尽早把每一次讨论的结论落到具体的输入输出样例上，哪怕样例只有二十条，也能让"模糊的期待"变成"可验证的行为"。

2. 功能清单里的"砍"与"留"：哪些产出最有价值，哪些纯属噪音

创新实训项目最容易失控的地方，是团队觉得功能越多越能证明成果。实际上到了答辩和验收环节，评委最关心的是你有没有把一条主链路做扎实。我们在第二周结束前制作了一张功能取舍表，把候选功能按"用户频率、实现成本、项目定位符合度"三个维度打分，分数低于六分的全部延后或删除。这个过程相当痛苦，因为很多功能从技术上看很有意思，比如生成一首主题诗、判断某个字是否为入声字，但它们在原有需求里并不占据核心位置。

2.1 项目第一阶段只做三件事

我们最终确定，第一阶段只保留三个核心能力。

第一个是引文出处检索。用户输入一句带引号或书名号的话，系统返回可能的典籍出处并按置信度排序。这条链路不依赖大模型生成，本质上是倒排索引加语义召回的组合，它必须做到"快、准、有出处"。第二个是局部释义问答，用户问某个词或某句话在指定典籍里的常见解释，系统返回原文片段和一到三种注疏观点，并标出观点来源。第三个是概念相关的原文聚拢，比如用户输入"仁"，系统能列出《论语》各篇里讨论到"仁"的主要段落，而不是只从百科里抄一段解释。

这三件事对应我们调研得出的三类主流问题，也恰好是我们能在三个月内做出可用原型的规模。凡是超出这三件事范围的提问，第一版系统会给出一句统一说明，告诉用户该能力暂未开放。千万别小看这句"拒答模板"，它既保护了系统不被超出语料的问题带偏，也为后续迭代留出了清晰的版本边界。

2.2 我们主动砍掉的三类功能

有加就有砍。我们砍掉的第一类是整段白话翻译。理由很直接，典籍翻译需要非常强的语境判断，同样的"之乎者也"在不同句子里的功能完全不同，自动翻译一旦出错就会造成对原文的严重误读，比不翻译还要危险。第二类是文学鉴赏风格的长文本生成，比如让系统写一段苏轼词的艺术特色分析。这类内容虽然看起来"AI味十足"，但它会诱导用户把系统当权威，而且生成过程中的事实性错误很难让使用者察觉。第三类是面向开放领域的任意闲聊，比如问"儒家和道家有什么异同"这类超大问题。

砍掉这三类功能，本质上是在给系统的能力边界做约束，也是在保护团队的学术声誉。对一个面向典籍研读的工具来说，"它宁可不回答，也不能乱回答"应该是一条铁律。我们宁可让用户觉得功能少，也不要让用户被一段看似通顺实则错误的生成文本误导。

2.3 验收标准变成可测量的数字，而不是一句"用户体验不错"

需求要落地，必须过验收关。我们把每个核心能力都改写成可量化的指标，再围绕指标设计了测试集。比如引文出处检索的验收标准是：在三百条测试问句里，返回结果前三位包含正确出处篇目的比例达到百分之八十以上；局部释义问答的验收标准是：由两名文史方向成员独立给准确性打分，完整正确比例达到百分之六十，且不能出现方向性错误。

这样的设定比"答得好不好"要实用得多。因为"好"是主观的，而"测试集上准确率多少"是可以每天跑一遍的。项目组每周五下午跑一次回归测试，把指标变化贴在共享文档里，谁引入的问题一目了然。这也是我给所有做类似项目的团队的建议：第一次做工具类项目，先不谈什么产品体验创新，先把度量口径定清楚。

3. 技术选型的三轮淘汰：为什么最终选择"检索增强"而不是"从零微调"

技术选型我们做了三轮评估，每一轮都淘汰了一个看起来很美的方案。这里我不只记录最终选了哪套，更想记录被淘汰方案的问题，因为那些问题才是大家最容易踩进去的坑。

3.1 第一轮淘汰：从零训练或全量微调大模型，性价比算不过来

团队里最早有人提议自己训练一个"古文问答模型"。我们认真算了一笔账：即便采用开源架构，从零预训练需要的数据量以百亿级文本计，就算只做增量预训练或全量微调，也需要相当可观的显卡资源。我们的训练预算支撑不了持续数周的实验，更不用说训练过程中的调试成本。

后来我们讨论出一个务实的思路：与其让模型记住所有古文知识，不如让模型学会"查资料再回答"。这就把问题从训练一个大模型，切换成搭建一条检索增强问答链路。模型负责理解问题、组织答案和标注不确定性，真正的事实依据则由检索模块从我们自建的典籍语料库里取出。这个方案对大模型能力的要求低得多，在资源有限的情况下更具可行性。

3.2 第二轮淘汰：直接套用通用问答框架，在古文检索上暴露硬伤

第二轮的方案本是"偷懒"的：直接使用市面上的通用问答框架，把语料放进去，接一个大模型API，目标是一周跑通原型。我们确实在一周内跑通了，但测试结果让所有人冷静下来。问题集中出在文本切分上。通用框架习惯按固定字数把文档切成块，比如每五百字一块，再用这些块做向量检索。

古文最怕这种切法，因为古代典籍的语义单元是篇、卷、章、句，而不是五百字一个的连续窗口。一个段落被拦腰切开后，向量表示会丢失上下文，导致检索时经常把"出处正确但语境完全不对"的片段排在前面。例如问"子在川上曰"相关的原文，系统可能返回《论语》其他章节里同样包含"川"字的段落，因为向量检索只看到了字面相似。这个教训让我们意识到，检索质量的前提不是算法多先进，而是文本结构有没有被尊重。

3.3 第三轮定稿：向量检索加重排，加受限生成的组合架构

最终定稿的技术栈并不复杂。后端用FastAPI提供接口，数据存储在PostgreSQL里，向量检索采用pgvector扩展，嵌入模型选用开源的中文向量模型。检索时先用文本召回加向量召回取回候选片段，再用一个开源的中文重排模型对候选重新打分，最后只把得分最高的三到五段原文交给对话模块。对话模块则通过内部封装的开源中文模型接口完成，模型只负责读材料、组织语言，不鼓励凭训练记忆编造出处。

这样做的好处是每一层都能单独检查和替换。检索错了可以只看检索日志，重排不对可以单独调权重，模型回答有事实错误也能通过限制提示词来约束。我特别想强调一点：小团队做项目，架构一定不能是"什么都耦合在一起"的黑盒，否则出了问题根本不知道该如何定位、迭代。

如果用一句话总结定稿逻辑，那就是：把"记忆"交给结构化的语料库，把"理解与生成"交给模型，把"可信度"交给检索排序和拒答规则，各管一段。

4. 语料工程：项目里最不像"AI"却最决定成败的部分

如果说技术选型是项目的骨架，语料工程就是血肉。古籍文本的获取、清洗和标注，我们投入了整个项目前四成的时间，这个比例在最终效果上得到了充分回报。

4.1 选版本、查授权：古籍数据不是"网上有就能用"

很多技术背景的同学会默认古籍文本可以从网上批量抓取，但实际处理时会遇到三种问题。一是版本混乱，同一个篇目在不同朝代刻本里的文字存在差异，不选定底本就会导致引文出处互相矛盾；二是质量参差，OCR识别和人工录入都可能有错字，直接使用会把错误带进检索结果；三是授权问题，虽然古籍原文年代久远，但现代标点、校勘、注释很可能凝聚了他人的智力成果，并非可以任意商用。

我们的做法是优先采用已进入公有领域的底本影印作为参照，同时选用在授权范围内开放且标注清晰的公开文本数据源；涉及《论语》《史记》这类常见典籍的现代注释观点时，只做观点索引并在结果中标注说明，不直接复制大段解释文字。项目第一阶段以科研学习为目标可以这样做，但如果未来要公开发布商业产品，这一步的版权评估必须做得更细。

4.2 清洗与切分：在"段落完整"和"检索命中"之间找平衡

清洗工作的核心是给每一段原文建立稳定的位置标识。我们为每本典籍设计了一套编号规则，按照"书名、篇名、章节序号、原句序号"四级结构做索引，这样检索结果天然可以变成学术脚注需要的格式。这一步看起来只是简单的文本处理，实际上决定了后续所有功能是否能展开。

切分策略上，我们没有采用固定字数切块，而是先按古籍原有的篇章结构分段，遇到篇幅很长的一篇，再以语义完整的句群为最小单元切分。比如《史记·项羽本纪》这样的长文，会保留篇名整体，再按事件场景切出"巨鹿之战""鸿门宴""垓下之围"等子单元，并为每个单元补充一个由人工撰写的简短说明。这个说明不是给用户看的，而是为了让向量模型在检索时多获得一层语境提示，实测下来能让准确率提升不少。

4.3 把"文本质量"变成肉眼可见的指标

文本质量没有量化之前，Team里永远会觉得"差不多能用"。我们做了一次全量抽检，从每本典籍里随机抽取五十个句子，让两个成员独立核对原文，然后统计字符级错误率。第一次抽检结果让我们羞愧，错误率最高的典籍达到百分之三，这意味着平均每三十多个字就可能有一个错字，对学术检索场景来说完全不可接受。我们随后专门安排了两轮校对，把错误率压到千分之五以下才进入下一个开发环节。

另外，针对释义问答需要使用的注疏语料，我们设计了一套简单的XML标签格式，把"原文句子、注家、注疏内容、出处来源"四个元素绑定在一起。最初人工标注了两千条，之后通过模板自动扩展了一批。虽然规模不大，但足以支撑原型阶段的路演与内部评测，也让我们真正理解了一个问题：信息粒度的设计决定功能的上限。

5. 端到端跑通之后的翻车现场：三个案例复盘与评测结果

链路第一次端到端跑通是在项目启动后的第六周。当天我们还挺兴奋，觉得系统已经能回答问题了。可第二天拿着五十个真实问题逐条测试，发现答对的比例远不如预期。我们没有急着调模型，而是把每个错误案例的检索日志调出来看，很快就定位到问题不是出在对话模块，而是出在检索链路和拒答规则上。

5.1 案例一：向量检索被字面相似带偏方向

有个测试问题是"孔子在《论语》里如何论述君子"，系统返回的片段里混进了一条包含"子曰"但讨论对象是"小人"的段落。从向量相似度看，这条片段和"孔子""论述""君子"都存在字面关联，所以排名靠前。但上下文语境恰恰相反，那段是在讲君子与小人的对比，单独截出来确实容易误读。

这个案例给了我们两个改造方向。第一，检索问题需要做改写，把原来的问句拆成"确定主题词、确定典籍范围、确定关系方向"三个子任务，再分别检索、交叉过滤；第二，提示词里必须明确要求模型不得只依赖某一小段原文作答，要在多段候选里综合判断。改造之后，"断章取义"类错误明显减少。

5.2 案例二：多版本异文让"出处"变成了开卷考试

另一个典型案例是测试"夸父逐日"这个典故的出处。参考答案并不唯一，它会出现在《山海经》的海外北经部分，也会在《列子》的相关篇章里有相近记载。我们的测试集只标了《山海经》一个正确答案，系统实际返回了两处，被评测脚本判成了错误。后来我们意识到，这其实是标注口径的问题，不是系统能力的问题。

这个案例直接推动了标注规范的更新：凡是存在异文或相互引用的条目，测试集允许标注多个可接受出处，模型只要能给出其中任何一个并说明版本差异就算部分得分。学术问答终究和标准化考试不同，它的正确往往是一组关系，而不是一个孤立答案。我们此前用单一答案评判模型，本质上是对领域特性的忽视。

5.3 三百道题的小型评测：分数不是只看答对多少

在修正了检索策略和标注口径之后，我们用三百道题的测试集做了一轮完整评测。目前的结果是：引文出处检索任务中，正确答案出现在前三位候选里的比例达到百分之八十四；释义问答任务中，回答完整正确的比例约六成，另有接近三成部分正确，真正方向性错误的案例已经降到百分之十二以内。考虑到测试集里故意混入了十几道超出语料范围的题，这个成绩我们还算满意。

评测之外我们还专门验证了拒答能力。对超出范围的提问，系统应当输出"暂不支持"而不是硬答。刚开始几乎所有的溢出问题都被模型强行回答了，我们不得不给对话模块加上一道前置的权限校验流程，先用分类器判断问题是否命中能力范围，命不中就直接走拒答模板。这个机制后来被证明非常重要，因为用户并不会主动配合你的系统边界提问，边界必须由系统自己守。

6. 项目记录的价值：这一阶段我们踩过的坑和对团队的提醒

最后这部分算是阶段复盘。项目做到现在，我们最深的一个体会是：创新实训项目的产出不只是代码和原型，还包括一套可以被传承的记录。每次调试时发现的坑、每个指标背后的原因，如果不写下来，三个月后就会忘得一干二净。

6.1 文档规范比代码规范更容易被忽略，但同样重要

我们项目组内部建立了每周五下午的复盘制度，不管进度如何，都要更新三份文档：问题清单、决策记录、数据版本表。问题清单记录本周遇到的人为错误和系统故障；决策记录说明某个方案为什么被采纳或被否掉，防止两周后有人提出已被否掉的方案；数据版本表则记录每版语料的清洗日期、处理脚本和抽检错误率。这套看似繁琐的文档流程，在人员分工变化时发挥了关键作用。

尤其要说数据版本管理。古籍语料动不动就进行新一轮校对，如果每次都在原文件上原地修改，最终你就说不清这个结果是基于哪个版本跑出来的。我们后来给每一版语料都打上一个版本号，代码仓库里固定引用版本号而不是直接引用文件路径，这样才保证了评测结果可以复现。

6.2 给下一批做同方向项目的团队的提醒清单

以我们踩过的坑为代价，我提炼出几条给后来团队的建议。第一，先定测试集再写功能，没有评测指标之前写出来的功能都是自我感动；第二，语料清洗阶段不要赶进度，每本典籍入库前都要做抽样校对，宁可少收十本也要把已有文本做准；第三，团队里必须有一个人负责"守住产品边界"，防止需求无限膨胀；第四，出现系统答错时，第一时间检查检索日志，问题大概率出在召回环节，而不是模型能力；第五，定期把系统输出打印出来让领域专业同学做人工评审，能发现很多自动化评测发现不了的质量问题。

第五点我想多说两句。自动评测只能判断答案字符串与参考标准是否一致，但它判断不了"这个解释放到整段语境里是否恰当"。我们每个月会请一位没参与开发的文学院同学来现场提问二十分钟，让他用"是否敢把系统回答写进论文注释"作为评价标准。这种粗颗粒但不留情面的反馈，往往最能推动架构迭代。

目前"文海问津"第一阶段的原型已经跑通，也完成了第一次完整评测。我们正在做的是把测试集规模扩大到八百题，同时补齐几部核心典籍的篇章级语料。接下来我们会专门处理一个此前暴露但暂时没碰的问题：注疏观点并不总是统一的，当朱熹和清儒对同一句话理解不一致时，系统应当如何向用户呈现分歧。这个问题已经超出了单纯的检索排序，涉及知识组织方式。等我们做出下轮版本的对比结果，我会在这里继续记录。如果你也在做文史语料相关的应用，欢迎把你的踩坑经历丢过来，咱们互相做对照组。