北京
日本最大的服裝租賃平臺airCloset，數據庫里躺著991張表、15個Schema、橫跨11個SQL庫和6個MongoDB實例。CTO Ryan Tsuji上周公開了一個內部工具——DB Graph MCP，讓客服用大白話就能查生產數據。這不是Demo，是跑了10年的老系統真實改造。
一個具體場景：用戶App顯示"退貨已完成"，倉庫到底收到貨沒有？
答案分散在4張表里，跨兩個數據庫，中間靠一個varchar字段硬連，沒有外鍵。全公司能理清這條路徑的人，一只手數得過來。有人休假，調查就卡死。
這就是"數據民主化"最樸素的痛點：連接關系只存在特定人腦子里。
從"人形接口"到自然語言：工具設計拆解
Ryan Tsuji把解決方案拆成兩層。DB Graph是底層的元數據圖譜，把表、列、關系全部向量化；DB Graph MCP是暴露給Claude Code的接口層，遵循Anthropic的模型上下文協議（MCP，Model Context Protocol）。
核心工具只有三個。search_tables做語義檢索，輸入"return processing confirmation"，返回相關表及關系路徑；get_table_details拉取指定表的列信息、樣本值、關聯表；execute_sql執行只讀查詢，帶權限管控。
工具返回格式經過精心設計。search_tables會給出匹配分數、表用途描述、關聯路徑示意圖；get_table_details包含列名、數據類型、是否可為空、樣本值分布、關聯表及連接字段；execute_sql返回結果集的同時，附帶執行計劃和行數估算。
Ryan Tsuji特別強調：所有工具都返回結構化數據，而非自然語言描述。這讓LLM能基于確定格式做二次推理，而非解析模糊的文本回答。
圖譜構建：10年技術債的自動化梳理
991張表的關系圖譜怎么建？airCloset的做法是分層掃描。
第一層讀數據庫元數據：表名、列名、主外鍵約束、索引定義。第二層分析查詢日志，提取高頻JOIN模式——哪些表經常被一起查，哪些字段頻繁用于關聯。第三層人工標注關鍵業務路徑，比如上述退貨場景的四表鏈條。
三層數據融合后，用向量模型編碼。表和列的描述文本、業務標簽、關聯路徑全部嵌入同一空間。語義搜索時，"return processing"能命中receive_record表的status字段，即使表名里完全沒有"return"字樣。
一個細節：airCloset把varchar匹配關系也納入圖譜。warehouse_order_code到shipping_order_code的跨庫關聯，原本是"隱式知識"，現在成了顯式邊。
這解決了老系統最頭疼的問題——沒有外鍵約束的"軟關聯"大量存在，新人根本無從下手。
安全與權限：生產數據的"只讀沙箱"
讓客服直接查生產庫，聽起來像事故預告。Ryan Tsuji的解法是多層隔離。
執行層用只讀副本，物理隔離寫操作。權限層按角色分配Schema可見性——客服只能看aircloset和bridge，工程師按項目開放更多。查詢層加敏感字段脫敏，手機號、地址自動哈希。審計層全量記錄自然語言提問、生成的SQL、返回行數。
一個設計選擇：execute_sql拒絕任何包含UPDATE/DELETE/INSERT的語句，不是正則過濾，而是解析AST（抽象語法樹）后白名單校驗。Ryan Tsuji提到，曾有工程師試圖用CTE繞過限制，被AST掃描攔下。
脫敏規則也進圖譜。客服查user表，看到的phone列是"138****1234"格式；工程師申請后，同一查詢返回完整值。權限差異體現在工具返回的樣本值里，LLM自動適配。
實際效果：從"等人"到"直接問"
Ryan Tsuji給了一組內部數據。退貨狀態核實類問題，平均解決時間從4.2小時降到11分鐘。不是查詢變快了，是"找到該問誰、等對方有空、再口述教一遍"的循環被砍掉。
更隱蔽的變化是提問方式。以前客服的描述是"用戶說退貨完成了但倉庫沒收到"，工程師需要翻譯為"查aircloset.delivery_order.status和bridge.receive_record.status的關聯"。現在客服直接復制用戶原話丟給Claude Code，中間翻譯層消失。
一個意外發現：圖譜暴露了歷史設計問題。Ryan Tsuji團隊發現，"return"相關邏輯分散在7個Schema、23張表里，有些是2015年遺留的命名，有些是新業務硬接的。可視化后，重構優先級變得清晰。
這套系統目前只供內部使用，但Ryan Tsuji把MCP Server的實現細節全部開源。技術棧基于Python，圖譜存儲用Neo4j，向量檢索用pgvector，LLM層對接Claude 3.5 Sonnet。
他提到一個未解決的 tension：圖譜更新頻率。元數據變化實時同步，但查詢日志的JOIN模式分析是T+1，人工標注更是季度級。新表上線后，語義搜索可能"看不見"——直到有人手動標注或它出現在足夠多的查詢里。
10年積累的數據架構，能用3個工具、自然語言接口重新組織。但"隱式知識"的顯式化，究竟能自動化到什么程度？Ryan Tsuji在文末留了這個問題——那些最復雜的跨系統關聯，最終仍需老工程師的判斷，還是會被查詢日志的統計規律逐步捕獲？
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
