【旅遊酒店之一】多源主數據歸一（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）」技能包（定位地址、補充天氣與時間、計算候選路線、在地圖上確認），在站點目錄中僅標註為物流行業的可遷移應用，並無旅遊酒店行業標籤，因此只能作為地址消歧與看圖複核的通用工作流模式參考，不承諾最優路線或實時可通行。

需要誠實説明的是：站點所有技能包目前均為擬議編排，僅通過合成數據演示流程，尚未接入真實服務；底層原子能力雖基於靜態源碼檢查具備可運行代碼，但所謂「源數據有行業依據」僅表示底層源碼庫帶有顯式的行業領域關聯，不代表已落地的客戶部署或商業成效。

啓動智能行程項目前的管理檢驗

在批准旅遊或酒店場景的智能規劃研發預算前，業務負責人與首席數據官可開展以下前置檢驗：

• 檢驗上游目錄是否設立了灰區複核隊列：不要只看演示環境中的成團方案，應檢查多供應商酒店、航次與景點接入時，是否區分了高置信歸併記錄與待人工確認的衝突記錄，以及是否保留了欄位級來源出處。
• 檢驗約束校驗是否與文本生成解耦：核實預算上限、同行人房型要求、營業時間窗等硬約束是否由結構化狀態機與版本比對邏輯顯式追蹤，而非依賴大模型在長文本生成中自行記憶。
• 檢驗計劃確認與庫存鎖定的責任邊界：確認人工選定行程版本後，價格與庫存刷新引發的衝突是否能強制觸發重審，避免將未經核實的規劃草案直接當成對客承諾。