简介这是一份AIML中文语料库面向需要构建中文聊天机器人的开发者和自然语言处理学习者用于训练和优化对话模型的意图识别与回复生成。资源共91个文件以56个XML和35个AIML文件为主整个压缩包仅1.48MB语料按标准AIML结构组织覆盖闲聊、影视、音乐、美食、情感、星座、健康、编程等多个主题每个主题下都有成对的用户输入与机器人响应示例适合直接导入支持AIML的聊天引擎。目前已有1492人学习下载适合初学者对照句式模板理解AIML语法也适合进阶开发者快速扩充中文知识库、评估模型表现。由于语料从多个渠道收集并经过初步预处理表达方式多样借助这些语料开发者可以训练出理解中文口语化表达、识别用户意图并给出合理回复的机器人同时也可用于语义分析、情感识别等NLP任务或作为课程设计的实验素材帮助读者在真实对话数据中掌握AIML的结构化写法与中文语料组织方式。 真正动手整理AIML中文语料之前我先把这个关键词挂在搜索框里翻了一个晚上结果不算意外能下载到的所谓中文语料包要么是十几年前A.L.I.C.E.时代的古董配置回答内容停留在我是Alice我可以帮你这种远古老梗上要么是拿英文标准语料用机器翻译硬翻过来读起来一股子直译腔你问它你吃了吗它回你我是一个软件程序上下文完全接不上。所以我决定不依赖现成资源从零开始整理一套能真正跑起来、也能持续迭代的中文AIML语料。这套语料前后维护了半年多从最初两三百条问答对到现在覆盖十几个场景、两千多条有效规则。整个过程踩了不少坑也沉淀了一套相对稳定的整理方法今天把过程完整写出来给准备走这条路的人一个参考。1. AIML没死只是被低估了——中文语料为什么值得自己动手1.1 AIML到底是什么还在用什么场景AIMLArtificial Intelligence Markup Language是用于定义聊天机器人感知-回应规则的一种XML方言它的核心思路非常朴素用户输入一句话机器人在预先定义好的模板里找到最匹配的模式pattern然后返回对应的回答template。你问你叫什么名字它匹配到pattern你叫什么名字/pattern就回我叫小语。它的历史可以追溯到A.L.I.C.E.和Richard Wallace这在NLP圈子里算是活化石级别的产物。但活化石不等于没用。和现在流行的深度对话模型相比AIML天然具备几个难以替代的优点完全离线、无隐私风险、响应延迟几乎为零、回答内容完全可控、debug过程像一个普通的XML解析任务一样透明。这些特性决定了它特别适合做垂直领域的FAQ机器人、客服预判回复、儿童教育对话、角色扮演闲聊这类对准确率要求高、对花哨程度要求低的场景。所以我的判断是AIML这个壳子本身没有问题问题出在语料。一套贴合中文用户语言习惯、领域边界清晰的语料完全可以撑起一个体验不错的轻量级对话系统。1.2 为什么市面上的中文语料基本都不能直接用不是因为数量不够恰恰相反我能找到的语料包数量不少但质量天花板很低问题集中在三类。第一类是年代感太强。很多语料包还保留着你是男孩还是女孩你喜欢什么颜色这种十几年前的入门级对话没有城市天气、没有外卖、没有帮我定个闹钟这种现代用户会真实追问的场景。第二类是翻译腔。英文AIML里大量使用*通配符加上特定关键词的匹配结构直接翻译成中文后会出现我是你的*是什么这种句式中文用户根本不会这么说话。第三类是版权和来源不明很多语料包混着爬虫抓取的聊天记录没有整理过直接拿进生产环境会引发内容安全和管理上的麻烦。所以自己动手不是情怀而是务实。自己做语料意味着你可以控制话题边界、回答口径、风格的统一性也意味着未来每一条新增规则你都知道它的来源意图。1.3 这套方法适合谁如果你只是想快速跑个demo验证AIML能聊到什么程度直接装个Program AB用英文语料跑通即可不需要看这篇文章。但如果你要做的是一个面向中文用户、需要真实投入使用的场景——无论是给老板演示的智能客服原型还是想做一个有固定人设的闲聊机器人甚至是用来做儿童AI伴读实验——那么我下面这套中文AIML语料整理方法应该能帮你少走几个月弯路。2. 中文语料的中文难题翻译不是解药这一节聊的是AIML中文语料和英文语料最本质的差异。很多人接手中文AIML项目时第一个直觉是把英文语料翻译成中文不就行了结果做出来以后丢到测试群里被朋友的刁钻提问打得体无完肤。根本原因在于中文自身的特点让AIML这套源自英文的匹配机制水土不服。2.1 分词英文天然做了中文什么都没做AIML的匹配核心是字符串模式匹配英文天然有空格作为分词边界一个pattern就是一组单词序列匹配的时候通配符*可以很自然地对应一个或多个单词。但中文句子没有空格一个pattern就是一句话同一个语义用户可能有十几种说法比如你叫什么名字用户还有可能说你叫啥你的名字是什么怎么称呼你您贵姓这些都要分别建category。英文里一条patternWHAT IS YOUR NAME/pattern规则靠WHAT IS * NAME这种结构也能覆盖不少变体但中文的灵活性远超英文通配符设计不好就会误伤别人。这不是AIML的问题而是中文处理的原生难题。所以构建中文语料第一步不是写XML而是先想清楚归一化策略。2.2 全半角、简繁、标点语料膨胀的隐形推手写英文语料时大小写转换一把梭基本解决格式问题。中文没有大小写但有两个英文不太care的坑全角半角字符和简繁字体。用户发你好和你 好、发你好?还是你好、发繁体妳好还是简体你好在AIML的匹配引擎看来分别是完全不同的字符串。这就逼着你做一整套输入预处理把全角字符统一转半角把中文标点统一转成规范形式或者干脆去除把繁体转简体或者按需求保留两种把用户输入的可见空格全部去掉。这个归一化环节必须在命中文档之前完成否则你要靠语料本身去背各种写法的包袱语料量直接翻三四倍。我在实际项目里还发现一个容易被忽略的坑很多用户是语音输入会有你好呀呀这种叠字也有你在哪儿和你在哪这种口语缩略。这一类不靠归一化解决要靠语料设计时预留常见白话变体。2.3 中文的省略和语序AIML的上下文需要额外设计英文对话里Yes和No这种词可以独立成句中文用户很少单回一个字他们更爱说是呀没错嗯嗯甚至用表情包结束对话。这在AIML里的直接影响是很多在英文语料里只要一条规则就能覆盖的回复中文要补充三到五条。另外中文的语序非常灵活。你吃饭了吗、饭你吃了吗、吃了吗你三句话语序不同但语义几乎一样。英文靠变形和助词表达时态语态中文靠语序和语气词这在AIML的模板设计里意味着不能只考虑语义集合还要考虑用户最常见的表达列。我建议为每个核心意图建立一张变体清单变体数量低于3个的意图不必单独建category交给通配符去兜底即可。对比维度英文AIML语料中文AIML语料分词天然空格分词pattern粒度是单词无空格pattern粒度是整个句子格式归一大小写转换即可全半角、简繁、标点、空格都要额外处理口语变体变形少相对可控语序灵活省略多变体数量成倍增加上下文衔接靠that和topic机制即可同样靠机制但需要更细的钩子设计通配符设计按词匹配相对安全按字匹配一个*可能吃掉一整个分句2.4 所以能不能直接翻译英文语料结论是可以但不能直译只能语义移植。英文语料的价值在于它的对话结构和逻辑框架而不是句子本身。比如说英文里有一组关于天气的话题从weather的几个分支展开为下雨晴天台风这个结构框架可以直接借鉴但回答内容里的表达方式、语气、地理位置常识必须完全重写。我把这种方法叫结构复用、语言重写后面做语料规划时会反复用到。3. 语料整理五步法从散乱对话到可入库的问答对3.1 第一步划定领域与场景边界任何一个AI语料库不可能覆盖人类所有话题AIML尤其如此。AIML的强项是窄而精所以第一件事是明确要聊什么。我当时给小语定位的是一个生活闲聊型机器人圈定了五个领域基本信息自我介绍、年龄、性别、闲谈寒暄你好、再见、谢谢、饮食话题今天吃什么、美食推荐、天气话题天气怎么样、明天会下雨吗、情绪陪伴我很难过、我开心。划定范围以后你会发现语料需求一下子从无底洞变成一个可控的数量级。每个领域先按用户可能问什么问题和机器人应该回答什么内容做两列清单等清单基本覆盖了80%的常见提问再进入下一步。3.2 第二步收集原始数据原始数据的来源大概有这么几个公开的开源聊天语料比如一些社区贡献的对话数据注意看许可协议、微信群/QQ群脱敏后的闲聊记录这是金矿真实用户怎么说话全在里面、以及你自己脑子里的用户视角提问清单。我特别建议把真实日志作为最高优先级。很多时候你自认为设计得很全的语料上线第一天就被用户一句话击穿比如问你知道周杰伦吗你根本还没来得及建任何关于明星的category。所以从第一天起就要规划好失配日志的导出机制后面第5章会展开把用户没被匹配上的每一句话都记录下来然后定期把这些话补充成新语料。3.3 第三步清洗与规约原始数据不能直接进AIML否则会带进来一堆垃圾。我常用的清洗规则如下处理项规则原因超链接全部删除用户不会在闲聊中期待链接连续重复字符超过2个重复字合并比如哈哈哈规约为哈哈表情符号全部删除AIML模板里不适合存emoji长度过滤单句超过30个字丢弃过长句在闲聊中占比低且pattern难以命中私密信息手机号、微信号、地址正则删除合规和信息安全无意义噪声啊啊啊、等单独出现的丢弃没有信息量清洗完之后还有一步规约把所有句子统一走一遍和线上一样的归一化流程——全角转半角、中文标点去除、繁体转简体、英文转小写。这样你记录下来的语料和实际运行时用户输入经过的预处理保持一致。3.4 第四步语义等价的改写与去重这是整个流程里最费脑力的一步。比如用户会问今天天气怎么样今天天气如何今天冷不冷今天会不会下雨前两句语义几乎完全等价后两句则属于天气意图但带有额外诉求。我的做法是把等价句子归为一组组内选一个最自然、出现频率最高的作为主pattern其他作为副pattern全部建category指向同一个template但template内容会根据副句子的特点微调。怎么判断等价还是部分等价我自己的标准是把两句话放到同一个上下文里如果机器人回答完全一样的内容不会显得违和就判定等价。比如今天天气怎么样和今天天气如何可以共用同一套回答今天冷不冷则建议单独回答因为用户问冷往往是想知道我该穿厚衣服吗这个语气上的微妙差别值得单独设计回答。去重算法上我不推荐单纯用模拟编辑距离因为中文短句改一两个字语义就可能完全变了。我的做法是结合归一化字符串完全匹配 语义变体清单人工审核在第一版手工过量大了以后才能在日志的辅助下做半自动归纳。3.5 第五步分类归档与命名规范一个完整的AIML语料库是由很多个.aiml文件组成的怎么组织直接决定了后期维护效率。我采用的是一领域一文件策略bot/ ├── aiml/ │ ├── basic.aiml # 自我介绍 │ ├── greeting.aiml # 寒暄 │ ├── food.aiml # 饮食 │ ├── weather.aiml # 天气 │ ├── emotion.aiml # 情绪陪伴 │ └── fallback.aiml # 兜底 ├── logs/ # 运行日志 ├── scripts/ │ ├── normalize.py │ └── load_logs.py └── README.md每个文件内部保持先核心意图、后扩展变体的排列并在category的注释里写清楚这个规则的设计意图。AIML支持在category上方加!-- 注释 --不要省这一步三个月后你会感激当时的自己。4. 把语料写进AIML标签规范与中文场景的实操细节4.1 最基础的category一个问答对的最小单元AIML文件的基本结构很简单每个category包含一个pattern和一个template?xml version1.0 encodingUTF-8? aiml version2.0 category pattern你叫什么名字/pattern template我叫小语你可以当我是你的闲聊伙伴。/template /category /aiml这里有一个在中文语料里容易踩的坑有的引擎对pattern中是否包含空格、全角字符非常敏感。如果你的预处理阶段已经把空格和标点都清理掉那么在语料文件里也应该存储同样清理后的状态否则测试时看上去一样的句子却匹配不上。4.2 通配符的边界中文里*容易吃太多AIML的通配符*和_用来匹配任意内容在英文语料里patternI LIKE */pattern可以覆盖I like musicI like playing games等一堆句子语义相对可控。但中文直接套这个思路会翻车比如pattern我喜欢 */pattern能匹配我喜欢你也能匹配我喜欢这个蓝色的外套语义范围太大同一条template根本没法兼顾。所以我总结了一个中文通配符设计原则通配符必须搭配意图关键词才能用而且关键词的优先级要高于通配符。具体做法是带通配符的pattern放在文件靠后位置让更具体的全匹配pattern优先命中同时template里不要试图回答通配符兜住的所有内容而是把话题推回去比如你自己喜欢*吗说来听听。4.3 that标签多轮对话的中文钩子AIML的that标签用于记录机器人上一轮的输出从而让下一轮匹配可以带上上下文。这个机制在多轮对话里几乎是中文语料的核心竞争力。举个例子设计一个美食推荐的多轮对话category pattern我不知道吃什么/pattern template那你喜欢什么口味呢比如辣的、清淡的还是甜食/template /category category pattern辣的/pattern that那你喜欢什么口味呢/that template辣的话我推荐试试麻辣香锅配上一碗冰粉很爽。/template /category category pattern清淡的/pattern that那你喜欢什么口味呢/that template清淡的话炖个鸡汤或者来一碗清汤面都不会出错。/template /category第一次匹配命中后机器人输出那你喜欢什么口味呢这个输出会被记录为that。用户回复辣的第二次匹配时引擎就会优先检索带对应that的category从而命中第二条规则。如果没有that限制辣的这种短句大概率会跑进兜底规则对话就断了。所以编写中文多轮对话语料时有一个技巧第一步不要问太开放的问题要用钩子句引导用户往你预设的几个方向走。因为你是语料设计者你能覆盖几个方向就只给几个选项问得太开放用户回答一个你没覆盖的词对话就会瞬间死亡。4.4 中文标签里的硬坑XML转义与编码AIML本质是XML所以所有XML转义规则都适用。中文语料本身没有额外问题但有一个场景要特别注意用户输入中可能包含、、、中文引号等字符这些在写进template或pattern时必须转义为amp;、lt;、gt;。另外文件头必须加encodingUTF-8如果保存时不小心用了GBK运行时会直接乱码。还有一个容易被忽略的是通配符匹配到的内容如果原样输出也要注意转义。比如用户问你知道什么是编程吗如果pattern里用了pattern你知道什么是*吗/patterntemplate里写template知道一点star/。/template这个编程两个字正常输出没问题但如果用户输入里含输出时也要做转义处理。稳妥的做法是写一个输出过滤函数对所有拼接了star/的结果统一做一遍HTML转义。4.5 一段完整的多轮对话示例以下是我当时饮食场景里的一段真实语料供参考整体结构category pattern我饿了/pattern template 饿了吗我猜你在纠结吃什么。我这里有三个思路火锅、烧烤、家常菜你想听哪个 /template /category category pattern火锅/pattern that我猜你在纠结吃什么/that template火锅是个好选择。一个人吃可以选小锅几个人一起可以点个鸳鸯锅。你喜欢什么锅底/template /category category pattern烧烤/pattern that我猜你在纠结吃什么/that template烧烤适合配点冰饮料但别吃太多容易上火。/template /category category pattern家常菜/pattern that我猜你在纠结吃什么/that template家常菜最稳。来一个番茄炒蛋再做一个蒜蓉空心菜简单又舒服。/template /category注意看that部分我没有写我猜你在纠结吃什么。我这里有三个思路火锅、烧烤、家常菜你想听哪个的完整句子而是只对归一化后的关键词部分做了限制。这里有个实操经验AIML的that匹配通常是包含匹配或整句匹配取决于具体引擎所以我在设计hook句时会刻意让它以固定句式结尾例如统一落到你想听哪个从而让that的匹配范围可控。5. 语料是养出来的测试、失配分析与迭代节奏5.1 让每一次失配都变成新语料的种子任何AIML语料库上线第一天都不可能做到高命中率。我第一版两三百条规则跑下来真实用户消息的失配率大概在40%左右意思是每10句话里有4句引擎找不到匹配。这个数字看起来很吓人但其实完全正常关键在于你有没有把失配内容接住。我的做法是写一个非常简单的脚本让聊天引擎把所有没有命中任何category的用户输入连同时间戳一起追加到logs/unmatched.jsonimport json from datetime import datetime def log_unmatched(text: str): entry {time: datetime.now().isoformat(), text: text} with open(logs/unmatched.json, a, encodingutf-8) as f: f.write(json.dumps(entry, ensure_asciiFalse) \n)然后每周固定抽一次日志按文本完全相同的频次做统计把频次超过3次的句子优先提取出来。这一步是化被动为主动不是等用户抱怨答非所问而是让用户天然的提问方式告诉你该补什么语料。5.2 用测试集守住已有语料的命门语料库最怕的不是少而是改坏了。你新增一条规则可能因为通配符放在前面覆盖掉了原来几条正常的规则。为了及时发现这种回退我建议为每个领域维护一个50到100条的黄金测试集这些是需要100%命中的典型用户问法。每次语料库更新后用脚本跑一遍黄金测试集统计命中率。我给自己定的标准是黄金测试集命中率低于90%时禁止发布新版本。这比人工抽查高效得多而且能明确感知到每一次修改带来的影响面。5.3 优先级排序什么语料先补失配日志里的句子虽然多但不能照单全收。我常用的排序逻辑是优先级条件例子处理策略P0频次高且和现有领域强相关今天吃什么立刻补categoryP1频次高但属于新领域帮我查快递新增领域先给一个引导式回答P2频次低但有明显意图打印机怎么用记入待办定期批量补充P3无意义噪声啊啊啊啊不做处理按这个表格每周花一两个小时处理一次新增语料即可。不要试图一次把所有失配都补完那是无底洞而且用户话题分布会随时间变化你需要的是可持续的迭代节奏。5.4 版本化语料库也是代码最后一点语料库文件务必纳入Git管理。每次修改后提交时在commit message里写下本次变更的领域范围和新增条目数比如food:新增20条火锅对话修复通配符误匹配。这样出了问题可以随时回滚也可以回溯某类语料是什么时候、因为什么原因加进去的。我自己在实际维护中还发现一件事当语料库从几百条涨到两三千条时失配率会经历一个明显的下降拐点。不是因为你的语料覆盖了所有可能的话题而是因为高频的闲聊型提问翻来覆去就那么些说法只要把这些高频表达兜住了剩下的低频问题你靠一条精心设计的兜底规则比如这个我还不太会你可以换个问法用户基本不会觉得这个机器人很蠢。6. 从问答对到角色感语料打磨的进阶方向语料库到了后面你会发现单纯追求答得上已经不够了更重要的是答得像一个人。同样一句你好一个冷酷版本的语料库回你好而一个有性格的语料库可能回哟终于来了今天过得怎么样。风格上的差异全靠语料撰写时的语气设计。我的经验是在语料数量稳定之后专门花一轮时间做角色一致性审查打开所有aiml文件逐条看template把所有过于生硬、像机器人的回答标识出来逐一改写。比如我不知道改写成这个问题我还真没想过你说说看呗对不起我不明白改写成呃这句话我没跟上换个说法试试。这一步看似只是改措辞实际影响非常大。用户对聊天机器人的体验上限并不取决于你覆盖了多少复杂问题而取决于那些最常见、最简单的对话里机器人说人话的程度。我的美食机器人最后被朋友夸奖最多的一次不是因为它推荐了多么精准的餐厅而是因为朋友说我饿了时它回了一句我也饿了可是我没有胃。——那是在一次语料打磨里随手加的玩笑规则却成了整个语料库的点睛之笔。所以如果你问我做中文AIML语料最值得投入精力的地方在哪我的答案不是算法不是标签语法而是语料本身的人味。把技术框架当作基础设施把语料当作一个角色的内心世界去经营这条路虽然慢但每一条规则都在积累价值。本文还有配套的精品资源点击获取
简介这是一份AIML中文语料库面向需要构建中文聊天机器人的开发者和自然语言处理学习者用于训练和优化对话模型的意图识别与回复生成。资源共91个文件以56个XML和35个AIML文件为主整个压缩包仅1.48MB语料按标准AIML结构组织覆盖闲聊、影视、音乐、美食、情感、星座、健康、编程等多个主题每个主题下都有成对的用户输入与机器人响应示例适合直接导入支持AIML的聊天引擎。目前已有1492人学习下载适合初学者对照句式模板理解AIML语法也适合进阶开发者快速扩充中文知识库、评估模型表现。由于语料从多个渠道收集并经过初步预处理表达方式多样借助这些语料开发者可以训练出理解中文口语化表达、识别用户意图并给出合理回复的机器人同时也可用于语义分析、情感识别等NLP任务或作为课程设计的实验素材帮助读者在真实对话数据中掌握AIML的结构化写法与中文语料组织方式。 真正动手整理AIML中文语料之前我先把这个关键词挂在搜索框里翻了一个晚上结果不算意外能下载到的所谓中文语料包要么是十几年前A.L.I.C.E.时代的古董配置回答内容停留在我是Alice我可以帮你这种远古老梗上要么是拿英文标准语料用机器翻译硬翻过来读起来一股子直译腔你问它你吃了吗它回你我是一个软件程序上下文完全接不上。所以我决定不依赖现成资源从零开始整理一套能真正跑起来、也能持续迭代的中文AIML语料。这套语料前后维护了半年多从最初两三百条问答对到现在覆盖十几个场景、两千多条有效规则。整个过程踩了不少坑也沉淀了一套相对稳定的整理方法今天把过程完整写出来给准备走这条路的人一个参考。1. AIML没死只是被低估了——中文语料为什么值得自己动手1.1 AIML到底是什么还在用什么场景AIMLArtificial Intelligence Markup Language是用于定义聊天机器人感知-回应规则的一种XML方言它的核心思路非常朴素用户输入一句话机器人在预先定义好的模板里找到最匹配的模式pattern然后返回对应的回答template。你问你叫什么名字它匹配到pattern你叫什么名字/pattern就回我叫小语。它的历史可以追溯到A.L.I.C.E.和Richard Wallace这在NLP圈子里算是活化石级别的产物。但活化石不等于没用。和现在流行的深度对话模型相比AIML天然具备几个难以替代的优点完全离线、无隐私风险、响应延迟几乎为零、回答内容完全可控、debug过程像一个普通的XML解析任务一样透明。这些特性决定了它特别适合做垂直领域的FAQ机器人、客服预判回复、儿童教育对话、角色扮演闲聊这类对准确率要求高、对花哨程度要求低的场景。所以我的判断是AIML这个壳子本身没有问题问题出在语料。一套贴合中文用户语言习惯、领域边界清晰的语料完全可以撑起一个体验不错的轻量级对话系统。1.2 为什么市面上的中文语料基本都不能直接用不是因为数量不够恰恰相反我能找到的语料包数量不少但质量天花板很低问题集中在三类。第一类是年代感太强。很多语料包还保留着你是男孩还是女孩你喜欢什么颜色这种十几年前的入门级对话没有城市天气、没有外卖、没有帮我定个闹钟这种现代用户会真实追问的场景。第二类是翻译腔。英文AIML里大量使用*通配符加上特定关键词的匹配结构直接翻译成中文后会出现我是你的*是什么这种句式中文用户根本不会这么说话。第三类是版权和来源不明很多语料包混着爬虫抓取的聊天记录没有整理过直接拿进生产环境会引发内容安全和管理上的麻烦。所以自己动手不是情怀而是务实。自己做语料意味着你可以控制话题边界、回答口径、风格的统一性也意味着未来每一条新增规则你都知道它的来源意图。1.3 这套方法适合谁如果你只是想快速跑个demo验证AIML能聊到什么程度直接装个Program AB用英文语料跑通即可不需要看这篇文章。但如果你要做的是一个面向中文用户、需要真实投入使用的场景——无论是给老板演示的智能客服原型还是想做一个有固定人设的闲聊机器人甚至是用来做儿童AI伴读实验——那么我下面这套中文AIML语料整理方法应该能帮你少走几个月弯路。2. 中文语料的中文难题翻译不是解药这一节聊的是AIML中文语料和英文语料最本质的差异。很多人接手中文AIML项目时第一个直觉是把英文语料翻译成中文不就行了结果做出来以后丢到测试群里被朋友的刁钻提问打得体无完肤。根本原因在于中文自身的特点让AIML这套源自英文的匹配机制水土不服。2.1 分词英文天然做了中文什么都没做AIML的匹配核心是字符串模式匹配英文天然有空格作为分词边界一个pattern就是一组单词序列匹配的时候通配符*可以很自然地对应一个或多个单词。但中文句子没有空格一个pattern就是一句话同一个语义用户可能有十几种说法比如你叫什么名字用户还有可能说你叫啥你的名字是什么怎么称呼你您贵姓这些都要分别建category。英文里一条patternWHAT IS YOUR NAME/pattern规则靠WHAT IS * NAME这种结构也能覆盖不少变体但中文的灵活性远超英文通配符设计不好就会误伤别人。这不是AIML的问题而是中文处理的原生难题。所以构建中文语料第一步不是写XML而是先想清楚归一化策略。2.2 全半角、简繁、标点语料膨胀的隐形推手写英文语料时大小写转换一把梭基本解决格式问题。中文没有大小写但有两个英文不太care的坑全角半角字符和简繁字体。用户发你好和你 好、发你好?还是你好、发繁体妳好还是简体你好在AIML的匹配引擎看来分别是完全不同的字符串。这就逼着你做一整套输入预处理把全角字符统一转半角把中文标点统一转成规范形式或者干脆去除把繁体转简体或者按需求保留两种把用户输入的可见空格全部去掉。这个归一化环节必须在命中文档之前完成否则你要靠语料本身去背各种写法的包袱语料量直接翻三四倍。我在实际项目里还发现一个容易被忽略的坑很多用户是语音输入会有你好呀呀这种叠字也有你在哪儿和你在哪这种口语缩略。这一类不靠归一化解决要靠语料设计时预留常见白话变体。2.3 中文的省略和语序AIML的上下文需要额外设计英文对话里Yes和No这种词可以独立成句中文用户很少单回一个字他们更爱说是呀没错嗯嗯甚至用表情包结束对话。这在AIML里的直接影响是很多在英文语料里只要一条规则就能覆盖的回复中文要补充三到五条。另外中文的语序非常灵活。你吃饭了吗、饭你吃了吗、吃了吗你三句话语序不同但语义几乎一样。英文靠变形和助词表达时态语态中文靠语序和语气词这在AIML的模板设计里意味着不能只考虑语义集合还要考虑用户最常见的表达列。我建议为每个核心意图建立一张变体清单变体数量低于3个的意图不必单独建category交给通配符去兜底即可。对比维度英文AIML语料中文AIML语料分词天然空格分词pattern粒度是单词无空格pattern粒度是整个句子格式归一大小写转换即可全半角、简繁、标点、空格都要额外处理口语变体变形少相对可控语序灵活省略多变体数量成倍增加上下文衔接靠that和topic机制即可同样靠机制但需要更细的钩子设计通配符设计按词匹配相对安全按字匹配一个*可能吃掉一整个分句2.4 所以能不能直接翻译英文语料结论是可以但不能直译只能语义移植。英文语料的价值在于它的对话结构和逻辑框架而不是句子本身。比如说英文里有一组关于天气的话题从weather的几个分支展开为下雨晴天台风这个结构框架可以直接借鉴但回答内容里的表达方式、语气、地理位置常识必须完全重写。我把这种方法叫结构复用、语言重写后面做语料规划时会反复用到。3. 语料整理五步法从散乱对话到可入库的问答对3.1 第一步划定领域与场景边界任何一个AI语料库不可能覆盖人类所有话题AIML尤其如此。AIML的强项是窄而精所以第一件事是明确要聊什么。我当时给小语定位的是一个生活闲聊型机器人圈定了五个领域基本信息自我介绍、年龄、性别、闲谈寒暄你好、再见、谢谢、饮食话题今天吃什么、美食推荐、天气话题天气怎么样、明天会下雨吗、情绪陪伴我很难过、我开心。划定范围以后你会发现语料需求一下子从无底洞变成一个可控的数量级。每个领域先按用户可能问什么问题和机器人应该回答什么内容做两列清单等清单基本覆盖了80%的常见提问再进入下一步。3.2 第二步收集原始数据原始数据的来源大概有这么几个公开的开源聊天语料比如一些社区贡献的对话数据注意看许可协议、微信群/QQ群脱敏后的闲聊记录这是金矿真实用户怎么说话全在里面、以及你自己脑子里的用户视角提问清单。我特别建议把真实日志作为最高优先级。很多时候你自认为设计得很全的语料上线第一天就被用户一句话击穿比如问你知道周杰伦吗你根本还没来得及建任何关于明星的category。所以从第一天起就要规划好失配日志的导出机制后面第5章会展开把用户没被匹配上的每一句话都记录下来然后定期把这些话补充成新语料。3.3 第三步清洗与规约原始数据不能直接进AIML否则会带进来一堆垃圾。我常用的清洗规则如下处理项规则原因超链接全部删除用户不会在闲聊中期待链接连续重复字符超过2个重复字合并比如哈哈哈规约为哈哈表情符号全部删除AIML模板里不适合存emoji长度过滤单句超过30个字丢弃过长句在闲聊中占比低且pattern难以命中私密信息手机号、微信号、地址正则删除合规和信息安全无意义噪声啊啊啊、等单独出现的丢弃没有信息量清洗完之后还有一步规约把所有句子统一走一遍和线上一样的归一化流程——全角转半角、中文标点去除、繁体转简体、英文转小写。这样你记录下来的语料和实际运行时用户输入经过的预处理保持一致。3.4 第四步语义等价的改写与去重这是整个流程里最费脑力的一步。比如用户会问今天天气怎么样今天天气如何今天冷不冷今天会不会下雨前两句语义几乎完全等价后两句则属于天气意图但带有额外诉求。我的做法是把等价句子归为一组组内选一个最自然、出现频率最高的作为主pattern其他作为副pattern全部建category指向同一个template但template内容会根据副句子的特点微调。怎么判断等价还是部分等价我自己的标准是把两句话放到同一个上下文里如果机器人回答完全一样的内容不会显得违和就判定等价。比如今天天气怎么样和今天天气如何可以共用同一套回答今天冷不冷则建议单独回答因为用户问冷往往是想知道我该穿厚衣服吗这个语气上的微妙差别值得单独设计回答。去重算法上我不推荐单纯用模拟编辑距离因为中文短句改一两个字语义就可能完全变了。我的做法是结合归一化字符串完全匹配 语义变体清单人工审核在第一版手工过量大了以后才能在日志的辅助下做半自动归纳。3.5 第五步分类归档与命名规范一个完整的AIML语料库是由很多个.aiml文件组成的怎么组织直接决定了后期维护效率。我采用的是一领域一文件策略bot/ ├── aiml/ │ ├── basic.aiml # 自我介绍 │ ├── greeting.aiml # 寒暄 │ ├── food.aiml # 饮食 │ ├── weather.aiml # 天气 │ ├── emotion.aiml # 情绪陪伴 │ └── fallback.aiml # 兜底 ├── logs/ # 运行日志 ├── scripts/ │ ├── normalize.py │ └── load_logs.py └── README.md每个文件内部保持先核心意图、后扩展变体的排列并在category的注释里写清楚这个规则的设计意图。AIML支持在category上方加!-- 注释 --不要省这一步三个月后你会感激当时的自己。4. 把语料写进AIML标签规范与中文场景的实操细节4.1 最基础的category一个问答对的最小单元AIML文件的基本结构很简单每个category包含一个pattern和一个template?xml version1.0 encodingUTF-8? aiml version2.0 category pattern你叫什么名字/pattern template我叫小语你可以当我是你的闲聊伙伴。/template /category /aiml这里有一个在中文语料里容易踩的坑有的引擎对pattern中是否包含空格、全角字符非常敏感。如果你的预处理阶段已经把空格和标点都清理掉那么在语料文件里也应该存储同样清理后的状态否则测试时看上去一样的句子却匹配不上。4.2 通配符的边界中文里*容易吃太多AIML的通配符*和_用来匹配任意内容在英文语料里patternI LIKE */pattern可以覆盖I like musicI like playing games等一堆句子语义相对可控。但中文直接套这个思路会翻车比如pattern我喜欢 */pattern能匹配我喜欢你也能匹配我喜欢这个蓝色的外套语义范围太大同一条template根本没法兼顾。所以我总结了一个中文通配符设计原则通配符必须搭配意图关键词才能用而且关键词的优先级要高于通配符。具体做法是带通配符的pattern放在文件靠后位置让更具体的全匹配pattern优先命中同时template里不要试图回答通配符兜住的所有内容而是把话题推回去比如你自己喜欢*吗说来听听。4.3 that标签多轮对话的中文钩子AIML的that标签用于记录机器人上一轮的输出从而让下一轮匹配可以带上上下文。这个机制在多轮对话里几乎是中文语料的核心竞争力。举个例子设计一个美食推荐的多轮对话category pattern我不知道吃什么/pattern template那你喜欢什么口味呢比如辣的、清淡的还是甜食/template /category category pattern辣的/pattern that那你喜欢什么口味呢/that template辣的话我推荐试试麻辣香锅配上一碗冰粉很爽。/template /category category pattern清淡的/pattern that那你喜欢什么口味呢/that template清淡的话炖个鸡汤或者来一碗清汤面都不会出错。/template /category第一次匹配命中后机器人输出那你喜欢什么口味呢这个输出会被记录为that。用户回复辣的第二次匹配时引擎就会优先检索带对应that的category从而命中第二条规则。如果没有that限制辣的这种短句大概率会跑进兜底规则对话就断了。所以编写中文多轮对话语料时有一个技巧第一步不要问太开放的问题要用钩子句引导用户往你预设的几个方向走。因为你是语料设计者你能覆盖几个方向就只给几个选项问得太开放用户回答一个你没覆盖的词对话就会瞬间死亡。4.4 中文标签里的硬坑XML转义与编码AIML本质是XML所以所有XML转义规则都适用。中文语料本身没有额外问题但有一个场景要特别注意用户输入中可能包含、、、中文引号等字符这些在写进template或pattern时必须转义为amp;、lt;、gt;。另外文件头必须加encodingUTF-8如果保存时不小心用了GBK运行时会直接乱码。还有一个容易被忽略的是通配符匹配到的内容如果原样输出也要注意转义。比如用户问你知道什么是编程吗如果pattern里用了pattern你知道什么是*吗/patterntemplate里写template知道一点star/。/template这个编程两个字正常输出没问题但如果用户输入里含输出时也要做转义处理。稳妥的做法是写一个输出过滤函数对所有拼接了star/的结果统一做一遍HTML转义。4.5 一段完整的多轮对话示例以下是我当时饮食场景里的一段真实语料供参考整体结构category pattern我饿了/pattern template 饿了吗我猜你在纠结吃什么。我这里有三个思路火锅、烧烤、家常菜你想听哪个 /template /category category pattern火锅/pattern that我猜你在纠结吃什么/that template火锅是个好选择。一个人吃可以选小锅几个人一起可以点个鸳鸯锅。你喜欢什么锅底/template /category category pattern烧烤/pattern that我猜你在纠结吃什么/that template烧烤适合配点冰饮料但别吃太多容易上火。/template /category category pattern家常菜/pattern that我猜你在纠结吃什么/that template家常菜最稳。来一个番茄炒蛋再做一个蒜蓉空心菜简单又舒服。/template /category注意看that部分我没有写我猜你在纠结吃什么。我这里有三个思路火锅、烧烤、家常菜你想听哪个的完整句子而是只对归一化后的关键词部分做了限制。这里有个实操经验AIML的that匹配通常是包含匹配或整句匹配取决于具体引擎所以我在设计hook句时会刻意让它以固定句式结尾例如统一落到你想听哪个从而让that的匹配范围可控。5. 语料是养出来的测试、失配分析与迭代节奏5.1 让每一次失配都变成新语料的种子任何AIML语料库上线第一天都不可能做到高命中率。我第一版两三百条规则跑下来真实用户消息的失配率大概在40%左右意思是每10句话里有4句引擎找不到匹配。这个数字看起来很吓人但其实完全正常关键在于你有没有把失配内容接住。我的做法是写一个非常简单的脚本让聊天引擎把所有没有命中任何category的用户输入连同时间戳一起追加到logs/unmatched.jsonimport json from datetime import datetime def log_unmatched(text: str): entry {time: datetime.now().isoformat(), text: text} with open(logs/unmatched.json, a, encodingutf-8) as f: f.write(json.dumps(entry, ensure_asciiFalse) \n)然后每周固定抽一次日志按文本完全相同的频次做统计把频次超过3次的句子优先提取出来。这一步是化被动为主动不是等用户抱怨答非所问而是让用户天然的提问方式告诉你该补什么语料。5.2 用测试集守住已有语料的命门语料库最怕的不是少而是改坏了。你新增一条规则可能因为通配符放在前面覆盖掉了原来几条正常的规则。为了及时发现这种回退我建议为每个领域维护一个50到100条的黄金测试集这些是需要100%命中的典型用户问法。每次语料库更新后用脚本跑一遍黄金测试集统计命中率。我给自己定的标准是黄金测试集命中率低于90%时禁止发布新版本。这比人工抽查高效得多而且能明确感知到每一次修改带来的影响面。5.3 优先级排序什么语料先补失配日志里的句子虽然多但不能照单全收。我常用的排序逻辑是优先级条件例子处理策略P0频次高且和现有领域强相关今天吃什么立刻补categoryP1频次高但属于新领域帮我查快递新增领域先给一个引导式回答P2频次低但有明显意图打印机怎么用记入待办定期批量补充P3无意义噪声啊啊啊啊不做处理按这个表格每周花一两个小时处理一次新增语料即可。不要试图一次把所有失配都补完那是无底洞而且用户话题分布会随时间变化你需要的是可持续的迭代节奏。5.4 版本化语料库也是代码最后一点语料库文件务必纳入Git管理。每次修改后提交时在commit message里写下本次变更的领域范围和新增条目数比如food:新增20条火锅对话修复通配符误匹配。这样出了问题可以随时回滚也可以回溯某类语料是什么时候、因为什么原因加进去的。我自己在实际维护中还发现一件事当语料库从几百条涨到两三千条时失配率会经历一个明显的下降拐点。不是因为你的语料覆盖了所有可能的话题而是因为高频的闲聊型提问翻来覆去就那么些说法只要把这些高频表达兜住了剩下的低频问题你靠一条精心设计的兜底规则比如这个我还不太会你可以换个问法用户基本不会觉得这个机器人很蠢。6. 从问答对到角色感语料打磨的进阶方向语料库到了后面你会发现单纯追求答得上已经不够了更重要的是答得像一个人。同样一句你好一个冷酷版本的语料库回你好而一个有性格的语料库可能回哟终于来了今天过得怎么样。风格上的差异全靠语料撰写时的语气设计。我的经验是在语料数量稳定之后专门花一轮时间做角色一致性审查打开所有aiml文件逐条看template把所有过于生硬、像机器人的回答标识出来逐一改写。比如我不知道改写成这个问题我还真没想过你说说看呗对不起我不明白改写成呃这句话我没跟上换个说法试试。这一步看似只是改措辞实际影响非常大。用户对聊天机器人的体验上限并不取决于你覆盖了多少复杂问题而取决于那些最常见、最简单的对话里机器人说人话的程度。我的美食机器人最后被朋友夸奖最多的一次不是因为它推荐了多么精准的餐厅而是因为朋友说我饿了时它回了一句我也饿了可是我没有胃。——那是在一次语料打磨里随手加的玩笑规则却成了整个语料库的点睛之笔。所以如果你问我做中文AIML语料最值得投入精力的地方在哪我的答案不是算法不是标签语法而是语料本身的人味。把技术框架当作基础设施把语料当作一个角色的内心世界去经营这条路虽然慢但每一条规则都在积累价值。本文还有配套的精品资源点击获取
仿真开发实战)
