簡介騰訊云出品的DataAI下一代數(shù)智平臺建設(shè)指南面向數(shù)據(jù)平臺負(fù)責(zé)人、架構(gòu)師與企業(yè)數(shù)字化決策者系統(tǒng)梳理了生成式AI與LLM時(shí)代企業(yè)數(shù)據(jù)平臺轉(zhuǎn)型的路徑與方法。報(bào)告詳細(xì)介紹WeData Agent、大數(shù)據(jù)智能管家TCInsight、數(shù)據(jù)分析智能體TCDataAgent、數(shù)據(jù)庫AI服務(wù)、BI智能助手ChatBI及向量數(shù)據(jù)庫等產(chǎn)品矩陣并圍繞DataOps、MLOps、Data與AI技術(shù)的可組裝性、多模態(tài)數(shù)據(jù)處理、統(tǒng)一元數(shù)據(jù)治理與合規(guī)等關(guān)鍵能力展開拆解。同時(shí)涵蓋AI數(shù)據(jù)湖TCLake、數(shù)據(jù)湖計(jì)算DLC、日志服務(wù)CLS、TBDS多模態(tài)數(shù)據(jù)湖倉等面向非結(jié)構(gòu)化數(shù)據(jù)管理需求的解決方案結(jié)合金融風(fēng)控、智能客服等典型場景說明從數(shù)據(jù)到智能的高效轉(zhuǎn)化邏輯。包體為1個(gè)PDF文檔整包約2.96MB結(jié)構(gòu)清晰、模塊完整已有145人學(xué)習(xí)瀏覽。適合希望把握頭部云廠商數(shù)據(jù)平臺演進(jìn)思路并對照自身數(shù)據(jù)底座規(guī)劃落地的讀者。 聊到“騰訊 DataAI 下一代數(shù)智平臺”我先說一句大實(shí)話數(shù)據(jù)團(tuán)隊(duì)和算法團(tuán)隊(duì)各干各的是大多數(shù)企業(yè)數(shù)智化轉(zhuǎn)型卡殼的根源。數(shù)據(jù)工程師把數(shù)倉搭得再漂亮算法工程師還是得從接口里現(xiàn)拉數(shù)據(jù)、現(xiàn)跑特征業(yè)務(wù)那邊催著要模型效果數(shù)據(jù)這邊卻還在講表結(jié)構(gòu)。所謂數(shù)智平臺核心就是把這條斷掉的鏈路重新接上——讓數(shù)據(jù)平臺能穩(wěn)定地喂給AI平臺干凈的數(shù)據(jù)讓算法人員能用最順手的方式把模型落到生產(chǎn)。我這篇指南會從項(xiàng)目選型、架構(gòu)設(shè)計(jì)、能力建設(shè)和運(yùn)維落地四個(gè)角度把做同類項(xiàng)目時(shí)驗(yàn)證過的思路和踩過的坑一起聊透。這篇文章適合正在規(guī)劃企業(yè)級數(shù)智平臺的架構(gòu)師、數(shù)據(jù)開發(fā)負(fù)責(zé)人、算法工程化同學(xué)也適合已經(jīng)在做數(shù)據(jù)中臺或AI中臺、但總覺得兩邊在“各玩各的”的團(tuán)隊(duì)。不管你是剛接觸這套理念還是已經(jīng)在折騰湖倉一體和模型服務(wù)按這套思路推下去至少能少走半年彎路。1. 項(xiàng)目概述先搞清楚數(shù)智平臺在解決誰的痛點(diǎn)1.1 數(shù)據(jù)與AI之間的接縫才是成本最貴的地方傳統(tǒng)企業(yè)里數(shù)據(jù)體系和AI體系是兩套獨(dú)立的班子。數(shù)倉團(tuán)隊(duì)負(fù)責(zé)離線表、日報(bào)、經(jīng)營分析算法團(tuán)隊(duì)負(fù)責(zé)推薦、風(fēng)控、客服模型。兩邊平時(shí)看著都在干活可真要做個(gè)“智能決策”項(xiàng)目時(shí)問題全冒出來了算法要的特征數(shù)據(jù)要么不在數(shù)倉里要么口徑跟業(yè)務(wù)報(bào)表對不上算法訓(xùn)練好的模型要用實(shí)時(shí)數(shù)據(jù)可實(shí)時(shí)鏈路沒人維護(hù)最后只能每小時(shí)拉一次離線快照湊合。我見過最夸張的一個(gè)項(xiàng)目算法工程師為了拿一份用戶行為特征先找數(shù)倉同事要表再找數(shù)倉同事要調(diào)度權(quán)限最后發(fā)現(xiàn)表里的字段和線上日志對不上又花了三周做清洗。等項(xiàng)目上線業(yè)務(wù)早就換方向了。這種“接縫”成本是隱性的不體現(xiàn)在任何一張預(yù)算表上但會實(shí)打?qū)嵉匕秧?xiàng)目的ROI拖垮。數(shù)智平臺要解決的就是這個(gè)問題把“收數(shù)、管數(shù)、算數(shù)、用數(shù)、訓(xùn)練模型、提供服務(wù)”全部放在一套底座里讓數(shù)據(jù)和AI之間的數(shù)據(jù)交換、口徑對齊、權(quán)限管控變成平臺默認(rèn)能力而不是靠人去協(xié)調(diào)。1.2 為什么拿騰訊這套體系做主線選騰訊DataAI這套體系來做主線不是因?yàn)椤按髲S”兩個(gè)字而是因?yàn)樗倪吔缱銐蛲暾牡讓釉圃A(chǔ)設(shè)施到對象存儲、湖倉一體計(jì)算引擎、實(shí)時(shí)計(jì)算Flink再到上層的AI訓(xùn)練平臺、模型服務(wù)和向量檢索都能在同一個(gè)云賬號下打通。騰訊內(nèi)部做微信、游戲、廣告這些業(yè)務(wù)時(shí)把同樣的架構(gòu)反復(fù)驗(yàn)證過很多輪真實(shí)業(yè)務(wù)場景的打磨比任何PPT都有說服力。另外配套資源也很重要。我在做平臺建設(shè)時(shí)經(jīng)常在騰訊云開發(fā)者社區(qū)查版本兼容方案鏡像也會統(tǒng)一推到騰訊云容器鏡像服務(wù)里管理訓(xùn)練和推理共用一份鏡像少踩了很多環(huán)境不一致的坑。后面所有實(shí)操內(nèi)容我會盡量落到“你也能在騰訊云上復(fù)現(xiàn)”的程度而不是講一堆虛的架構(gòu)理念。2. 整體架構(gòu)設(shè)計(jì)與技術(shù)選型思路2.1 湖倉一體與批流一體不是口號是底座這一代數(shù)智平臺的地基我理解就兩件事湖倉一體、批流一體。湖倉一體解決的是“數(shù)據(jù)都能裝、也能管”的問題。純數(shù)據(jù)湖能接任意格式的數(shù)據(jù)但缺乏事務(wù)、索引和約束業(yè)務(wù)部門用起來不放心傳統(tǒng)數(shù)倉治理能力強(qiáng)但擴(kuò)展非結(jié)構(gòu)化數(shù)據(jù)很痛苦。湖倉一體的做法是底層用對象存儲或分布式文件系統(tǒng)存所有原始數(shù)據(jù)上面用Iceberg、Hudi這類開源表格式來管理讓數(shù)據(jù)湖里的數(shù)據(jù)也能有事務(wù)、有元數(shù)據(jù)、有增量更新能力。AI要用的圖片、文本、日志和BI要用的寬表從此可以放在同一個(gè)存儲底座里。批流一體解決的是“口徑合一”的問題。離線批處理和實(shí)時(shí)流處理如果兩套計(jì)算邏輯、兩套表結(jié)構(gòu)白天看到的數(shù)據(jù)和實(shí)時(shí)大屏上的數(shù)字永遠(yuǎn)對不上。統(tǒng)一用一套SQL語義來描述批任務(wù)和流任務(wù)底層的狀態(tài)存儲、時(shí)間語義也按同一套規(guī)則來業(yè)務(wù)方才能放心用實(shí)時(shí)數(shù)據(jù)做決策。以騰訊這套體系的常見做法為例離線用Spark、實(shí)時(shí)用Flink但表結(jié)構(gòu)和口徑定義都收口在統(tǒng)一的元數(shù)據(jù)中心從源頭保證一致性。2.2 存儲、計(jì)算與AI資源怎么選型建設(shè)的時(shí)候我把資源分成四層存儲層對象存儲主打冷熱分層和低成本適合放原始數(shù)據(jù)、圖片、日志高性能分布式文件系統(tǒng)負(fù)責(zé)訓(xùn)練數(shù)據(jù)集這種高IO場景。通用計(jì)算層離線批次用Spark實(shí)時(shí)流用Flink交互式查詢用Presto或StarRocks這類MPP引擎。AI計(jì)算層GPU資源池用Kubernetes統(tǒng)一調(diào)度負(fù)責(zé)模型訓(xùn)練、在線推理和向量檢索。服務(wù)層統(tǒng)一API網(wǎng)關(guān)和權(quán)限中心把數(shù)據(jù)能力、特征能力、模型能力都包裝成服務(wù)。這個(gè)選型背后的邏輯很簡單不要指望一個(gè)引擎干完所有事。Spark擅長批處理但實(shí)時(shí)延遲下不來Flink擅長實(shí)時(shí)但跑大批量ETL不劃算Presto適合即席查詢但不適合大規(guī)模寫入。把合適的場景交給合適的引擎再用統(tǒng)一的元數(shù)據(jù)和調(diào)度平臺串起來看起來用了多套組件實(shí)際維護(hù)成本反而更低。這就像廚房里不能只靠一口鍋炒菜鍋、燉湯鍋、蒸鍋各有用途但最后端上桌的是一桌完整的菜。2.3 分層架構(gòu)與避免過度設(shè)計(jì)標(biāo)準(zhǔn)的分層一般是采集層、存儲層、計(jì)算層、服務(wù)層、AI應(yīng)用層。每層之間只通過明確的接口交互比如計(jì)算層只能通過目錄服務(wù)找到表服務(wù)層只能通過API網(wǎng)關(guān)訪問底層引擎。分層能保證團(tuán)隊(duì)并行開發(fā)時(shí)互不干擾數(shù)據(jù)工程師改存儲結(jié)構(gòu)算法工程師不需要感知算法上線新模型也不會把數(shù)倉的查詢拖垮。但我要提醒一句分層是為了清晰不是為了堆組件。我見過一個(gè)團(tuán)隊(duì)為了追求“下一代架構(gòu)”一開始就上了服務(wù)網(wǎng)格、多集群聯(lián)邦、數(shù)據(jù)編排框架結(jié)果半年過去了連一條核心鏈路都沒跑通。我的建議是第一版只做“采集-湖倉-特征-模型”這一條最小閉環(huán)其他能力能不加就不加。主線通了團(tuán)隊(duì)有了信心再一步步把治理、調(diào)度、成本優(yōu)化補(bǔ)上去。平臺不是一天建成的先讓業(yè)務(wù)看到結(jié)果你才有資格談架構(gòu)升級。3. 核心能力建設(shè)與實(shí)操要點(diǎn)解析3.1 統(tǒng)一元數(shù)據(jù)DataAI的粘合劑數(shù)智平臺能不能用起來關(guān)鍵看元數(shù)據(jù)。算法工程師要找一個(gè)特征如果還得靠問人平臺就是失敗的。我的做法分四步第一步把數(shù)倉、消息隊(duì)列、對象存儲里的元數(shù)據(jù)全量采集過來包括表名、字段、類型、分區(qū)、更新頻率第二步讓數(shù)據(jù)負(fù)責(zé)人補(bǔ)業(yè)務(wù)定義和負(fù)責(zé)人信息把技術(shù)元數(shù)據(jù)變成業(yè)務(wù)元數(shù)據(jù)第三步給核心表打標(biāo)簽比如“用戶活躍特征”“訂單交易事實(shí)”第四步通過調(diào)度日志自動解析數(shù)據(jù)血緣知道每張表的上游和下游是誰。這套體系建好之后算法同學(xué)自己就能在資產(chǎn)目錄里找到“最近更新、字段含義清晰、質(zhì)量分高”的表做訓(xùn)練集不用再給數(shù)倉團(tuán)隊(duì)提工單。從數(shù)據(jù)生產(chǎn)到AI消費(fèi)中間靠的是同一份元數(shù)據(jù)而不是人肉溝通。這里有一個(gè)容易被忽略的點(diǎn)元數(shù)據(jù)采集本身要設(shè)計(jì)成增量同步不然每天全量掃一遍Iceberg的元數(shù)據(jù)也會成為不小的負(fù)擔(dān)。我一般是十分鐘同步一次增量變更每天凌晨做一次全量對賬兩邊數(shù)據(jù)不一致時(shí)以底層存儲為準(zhǔn)重新拉取。3.2 實(shí)時(shí)鏈路搭建從業(yè)務(wù)庫Binlog到在線特征數(shù)智平臺里最容易被低估的是實(shí)時(shí)鏈路。實(shí)時(shí)特征直接影響推薦、風(fēng)控這類對延遲敏感的模型效果。我推薦的基礎(chǔ)鏈路是業(yè)務(wù)數(shù)據(jù)庫通過CDC工具監(jiān)聽Binlog變更寫入KafkaFlink從Kafka消費(fèi)做清洗和指標(biāo)計(jì)算結(jié)果落到在線特征存儲和離線數(shù)倉兩份數(shù)據(jù)用同一套口徑邏輯生成保證線上線下一致性。部署Flink時(shí)有四個(gè)參數(shù)我每次都會重點(diǎn)檢查并行度、Checkpoint間隔、狀態(tài)后端和空閑Source超時(shí)時(shí)間。并行度先按分區(qū)數(shù)估再根據(jù)實(shí)際吞吐調(diào)整Checkpoint間隔我一般設(shè)60秒太短會把狀態(tài)后端壓垮太長故障恢復(fù)時(shí)間會明顯變長狀態(tài)后端選RocksDB適合大狀態(tài)場景空閑Source超時(shí)設(shè)5分鐘避免連接永遠(yuǎn)掛著不釋放。這里有個(gè)很多人忽略的細(xì)節(jié)實(shí)時(shí)特征生成后一定要落一份離線副本。不要覺得“我有實(shí)時(shí)數(shù)據(jù)就夠了”模型回測需要?dú)v史特征報(bào)表核對需要離線口徑?jīng)]有這份副本后面線上線下的準(zhǔn)確率對不上時(shí)排查會讓你懷疑人生。實(shí)時(shí)鏈路和數(shù)據(jù)質(zhì)量監(jiān)控必須同步建設(shè)Kafka消費(fèi)Lag、Flink反壓、特征空值率這三個(gè)指標(biāo)我建議直接做成可視化大屏每天晨會掃一眼。3.3 數(shù)據(jù)服務(wù)化別讓業(yè)務(wù)方直連數(shù)倉平臺建完最大的問題是業(yè)務(wù)方直接用BI工具連底層表跑查詢。一兩個(gè)大查詢就能把數(shù)倉IO打滿影響所有離線任務(wù)。所以我在建設(shè)時(shí)堅(jiān)持加一層統(tǒng)一數(shù)據(jù)服務(wù)層。所有查詢都走統(tǒng)一SQL網(wǎng)關(guān)網(wǎng)關(guān)負(fù)責(zé)鑒權(quán)、解析、路由、限流和緩存。同一個(gè)SQL模板命中緩存就直接返回大查詢自動路由到Presto避免占用ETL資源池按賬號做優(yōu)先級核心業(yè)務(wù)可以插隊(duì)分析類任務(wù)排隊(duì)等待。實(shí)現(xiàn)上網(wǎng)關(guān)后面接一組無狀態(tài)服務(wù)自己維護(hù)一個(gè)小的SQL解析器按正則和語法樹識別查詢類型剩下的透傳給底層引擎。這個(gè)服務(wù)本身不存數(shù)據(jù)只做“路由管控”所以很容易水平擴(kuò)展。加上統(tǒng)一數(shù)據(jù)服務(wù)層之后最明顯的變化是數(shù)倉的負(fù)載峰值降了40%以上業(yè)務(wù)方也不再抱怨互相影響。對團(tuán)隊(duì)來說后續(xù)給算法提供API、給大模型提供知識庫檢索都是在這層服務(wù)之上繼續(xù)長出能力而不是再另起爐灶。4. AI能力接入與模型服務(wù)化4.1 特征平臺打通算法工程師不再自己搬數(shù)據(jù)數(shù)據(jù)和AI之間的橋重點(diǎn)在特征平臺。離線特征從數(shù)倉寬表生成在線特征從實(shí)時(shí)鏈路生成兩邊必須在同一個(gè)地方定義口徑避免線上線下一對不上就掉點(diǎn)。實(shí)踐中我建議把特征定義、特征版本、特征存儲都收口到一個(gè)平臺。存儲上離線特征放湖倉表在線特征放Redis或向量數(shù)據(jù)庫同一份特征的離線和在線版本通過特征名和版本號一一映射并寫到統(tǒng)一元數(shù)據(jù)里。這樣算法訓(xùn)練時(shí)用離線特征上線時(shí)直接引用同一個(gè)特征名平臺自動路由到實(shí)時(shí)存儲不需要改代碼。這里最值得投入的是特征血緣和特征質(zhì)量監(jiān)控。一個(gè)特征從原始日志到最終服務(wù)的每一步都要能追蹤每天定時(shí)比較離線特征和在線特征分布一旦偏差超過閾值就告警。特征壞了模型再牛也沒用這句話應(yīng)該刻在團(tuán)隊(duì)共識里。在實(shí)際推進(jìn)時(shí)我建議先挑一個(gè)核心業(yè)務(wù)場景做試點(diǎn)完整跑通特征上線流程再擴(kuò)大到全量特征否則一次性遷移所有特征風(fēng)險(xiǎn)太大。4.2 向量檢索與RAG應(yīng)用大模型落地的工程化路徑大模型落地目前最穩(wěn)的方向還是RAG——把企業(yè)私有知識庫切成片段向量化后存儲檢索出來喂給大模型做回答。好處是無需微調(diào)就能快速給業(yè)務(wù)提供有依據(jù)的問答能力而且知識更新只改向量庫不用重新訓(xùn)練。實(shí)操上流程大致是文檔解析、切片、Embedding、入庫、檢索、重排、生成。切片大小要按業(yè)務(wù)調(diào)太短上下文缺失太長檢索噪音變大我用下來500到800字一個(gè)切片比較穩(wěn)定。Embedding模型可以選商用API也可以自建開源模型如果數(shù)據(jù)量不大先用API跑通鏈路后期量大了再換自建。向量數(shù)據(jù)庫方面可以用騰訊云上的向量數(shù)據(jù)庫也可以選開源的Milvus。我傾向于在平臺早期就接入騰訊云向量數(shù)據(jù)庫因?yàn)樗蛯ο蟠鎯?、API網(wǎng)關(guān)的集成比較順團(tuán)隊(duì)不用自己運(yùn)維集群等數(shù)據(jù)規(guī)模真的增長到需要精細(xì)化調(diào)優(yōu)了再評估是否遷移到自建方案。RAG上線后一定要監(jiān)控兩件事檢索命中率和回答采納率。檢索命中率低說明切片或Embedding有問題回答采納率高但命中率低說明業(yè)務(wù)方在不依賴檢索的情況下也能答系統(tǒng)的價(jià)值就打折扣了。把這兩個(gè)指標(biāo)收進(jìn)項(xiàng)目周報(bào)團(tuán)隊(duì)才不會做得“看起來很美”。還要注意知識庫的更新頻率文檔改了向量庫里舊的切片要及時(shí)淘汰否則回答永遠(yuǎn)滯后。4.3 訓(xùn)練到推理一套鏡像打通開發(fā)與生產(chǎn)模型從訓(xùn)練到上線最大的坑是環(huán)境不一致。訓(xùn)練時(shí)用的Python版本、CUDA版本、依賴庫和線上不一致模型表現(xiàn)就會“原地跳水”。我的做法是把整個(gè)訓(xùn)練環(huán)境固化成容器鏡像鏡像構(gòu)建好之后推送到騰訊云容器鏡像服務(wù)訓(xùn)練和推理都從同一個(gè)倉庫拉取版本號一一對應(yīng)。模型產(chǎn)物和鏡像版本、訓(xùn)練腳本版本一起登記哪次推理效果異?？梢悦爰壎ㄎ坏接玫氖悄膫€(gè)版本。訓(xùn)練環(huán)節(jié)還需要注意資源隔離。多個(gè)算法團(tuán)隊(duì)共用GPU如果不用Kubernetes做配額管理一個(gè)團(tuán)隊(duì)的顯存泄漏會把整臺機(jī)器拖垮。我的經(jīng)驗(yàn)是按團(tuán)隊(duì)設(shè)資源組按項(xiàng)目設(shè)配額訓(xùn)練任務(wù)最多只能占用組內(nèi)資源的80%保證永遠(yuǎn)有資源處理緊急推理任務(wù)。推理服務(wù)要單獨(dú)部署和訓(xùn)練任務(wù)隔離開用彈性伸縮應(yīng)對流量波動沒有請求時(shí)自動縮容到零。這套規(guī)則推行下去之后團(tuán)隊(duì)之間因?yàn)閾孏PU吵架的事基本消失了。5. 落地部署與運(yùn)維經(jīng)驗(yàn)常見問題與排查技巧5.1 資源規(guī)劃與成本優(yōu)化DataAI平臺最容易被吐槽的就是成本。我的建議是三類資源分開預(yù)算存儲、計(jì)算和AI。存儲優(yōu)先做分層熱數(shù)據(jù)放高性能介質(zhì)溫?cái)?shù)據(jù)放普通對象存儲冷數(shù)據(jù)轉(zhuǎn)歸檔。很多平臺冷數(shù)據(jù)占了一半全放熱存儲就是在燒錢。計(jì)算資源按業(yè)務(wù)優(yōu)先級配額離線任務(wù)全部支持在低峰期執(zhí)行實(shí)時(shí)任務(wù)單獨(dú)預(yù)留資源。GPU資源更要用在刀刃上訓(xùn)練和推理分離推理服務(wù)做彈性伸縮沒有請求時(shí)自動縮容到零。成本埋點(diǎn)也要盡早做。每個(gè)任務(wù)、每個(gè)模型服務(wù)、每次查詢都要有成本標(biāo)簽月底按業(yè)務(wù)部門分?jǐn)偂Ｓ辛诉@個(gè)數(shù)據(jù)業(yè)務(wù)方才會主動優(yōu)化自己的查詢和模型調(diào)用頻率比平臺團(tuán)隊(duì)追在后面催效果好得多。實(shí)際運(yùn)營中我發(fā)現(xiàn)最容易被忽略的是“廢棄任務(wù)”。很多離線任務(wù)跑著跑著已經(jīng)沒有下游依賴了但調(diào)度器還在每天按時(shí)執(zhí)行。我建議每季度做一次任務(wù)治理把超過一個(gè)月沒有下游讀取的任務(wù)先暫停觀察兩周再刪除成本能肉眼可見地下降。5.2 數(shù)據(jù)鏈路延遲與口徑一致性排查我遇到最多的生產(chǎn)事故都指向同一類問題離線特征生成晚了模型還在用昨天的數(shù)據(jù)。排查時(shí)主要看三點(diǎn)第一上游ETL任務(wù)是否按時(shí)完成有沒有因?yàn)閿?shù)據(jù)量暴增而延遲第二調(diào)度依賴是否配置正確尤其是跨天任務(wù)有沒有正確識別業(yè)務(wù)日期第三數(shù)據(jù)質(zhì)量監(jiān)控是否觸發(fā)字段空值率、枚舉值分布有沒有異常。我把排查過程固定成一張速查表團(tuán)隊(duì)按順序檢查15分鐘內(nèi)基本能定位問題?，F(xiàn)象可能原因檢查動作模型效果突降離線特征表遲到或口徑變更查血緣對比特征表更新時(shí)間實(shí)時(shí)特征為空Flink任務(wù)失敗或Kafka堆積查Checkpoint、消費(fèi)Lag線上線下一對不上離線和在線特征口徑不同查特征版本映射對比生成邏輯API調(diào)用超時(shí)底層引擎負(fù)載高查網(wǎng)關(guān)路由和限流配置這張表看起來簡單但真出事的時(shí)候能救命。另一個(gè)容易被忽視的點(diǎn)是“調(diào)度依賴中的日期參數(shù)”。離線任務(wù)經(jīng)常要補(bǔ)算歷史數(shù)據(jù)如果日期參數(shù)寫死補(bǔ)數(shù)任務(wù)會和正常任務(wù)互相覆蓋。我的做法是所有任務(wù)統(tǒng)一用調(diào)度系統(tǒng)注入的業(yè)務(wù)日期參數(shù)補(bǔ)數(shù)時(shí)單獨(dú)跑一個(gè)實(shí)例寫不同的目標(biāo)分區(qū)從機(jī)制上避免沖突。5.3 權(quán)限與安全治理越早設(shè)計(jì)越省錢數(shù)據(jù)和AI融合之后權(quán)限問題會變得更復(fù)雜。數(shù)據(jù)權(quán)限要能管到行列級算法同學(xué)只能看到自己需要的那部分模型API要有單獨(dú)的調(diào)用憑證不能跟數(shù)據(jù)查詢混用模型服務(wù)的日志要脫敏不能讓Prompt里的業(yè)務(wù)數(shù)據(jù)原樣落盤。這些能力如果等到業(yè)務(wù)爆發(fā)之后再補(bǔ)成本會翻好幾倍。我的原則是第一版就把權(quán)限模型定義清楚按“最小夠用”原則分配。平臺提供三種角色數(shù)據(jù)生產(chǎn)者、數(shù)據(jù)消費(fèi)者、平臺管理員。數(shù)據(jù)消費(fèi)者默認(rèn)只能讀已發(fā)布的數(shù)據(jù)資產(chǎn)不能直接訪問底層存儲平臺管理員負(fù)責(zé)審批授權(quán)和看審計(jì)日志。別怕一開始繁瑣后面你會發(fā)現(xiàn)這套權(quán)限結(jié)構(gòu)幫團(tuán)隊(duì)擋掉了大量數(shù)據(jù)安全方面的麻煩。另外AI模型服務(wù)的安全也不能忽略模型API要加調(diào)用頻控和異常檢測防止有人拿業(yè)務(wù)API做批量抓取。上線前把安全審查加入發(fā)布流程等出了事再補(bǔ)往往已經(jīng)晚了。項(xiàng)目做到后半段我越來越覺得技術(shù)選型不是最難的難的是讓數(shù)據(jù)工程師、算法工程師和業(yè)務(wù)方在同一個(gè)平臺上“說同一種語言”。騰訊這套DataAI的思路真正有價(jià)值的地方不是某個(gè)引擎多強(qiáng)而是把元數(shù)據(jù)、特征、模型、API全部統(tǒng)一到一套體系里逼著大家按同一套規(guī)則協(xié)作。最后再分享一個(gè)實(shí)用小技巧如果你正在規(guī)劃類似的平臺先別急著把組件鋪滿。挑一條真實(shí)業(yè)務(wù)鏈路從數(shù)據(jù)庫到數(shù)倉、從特征到模型服務(wù)完整跑一遍哪怕過程中用一些看似“簡陋”的臨時(shí)方案也先讓業(yè)務(wù)看到結(jié)果。第一版跑通后再回頭補(bǔ)治理、補(bǔ)監(jiān)控、補(bǔ)成本優(yōu)化。平臺的價(jià)值永遠(yuǎn)在業(yè)務(wù)結(jié)果里不在架構(gòu)圖里。下次我再單獨(dú)寫一篇特征平臺和模型服務(wù)如何做版本管理的詳細(xì)配置那部分內(nèi)容比較多一篇塞不下到時(shí)候咱們接著聊。本文還有配套的精品資源點(diǎn)擊獲取