1. 先重新认识RasaCore负责的是接下来做什么1.1 从rasa_core到统一包为什么还有人称它为Core很多刚接触Rasa的人会把它当成一个意图识别框架来学装上NLU组件、训练出意图分类和实体抽取模型就以为对话机器人已经搞定了。但等真正面对多轮对话时才发现机器人不知道什么时候该追问、什么时候该调接口、什么时候该结束话题。这个下一步该做什么的判断就是Rasa Core的核心使命。这里要先交代一个历史背景。早期Rasa其实是两个独立项目rasa_nlu负责自然语言理解rasa_core专门负责对话管理。两者分开安装、分开训练所以老教程里会频繁出现Rasa Core这个称呼。后来Rasa进入2.x时代后合并成了一个统一的框架安装时直接装rasa这一个包就行但Core所承载的对话决策机制并没有消失只是变成了框架内部的核心引擎。所以在今天的Rasa项目里你依然会看到stories、rules、policies、Tracker、Slots、Forms这些词汇它们全部属于当年Rasa Core的范畴。理解了这层演化再去看网上那些rasa_core训练失败的旧教程就不会懵了。新旧版本虽然组织方式不同但底层思路一脉相承。这篇指南里我会以Rasa 3.x为准把Core相关的概念和实操从头到尾捋一遍。1.2 Core的决策链路从用户输入到Action的一整套流程用一句话概括Rasa Core的工作方式它根据当前的对话状态在众多候选动作中选出一个最合适的动作来执行。整条链路可以拆成下面几个环节用户发送一条消息例如帮我订一间大床房。NLU层先做意图识别和实体抽取得到intent: book_room、entity: room_type大床房。这些结果会作为事件写入Tracker对话状态跟踪器Tracker里的状态因此更新。Policy层基于Tracker当前状态给所有候选Action打分。得分最高的Action被选中并执行可以是回复模板、表单也可以是自定义Python动作。很多人容易忽略第3步和第4步的差异。NLU解决的是用户说了什么Core解决的是机器人接下来该怎么回应。如果只需要回答固定问题那用ResponseSelector做FAQ就够但一旦涉及条件判断、临时记忆、外部API调用就必须靠Core来维持整个对话的状态。这也是为什么Core才是Rasa真正区别于普通问答机器人的核心部分。1.3 什么时候你会真正需要Core我的建议是别盲目上Core。如果业务只是用户问商品规格机器人回答规格那不需要多轮对话状态管理用一套检索式问答就能跑。但只要有下面这些需求中的任何一个Core就是绕不开的对话过程中需要记录并持续引用用户提供的信息比如订房场景中的房型和日期。机器人需要根据当前上下文决定下一步动作比如房间类型没提供就继续追问提供了就调用预订接口。用户可能中途改变话题机器人还得能回到未完成的任务。需要接入外部系统比如查库存、下单、查天气等。Core的设计目标就是把这些对话状态显式地管理起来而不是靠一堆散落的全局变量硬扛。2. Tracker与Slots对话系统的记忆是怎么保存的2.1 Tracker到底帮你记了什么Tracker这个词直译过来是跟踪器它在Rasa里就是一个对话状态容器。每当一条消息进来或者一个动作执行完Rasa都会往Tracker里追加一条事件event。这些事件按时间顺序排列共同构成对话的完整历史。你可以把Tracker理解成一份对话流水账上面记录着用户的每一次输入消息内容、意图、实体。机器人执行过的每一个动作。槽位Slot的每一次设置和改变。当前是否有激活的表单Form。对话时间和会话ID等元信息。这里有个关键点Tracker里的历史是追加式的永远不会改写之前的记录。设计成这种只追加的日志结构是为了让Policy能回溯整个对话过程也方便调试时定位问题。在自定义Action里最常用的两个方法是tracker.get_slot(slot_name)和tracker.latest_message前者用来读取当前槽位值后者用来获取最近一条用户消息的结构化信息。还有tracker.events能直接拿到完整事件列表排查问题时很有用。我在日常开发里会把Tracker当作对话的数据库来对待。任何需要跨轮次记忆的信息都应该尽量落到Slot里而不是依赖Action里自己定义的外部变量。因为Action进程可能会被重启但Tracker里的Slot状态是跟随对话持久化存在的。2.2 Slot的类型与mapping配置Slot在Rasa中承担两个职责一是存储对话过程中收集到的信息比如用户名、日期、房型二是影响对话决策比如某个Slot的值决定了接下来走哪条分支。Rasa提供了多种Slot类型开发时选择哪种类型不是随意的它决定了这个Slot能否参与某些条件判断。我常用的类型有这些Slot类型说明适用场景text普通文本值存任意内容如订单号、日期字符串categorical有限类别值可配置映射房型、城市、区分大小写敏感的选项bool布尔值是否确认、开关状态float/list数值 / 数组价格、数量、多项选择any可存任意类型需要存储复杂对象时用Slot的赋值方式由mappings决定这也是Rasa 3.x里比较重要的一环。最常见的配置是from_entity意思是只要NLU从这个槽位对应的实体里抽到了值就自动填进Slot。例如slots: room_type: type: text mappings: - type: from_entity entity: room_type这样用户说我要大床房NLU抽出entity: room_type大床房后Rasa就会自动把room_type槽位设为大床房。还有一种容易踩坑的映射是from_text它会直接把用户最近一条消息的原文填进槽位。看起来方便但很容易把无关闲聊内容误存进来。比如用户本来在说今天天气不错如果某个槽位配了from_text就可能被填成这句废话从而污染对话状态。我的原则是能用from_entity或from_intent解决的绝对不用from_text。这里补充一个经验Slot的分类要尽量跟实际业务语义对齐。比如房间类型只有大床房、双床房、套房几种就该用categorical而不是text。原因很简单categorical类型在Policy做特征化时会变成离散特征对模型学习哪些槽位值会影响决策更友好而text类型需要额外处理成向量效果有时候反而飘。2.3 表单的生命周期Form如何自动收集槽位Forms是Rasa Core里最实用的机制专门解决多轮收集信息这类问题。比如订房需要房型和日期用户不一定一次性说完机器人就要一轮一轮追问。Forms把这件事变成了声明式配置不需要你在代码里写一堆状态判断。一个典型的Form定义长这样forms: room_booking_form: required_slots: - room_type - date只要这个表单被触发它会检查required_slots里的每一个槽位谁还没被填就自动生成提问动作utter_ask_slot名填完一个就继续下一个直到全部填完才释放控制权。整个过程有三个状态需要重点理解active_loop表单激活后Rasa会在Tracker里记录active_loop: room_booking_form表示当前处于表单收集中。requested_slot表示当前正在请求哪一个槽位。用户在填完当前槽位前如果说了别的话Form会根据这个字段决定是否忽略。active_loop: null所有槽位都填完表单关闭控制权交回正常Policy。这三个状态在debug日志里非常显眼。很多初学者遇到Form一直在问同一个槽位的问题其实就是因为requested_slot对应的提问动作没有定义或者NLU没能从用户回答中抽出对应实体。后面第5章我会专门讲怎么排查这类问题。3. Stories、Rules、Policies三种教对话的方式不能搞混3.1 Stories给TEDPolicy看的对话示范课Stories是Rasa Core训练数据的核心形式它用示例对话的方式告诉模型当用户这样说、系统这样回应之后下一步应该怎么走。每一段Story就是一条完整的对话路径由一系列用户意图和系统动作组成。下面是一个订房场景的Story示例stories: - story: 订房常规路径 steps: - intent: greet - action: utter_greet - intent: book_room - action: room_booking_form - active_loop: room_booking_form - slot_was_set: - room_type: 大床房 - slot_was_set: - date: 2024-06-01 - active_loop: null - action: action_book_room注意Story里虽然写了具体的槽位值大床房、2024-06-01但训练时Rasa并不会把这些值当成唯一匹配条件而是让模型学到这种情况下使用这类槽位特征的规律。所以数据里最好覆盖不同的值和不同的措辞给模型足够的泛化空间。这里有个很关键的心态转变写Stories不是在写死规则而是在准备训练语料。它和传统软件开发里的单元测试很像——你提供的Story越全面Policy学到的决策模式就越丰富。如果只写了一两条路径模型遇到没见过的表达方式就可能乱猜。所以我会建议至少为每一个核心业务路径准备3-5条Story变体变化的点包括用户先说哪个槽位、是否中途插入无关信息等。3.2 Rules不可动摇的硬规则Rules解决的是某些行为必须无条件执行的问题。比如用户说你好机器人就应该立刻打招呼表单激活后如果用户没有提供任何槽位信息机器人就应该继续追问。这些逻辑如果丢给TEDPolicy学习可能因为数据噪音而学不精准所以Rasa提供了Rules机制用配置强制固定。一个典型的Rule定义如下rules: - rule: 激活订房表单 steps: - intent: book_room - action: room_booking_form - active_loop: room_booking_form - rule: 表单未填完就继续追问 steps: - active_loop: room_booking_form - active_loop: room_booking_form - action: utter_ask_room_typeRules的优先级天然高于从Stories里学到的模式这是设计上的有意为之。当Rule生效时它会把行为锁死不管TEDPolicy预测什么都按Rule走。所以在写Rule时要克制只把那些无论如何都必须这样回应的逻辑写成Rule比如表单激活、意图追问、低频兜底。凡是带有泛化空间的对话流转尽量交给Stories去喂给模型。3.3 Policies的分工和优先级Policies是Rasa Core的决策引擎作用于整个对话状态并输出每个动作的置信度分数。3.x版本的config.yml里默认会启用三种Policy它们各有分工Policy默认优先级作用是否需要训练RulePolicy6执行Rules和兜底Fallback逻辑不依赖深度学习MemoizationPolicy3精确匹配历史上出现过的Stories无需额外训练TEDPolicy1用神经网络泛化对话模式需要深度训练RulePolicy优先级最高这是为了保证Rules永远优先被采纳MemoizationPolicy次之它会把训练数据里的Story逐条记下来如果当前对话状态和某条Story完全一致就直接给出对应动作TEDPolicy则是主力模型它基于Transformer编码对话历史并计算当前状态下每个候选动作的匹配度即使对话路径没有在Stories里出现过也能通过泛化能力给出合理预测。config.yml里关于Policy的配置通常长这样policies: - name: MemoizationPolicy - name: RulePolicy - name: TEDPolicy epochs: 100 max_history: 5这里的max_history很关键它表示Policy在决策时最多回看多少轮对话历史。值太小模型记不住早期信息无法做出依赖长上下文的决策值太大训练和推理开销上升且可能过拟合。日常我从5开始调场景需要长上下文时再提升。3.4 三种方式冲突时会发生什么实际开发中最常见的冲突场景是某条路径同时出现在Stories和Rules里但行为定义不一样。由于RulePolicy优先级最高最终线上表现会遵循Rules而不是TEDPolicy从Stories里学到的模式。很多人遇到这种情况会下意识地疯狂增加Stories样本结果发现行为毫无变化原因就在这里。我的建议是先运行rasa data validate检查规则冲突再结合rasa shell --debug看实际生效的预测来源。如果确认是Rules锁死了行为就回头审视Rule是不是写得过于宽泛。比如用户询问天气这种动作往往写成Story让模型泛化更合适没必要写成Rules。Rules应该聚焦在必须做和绝对不允许做这两个极端场景上。4. 从零搭一个酒店订房机器人开发实操全记录4.1 初始化项目与目录结构先用命令初始化一个Rasa项目这里我以3.x为例pip install rasa rasa init --no-prompt初始化完成后的目录结构通常是这样. ├── actions/ # 自定义Action服务代码 │ ├── __init__.py │ └── actions.py ├── data/ # 训练数据 │ ├── nlu.yml # 意图与实体样本 │ ├── stories.yml # Stories │ └── rules.yml # Rules ├── config.yml # NLU Pipeline 和 Policies 配置 ├── domain.yml # 领域配置intents/slots/responses/actions/forms ├── endpoints.yml # Action Server等端点配置 ├── credentials.yml # 通道凭证 └── models/ # 训练输出目录如果是老版本迁移过来的项目要注意data/下可能还有core/和nlu/两个子目录新版本统一放在平级文件里了。这个差异虽然不大但经常导致老教程的命令在新环境里对不上号。4.2 domain.yml先定义好对话本体Domain文件相当于整个对话系统的本体定义。所有意图、实体、槽位、动作、回复模板都要在这里预先声明否则训练时Rasa会报错或者忽略未声明的元素。下面是订房机器人精简版的domain.ymlversion: 3.1 intents: - greet - book_room - inform entities: - room_type - date slots: room_type: type: text mappings: - type: from_entity entity: room_type date: type: text mappings: - type: from_entity entity: date responses: utter_greet: - text: 你好我是酒店预订助手需要我帮你订房吗 utter_ask_room_type: - text: 你想订什么类型的房间大床房、双床房还是套房 utter_ask_date: - text: 请问入住日期是哪天 utter_ask_confirm: - text: 确认预订 {date} 的 {room_type}对吗 actions: - action_book_room forms: room_booking_form: required_slots: - room_type - date session_config: session_expiration_time: 60 carry_over_slots_to_new_session: true这里有几个容易忽略的点。第一utter_ask_slot这类提示语必须写在responses里如果Form里声明了required_slots但漏了对应的提问模板运行时Form会直接报错。第二actions列表里必须显式声明自定义Action的名称否则Action Server即使写了代码也不会被调用。第三session_expiration_time单位是分钟设定对话会话的过期时长对长期闲置会话的回收很重要。4.3 config.ymlPipeline和Policies参数怎么定config.yml是Rasa的全局配置包含NLU特征提取组件和Policy选择两大部分。中文场景下Pipeline里的Tokenizer是重中之重。一个可用的中文配置大致如下recipe: default.v1 language: zh pipeline: - name: JiebaTokenizer - name: RegexFeaturizer - name: LexicalSyntacticFeaturizer - name: CountVectorsFeaturizer - name: CountVectorsFeaturizer analyzer: char_wb min_ngram: 1 max_ngram: 4 - name: DIETClassifier epochs: 100 constrain_similarities: true - name: EntitySynonymMapper - name: ResponseSelector epochs: 100 policies: - name: MemoizationPolicy - name: RulePolicy - name: TEDPolicy epochs: 100 max_history: 5如果不用JiebaTokenizer而直接用WhitespaceTokenizer中文句子会被按空格切分但中文文本通常没有空格导致整个句子被当成一个token意图和实体抽取效果都会很差。所以做中文对话机器人时第一件事就是确认Tokenizer是Jieba。另外CountVectorsFeaturizer配合analyzer: char_wb可以为中文提供字符级别的特征能显著提升实体和意图识别的鲁棒性。数据量不大的项目里epochs调到80-100就够了太大了容易过拟合。4.4 编写Stories、Rules和自定义Actiondata/stories.yml的内容对应对话的常规流转路径比如stories: - story: 订房成功路径 steps: - intent: greet - action: utter_greet - intent: book_room - action: room_booking_form - active_loop: room_booking_form - slot_was_set: - room_type: 大床房 - slot_was_set: - date: 2024-06-01 - active_loop: null - action: action_book_room - intent: affirm - action: utter_greetdata/rules.yml则用来固定那些不能商量的逻辑rules: - rule: 订房意图激活表单 steps: - intent: book_room - action: room_booking_form - active_loop: room_booking_form - rule: 表单过程中用户没提供有效信息就继续追问 steps: - active_loop: room_booking_form - active_loop: room_booking_form - action: utter_ask_room_type接下来是自定义ActionAction是Core与外部世界交互的桥梁。它读取Tracker里的槽位调用内部逻辑或外部API最后返回回复信息和事件。一个最简单的订房Action长这样from typing import Any, Text, Dict, List from rasa_sdk import Action, Tracker from rasa_sdk.executor import CollectingDispatcher class ActionBookRoom(Action): def name(self) - Text: return action_book_room def run( self, dispatcher: CollectingDispatcher, tracker: Tracker, domain: Dict[Text, Any], ) - List[Dict[Text, Any]]: room_type tracker.get_slot(room_type) date tracker.get_slot(date) # 这里可以写调用真实酒店预订API的逻辑 # 比如 requests.post(https://..., json{date: date, room_type: room_type}) dispatcher.utter_message(textf已经为你预订了 {date} 的 {room_type}稍后会发送确认短信。) return []Action返回的列表里可以携带任意事件比如更新槽位、重置表单、重新开始对话等。常用的事件类型有SlotSet、Restarted、UserUtteranceReverted等。实际业务中SlotSet用得最频繁它允许在Action内部根据外部系统返回值修正对话状态。4.5 训练、启动与联调完成上述文件后按顺序执行下面的命令# 训练模型 rasa train # 启动自定义Action服务 rasa run actions # 另开一个终端进入对话调试 rasa shellrasa train会同时训练NLU和Core两部分产出模型放在models/目录。rasa run actions必须单独开进程因为自定义Action运行在独立的Action Server里与Rasa主服务通过HTTP通信。如果ActionExecutionRejection错误频繁出现九成是Action Server没启动或者自定义Action没有在domain.yml的actions列表里声明。endpoints.yml里确认一下Action端点配置action_endpoint: url: http://localhost:5055/webhook只要rasa run actions默认监听5055端口这个配置一般不用改。5. 对话翻车时怎么查几个高频问题的完整排查链路5.1 用rasa shell --debug追踪每一步决策对话行为不如预期时最高效的手段是开启调试模式rasa shell --debug这个命令会在每一轮对话后打印详细的决策日志包括用户消息解析出的意图和实体。Tracker当前收到的所有事件。每个Policy分别输出了什么动作、置信度多少。最终选中的Action及其来源。日志里会明确标注rule policy、memoization policy、ted policy各自的预测结果这对定位为什么走了这条路而不是那条路非常关键。我排障时不会先改代码而是先跑上几条调试对话把日志里的Policy输出对比一遍通常问题根源很快就能浮出水面。举个例子如果用户说我要大床房但日志里显示NLU把实体抽成了room_type双床房那问题就不在Core而在NLU训练数据上如果NLU结果正确但TEDPolicy没有选中表单激活动作那就要检查Stories里是否有覆盖这条路径。5.2 用rasa interactive修正对话路径如果说rasa shell --debug是事后看日志rasa interactive就是边聊边修正。它允许你扮演机器人的角色在对话过程中手动指定正确的Action最终把这些人工确认过的路径自动保存为新Stories。rasa interactive --model models/执行后在对话界面里每一步都可以选择让机器人执行哪个Action还可以手动设置槽位值。对话结束后Rasa会提示你把这段修正路径保存到Stories文件里。这个功能对打磨对话流程极其有用尤其是面对那些手写YAML容易漏掉的边缘情况时它能把你的纠偏直接沉淀成训练数据。我自己的习惯是先让机器人跑一轮裸数据对话在rasa interactive里把明显不对的回应纠正过来保存成Stories再训练。迭代几个版本后对话质量会肉眼可见地提升。比闭着眼睛往YAML里堆数据高效得多。5.3 高频问题排查表与处理经验最后把实际开发中遇到最多的几个问题列成表格方便对照症状可能原因处理方式ActionExecutionRejectionAction Server未启动或Action名未声明确认rasa run actions在跑检查domain.yml的actions列表表单一直卡在同一个槽位utter_ask_slot模板缺失或NLU无法抽取对应实体补全Response模板检查实体抽取结果Policy行为与Stories不符Rules优先级过高或Story样本不足审查Rules范围增加Story变体意图总被识别为low_confidence训练样本重叠度过高增加区分度高的样本调整threshold参数中文分词把整句切成一坨Tokenizer配置错误确认JiebaTokenizer已配置并安装依赖模型加入新数据后行为回退没有重新训练或过期模型仍在加载重新rasa train并重启rasa shell还有一个经验容易踩坑在rules.yml里写了太多细颗粒度规则。Rules虽然省事但会覆盖模型学到的泛化模式写多了整个对话系统会退化成一张密密麻麻的if-else表丧失多轮对话的灵活性。能用Story解决的问题尽量不要用Rule去兜底。我在实际项目里还会定期跑rasa data validate在训练前把数据格式问题和规则冲突提前暴露出来。对话数据其实也是一种代码需要认真维护和版本管理否则项目跑久了连自己都说不清某个行为是哪条Story带来的。最后分享一个长期实践的感受Rasa Core的开发本质上是对话数据的组织工程而非纯编码工程。模型结构是现成的真正决定机器人智商的是Stories、Rules和Domain这三份配置的质量。每改一次对话行为先想清楚它是该属于规则还是示例再动手这个判断比任何调参都重要。后面再做新项目时我也会先用rasa interactive快速跑出一条主链路、保存Stories再回头补NLU样本整个过程会顺畅非常多。