檢索命中了訂單和品牌卻沒有 SKU 中間表模型就可能發(fā)明一個不存在的直接連接。Schema 剪枝要解決的不是“盡量短”而是“在可用預算內留下夠用的關系”。10 月 20 日的分析 Agent 基準把多跳數(shù)據(jù)層的使用與計劃錯誤分開觀察。它不能證明某種剪枝器對所有企業(yè)都有效但能幫助我們提出一個更具體的測試問題相關表找到了連接路徑是否也保住了Agentic Analytics Benchmark 第二輪保留順序補齊必需路徑候選列表有排名不能先轉集合再取前三。外鍵補全也不是隨便拉進所有鄰居應從確認的核心表出發(fā)在可信關系圖中尋找路徑保留橋接節(jié)點。預算裝不下必要路徑時應失敗或反問而不是悄悄把橋表截掉。from collections import deque graph {orders: [items], items: [orders, brands], brands: [items]} def path_between(start, goal): queue deque([(start, [start])]) seen {start} while queue: node, path queue.popleft() if node goal: return path for neighbor in graph.get(node, []): if neighbor not in seen: seen.add(neighbor) queue.append((neighbor, path [neighbor])) raise ValueError(no approved join path) def prune(ranked_hits, max_tables4): selected list(dict.fromkeys(ranked_hits)) if not selected: return [] anchor selected[0] for target in selected[1:]: for table in path_between(anchor, target): if table not in selected: selected.append(table) if len(selected) max_tables: raise ValueError(required join graph exceeds budget) return selected answer prune([orders, brands, orders]) assert set(answer) {orders, items, brands} assert answer[:2] [orders, brands] print(answer)這是無權圖上的教學 BFS不是向量檢索或跨編碼器實現(xiàn)。圖中的邊應來自經過核對的關系元數(shù)據(jù)并包含主鍵、外鍵、基數(shù)與有效時間等信息最短的圖路徑也不一定具有正確業(yè)務粒度。該保留的不只是列名訂單表可能是訂單粒度明細表是一單多行品牌表還可能有緩慢變化版本。即便三表連通若 JOIN 后重復累計訂單實付額結果仍會錯。剪枝上下文需要附上粒度、去重規(guī)則與應使用的金額字段。評估時至少記錄表召回、橋表遺漏、最終結果正確率、上下文長度和延遲。只看 token 減少容易獎勵一個把正確答案也剪掉的算法。重排用真實打分器還是規(guī)則排序要在方案里說清楚不能把candidates[:k]標成已經完成了神經重排。本文沒有接入 embedding 服務、向量數(shù)據(jù)庫或真實模型也不提供“從 500KB 到 3KB”“準確率提升到 93.5%”的實測結論。先用一張小圖把連接關系解釋清楚再決定是否值得引入更復雜的檢索組件。延伸閱讀Agentic Analytics Benchmark 第二輪DuckDB 2.0.0 LTS 發(fā)布說明