【旅游酒店之一】多源主数据归一（Entity Resolution）：为什么智能行程编排的底座是枯燥的目录清洗

通顺的行程文案背后，为何常藏着难以兑现的预订冲突

设想一种常见的业务情形：旅行服务团队将多渠道供应商名录接入对话式规划工具，要求按家庭预算、同行人构成与交通衔接生成跨城行程。模型很快输出了一份图文并茂的方案，但进入人工核价与锁房环节时，计调人员却发现方案中容易出现已停业或无房的酒店、拼写相近却位于不同城区的同名场馆，或把同一邮轮在不同批发商处的别名当成不同的备选方案。

这种落差并非仅靠调整提示词就能消除。在复杂旅行服务中，可靠的行程编排以多源目录去重归一与记录链接为底座，再在真实库存与营业时间内做约束规划。跳过底层枯燥的目录清洗，直接让模型在杂乱数据上做自由生成，往往只能得到表面通顺却无法落地的文本。

从记录链接理论到多约束规划评测：数据底座与规划能力的双重挑战

为什么将多源记录对齐到同一真实实体如此困难？早在电子数据处理初期，Fellegi 与 Sunter（1969）便在记录链接理论中为这一问题建立了数学框架^[1]。该模型比较来自两个文件的记录特征向量 γ，以识别指向同一人、物体或事件的记录对，并在给定错误水平下将判定分为三类：链接（A1）、不链接（A3）与因证据不足而无法作出明确判定的“可能链接”（A2）^[1]。其中前两类明确处置伴随两类错误概率——将实际不匹配记录误判为链接（错误率 μ），或将实际匹配记录误判为不链接（错误率 λ）^[1]。最优链接规则的核心性质，是在固定错误率（μ, λ）的前提下，最小化落入“可能链接”（A2）的概率^[1]。这一经典结论揭示了一个工程事实：只要存在数据噪声与错误容忍边界，通常就会留下无法仅靠自动阈值消化的灰区记录（A2），需要进入补查与人工复核通道。

进入大数据环境后，主数据清洗的复杂度进一步上升。Christophides 等人（2020）关于端到端实体解析（Entity Resolution, ER）的综述指出，实体解析旨在识别指向同一真实世界实体的不同描述，是提升数据质量与分析可靠性的关键任务^[3]。当真实应用同时面临规模（Volume）、速度（Velocity）与多样性（Variety）中的多项特征时，来自数据库、语义网与机器学习领域的处理步骤与执行策略，必须应对实体描述的松散结构性、极端多样性、高速度与大规模挑战^[3]。在旅游供应链中，不同批发商、航司、酒店集团与目的地指南对同一地点、房型或航次的表述结构高度异构，正属于典型的端到端实体解析难题。

即便底层提供了结构化检索环境，仅靠语言智能体直接拼装多约束行程依然极为脆弱。Xie 等人（2024）提出的 TravelPlanner 基准测试，专门评估语言智能体在真实世界复杂旅行规划中的表现^[2]。该基准构建了包含近 400 万条数据记录的沙盒环境与配套检索工具，并整理了 1,225 条规划意图与参考方案^[2]。评测结果显示，现有语言智能体尚不具备处理此类复杂规划任务的能力——即便是评测中表现领先的商用大模型，最终成功率也仅为 0.6%^[2]。研究者指出，智能体往往难以持续聚焦任务、难以正确调用工具收集信息，也难以同时追踪多项约束条件^[2]。当多约束追踪本身的容错率已经极低时，倘若上游目录还充斥着未归一的重复实体与过期状态，规划结果就会偏离实际可预订范围。

目录归一与约束编排的工程解耦：从主数据清洗到版本化行程

将上述文献机制转化为系统架构，意味着必须把“主数据目录归一”与“多约束行程编排”拆分为职责分明、带有显式人工关口的工作流，而不是混入单次对话生成中。在 rlab.works 的能力版图中，这一分层横跨智能感知与智能中枢模块，并在旅游酒店行业下具备明确的源数据对应关系。

上游层负责目录去重与补全。在智能感知模块中，「多源资料合并（S28）」技能包以“授权来源、旧资料与目标目录字段”为初始输入契约，依次推进：

• 导入各方资料（辅助）：导入不同渠道记录，输出带出处的暂存资料和缺失记录。
• 合并同一对象（辅助）：可结合规范化的地理、酒店与 POI 实体及多供应商邮轮目录标准化等能力拆解异构结构，输出统一实体、明细关系与别名。
• 分类并标明缺口（辅助）：对齐分类体系，输出分类结果和待补事实清单。
• 补查并确认（人工复核）：对应 Fellegi-Sunter 模型中的灰区处置，将冲突记录与待补事实交由流程指定的复核人或提出请求的用户审阅，输出人工接受的目录事实与引用；被拒绝的产出退回修订，不进入下一步。

在旅游酒店行业，S28 的源数据有行业依据，设计用于把不同供应商的目的地、酒店和航次资料归并，补齐缺失事实后再进入目录；其适配边界在于不同供应入口需要独立字段契约以保留冲突和来源差异，且真实目录接线仍待实施。

下游层是在干净目录之上做受控规划。在智能中枢模块中，「计划制定与调整（S07）」技能包以“自然语言目标、时间与资源限制”为输入，依次执行：明确条件（辅助，输出已澄清的硬条件和偏好）、查找候选项（辅助，输出带来源的候选清单与约束）、生成计划（辅助，可借助版本化行程规划与重规划能力生成计划草案及与前版的差异）、选定方案（人工复核，输出人工选定的计划版本）与更新执行资料（辅助，输出已刷新资料、任务状态和待决变化）。S07 在旅游酒店行业同样属于源数据有行业依据，可将出行时间、预算和偏好转成可比较行程，经旅客确认后再刷新报价与候选；但刷新后的冲突需重新确认，且生成的计划不代表已完成预订。至于涉及地理坐标与路网计算的「地址核对与路线规划（S27）」技能包（定位地址、补充天气与时间、计算候选路线、在地图上确认），在站点目录中仅标注为物流行业的可迁移应用，并无旅游酒店行业标签，因此只能作为地址消歧与看图复核的通用工作流模式参考，不承诺最优路线或实时可通行。

需要诚实说明的是：站点所有技能包目前均为拟议编排，仅通过合成数据演示流程，尚未接入真实服务；底层原子能力虽基于静态源码检查具备可运行代码，但所谓“源数据有行业依据”仅表示底层源码库带有显式的行业领域关联，不代表已落地的客户部署或商业成效。

启动智能行程项目前的管理检验

在批准旅游或酒店场景的智能规划研发预算前，业务负责人与首席数据官可开展以下前置检验：

• 检验上游目录是否设立了灰区复核队列：不要只看演示环境中的成团方案，应检查多供应商酒店、航次与景点接入时，是否区分了高置信归并记录与待人工确认的冲突记录，以及是否保留了字段级来源出处。
• 检验约束校验是否与文本生成解耦：核实预算上限、同行人房型要求、营业时间窗等硬约束是否由结构化状态机与版本比对逻辑显式追踪，而非依赖大模型在长文本生成中自行记忆。
• 检验计划确认与库存锁定的责任边界：确认人工选定行程版本后，价格与库存刷新引发的冲突是否能强制触发重审，避免将未经核实的规划草案直接当成对客承诺。