一、背景一套跑了一年的三件套1.1 先說項目我在一家制造企業(yè)做平臺開發(fā)。去年接了個活兒給內(nèi)部客服和售后搭智能問答說穿了就是 RAG。把幾十年的產(chǎn)品手冊、維修案例、工單記錄喂給大模型一線員工提問的時候系統(tǒng)把最相關(guān)的資料片段撈出來遞給模型模型再組織成人話回答。去年上的線。用的人不少日均幾千次提問吧。別看我現(xiàn)在說得輕巧當(dāng)年的架構(gòu)可是照著行業(yè)標(biāo)配抄的三件套。MySQL 存業(yè)務(wù)元數(shù)據(jù)和文檔目錄一個專用向量數(shù)據(jù)庫存 embedding中間靠 ETL 任務(wù)搬磚。就這套東西跑了一年。1.2 當(dāng)時是怎么切的分工大概這樣。文檔正文和切片進(jìn) MySQL運(yùn)營同事要審核管理嘛。切片算出來的 embedding 灌進(jìn)向量庫建 ANN 索引管相似度檢索。至于權(quán)限、產(chǎn)品線、有效性這些業(yè)務(wù)屬性兩邊都存了一份向量庫里放元數(shù)據(jù)字段用來過濾MySQL 里那份當(dāng)權(quán)威版本。算法組的小林當(dāng)時就嘀咕過說兩邊都存早晚要出事。我還挺不耐煩回他說 ETL 十分鐘跑一次呢能出啥事。嗯。這個 Flag 立得相當(dāng)標(biāo)準(zhǔn)。二、出事了機(jī)器人把停產(chǎn)貨當(dāng)現(xiàn)貨賣2.1 周二下午售后群炸了。機(jī)器人信誓旦旦地告訴客戶某款停產(chǎn)大半年的控制器目前有貨可以下單。客服沒多想照著回了?？蛻暨€真去下了單。我到現(xiàn)在都記得排查的過程。順著問題向量去檢索命中的確實是那款產(chǎn)品的資料相似度還挺高檢索這步?jīng)]毛病。回頭查元數(shù)據(jù)MySQL 里這條產(chǎn)品三個月前就標(biāo)記停售了。卡在哪兒ETL。某次向量庫升級之后同步任務(wù)的鑒權(quán)配置失效了。注意啊任務(wù)沒報錯它就是安靜地不干活了。停售標(biāo)記從頭到尾沒走到向量庫的過濾字段里。更頭皮發(fā)麻的是這種安靜失敗不是頭一回。上一次是權(quán)限字段某部門的文檔下線了向量庫里的副本還活得好好的測試同學(xué)閑逛才發(fā)現(xiàn)的。兩次一個根兒。同一份業(yè)務(wù)事實存兩個系統(tǒng)靠異步任務(wù)保持一致那延遲和漂移就不是會不會發(fā)生的問題了只是什么時候被人撞見的問題。2.2 復(fù)盤會上算的賬復(fù)盤會開完我沒走一個人把這一年的賬攤開來算了算。同步鏈路四道工序解析、切片、向量化、搬運(yùn)哪道都可能卡住監(jiān)控只蓋得住兩道?；旌喜樵円矂e扭用戶的真實問題從來不是純相似度是某產(chǎn)品線、我有權(quán)限、還沒過期的資料里搜這么一串。向量庫的元數(shù)據(jù)過濾又弱只能應(yīng)用層先查 MySQL 拿 id再攥著 id 列表去向量庫搜。權(quán)限范圍一大列表好幾千個性能當(dāng)場趴窩。運(yùn)維是雙份的苦。兩套庫兩套備份兩套告警。老徐半夜被告警吵醒原話是我還得先想半分鐘這次是誰家的。那天下班路上我一直在想小林那句話。三、換思路讓向量長回數(shù)據(jù)庫里3.1 一個樸素得要命的問題后來某次內(nèi)部討論小林又開口了。向量不就是表里的一列嗎憑什么不能跟別的字段住一張表、進(jìn)同一個事務(wù)會議室安靜了幾秒。這問題聽著簡單把我們整個架構(gòu)的前提給問松了。順著這個方向查資料最后落在金倉數(shù)據(jù)庫 KES 的向量能力上。思路跟小林那個問題一模一樣向量作為一種數(shù)據(jù)類型直接建在關(guān)系表里跟數(shù)值、文本、JSON、GIS、時序一塊兒活在同一個庫里。沒有搬運(yùn)這回事一條 SQL 里向量檢索和普通條件一起下。坦白講我起先犯嘀咕。專用向量庫那邊迭代得跟飛一樣數(shù)據(jù)庫內(nèi)置的向量能力會不會是個玩具親手測了兩件事才踏實。一是人家自研實現(xiàn)了 HNSW 和 IVFFlat 兩種近似索引還帶 SIMD 指令級的加速不是掃個表糊弄事。二是向量數(shù)據(jù)直接吃數(shù)據(jù)庫的 ACID 事務(wù)這個市面上不少 NoSQL 形態(tài)的向量庫給不了而對我們這種元數(shù)據(jù)改了向量必須跟著變的場景恰恰是要命的那條。3.2 新架構(gòu)長什么樣改造完我盯著看了半天有點不習(xí)慣就這么簡單原來元數(shù)據(jù)和向量分兩個庫、ETL 搬著磚、滯后還漂移現(xiàn)在一張表向量就是其中一列改完即生效。原來相似度和過濾分兩步走、應(yīng)用層拿針線縫合現(xiàn)在一條 SQL 混合檢索全下推。原來備份監(jiān)控權(quán)限配置什么都得來兩份現(xiàn)在一份。老徐的原話是晚上能睡整覺了。四、動手改造4.1 建表文檔切片表直接帶上向量列。我們的 embedding 模型輸出 768 維類型聲明里就寫 768別的不用多想CREATETABLEdoc_chunks(id BIGSERIALPRIMARYKEY,doc_idBIGINTNOTNULL,doc_titleTEXT,chunk_textTEXTNOTNULL,embedding VECTOR(768)NOTNULL,product_lineTEXT,is_activeBOOLEANDEFAULTTRUE,dept_permTEXT[],updated_at TIMESTAMPTZDEFAULTnow());多看一眼 is_active 和 dept_perm 這倆字段。停產(chǎn)標(biāo)記、部門權(quán)限原來住在另一個庫里現(xiàn)在跟向量睡同一行。產(chǎn)品停售了一條 UPDATE 把 is_active 置掉事務(wù)提交那一瞬間檢索結(jié)果里就再也見不著它了。開頭那個事故擱這個架構(gòu)下壓根沒有發(fā)生的土壤。4.2 索引選型加兩個血淚坑兩種索引我們都實測了代碼一起貼給你-- HNSW多層圖結(jié)構(gòu)召回高、查詢快就是吃內(nèi)存、建得慢CREATEINDEXidx_chunk_hnswONdoc_chunksUSINGhnsw(embedding vector_cosine_ops);-- IVFFlat先聚類再倒排省內(nèi)存、建得快拿 probes 調(diào)精度CREATEINDEXidx_chunk_ivfONdoc_chunksUSINGivfflat(embedding vector_cosine_ops);最后定的 HNSW。語料百萬級內(nèi)存扛得住而客服場景對召回率敏感漏一條關(guān)鍵維修案例可比慢十毫秒嚴(yán)重多了。你要是向量上億、內(nèi)存又緊那 IVFFlat 值得先試。補(bǔ)一句這兒的索引在數(shù)據(jù)插入更新時是實時維護(hù)的不存在建完索引就不讓改數(shù)據(jù)那種憋屈事?？硬攘藗z。第一個IVFFlat 千萬別在空表上建。它先對全量數(shù)據(jù)聚類再分桶空表建出來的分桶全是錯的召回慘到?jīng)]法看。我們當(dāng)時還以為是版本 bug排了一晚上最后發(fā)現(xiàn)是自己用法不對。先灌數(shù)后建索引順序別反。第二個更隱蔽。用余弦距離的話向量入庫前要?dú)w一化不然模長會摻進(jìn)距離里搗亂排序結(jié)果莫名其妙地不對。我們有一陣子檢索質(zhì)量忽好忽壞查了好幾天才定位到這兒說起來都是淚。4.3 檢索就一條 SQL改造后最爽的部分。用戶提問的完整檢索就這一條-- q_vec 是應(yīng)用側(cè)把用戶問題向量化后傳進(jìn)來的參數(shù)SELECTdoc_title,chunk_text,embeddingq_vecASdistanceFROMdoc_chunksWHEREis_activeTRUEANDproduct_line工業(yè)控制器ANDdept_perm ARRAY[after_sales]ORDERBYembeddingq_vecLIMIT5;看看 WHERE 里混了些什么。有效性產(chǎn)品線數(shù)組權(quán)限判斷再搭上 算的余弦距離排序。原來那個先查 id 列表再傳給向量庫的兩段式整個被壓進(jìn)數(shù)據(jù)庫一次執(zhí)行。權(quán)限列表幾千條也不虛了過濾條件下推掃描范圍先砍一大截。我觀察下來這是融合架構(gòu)最被低估的地方。大家盯著向量檢索性能比來比去很少有人算省掉的那條同步鏈路值多少錢。4.4 意外收獲順手的驚喜值得一小節(jié)。向量類型支持加減、數(shù)乘、拼接還帶 AVG、SUM 這類聚合。我拿它算過全部語料向量的均值專門撈離群的切片-- 找跟語料中心離得最遠(yuǎn)的切片多半是切壞了的或者內(nèi)容異常的WITHcenterAS(SELECTAVG(embedding)AScFROMdoc_chunks)SELECTid,doc_title,embeddingcASdistanceFROMdoc_chunks,centerORDERBYdistanceDESCLIMIT20;跑出來一瞧果然一堆切稀碎的表格和亂碼 PDF。以前這種活兒得導(dǎo)出去寫 Python 腳本現(xiàn)在 SQL 一條。五、跑了三個月的賬說幾個拿得出手的數(shù)。檢索鏈路里徹底沒有 ETL 這號角色了數(shù)據(jù)新鮮度從最多滯后十分鐘變成事務(wù)級?；旌蠙z索的 P95 從 180ms 掉到 40ms 上下大頭是省了兩段式那個應(yīng)用層往返。運(yùn)維對象兩套變一套老徐的告警群肉眼可見地清凈了。至于停產(chǎn)產(chǎn)品當(dāng)現(xiàn)貨賣這類事故架構(gòu)上沒有它發(fā)生的土壤了。代價也得老實交代。單一庫資源共享高峰期向量檢索和普通業(yè)務(wù)查詢會搶 CPU。我們靠資源隔離配置壓了壓不算完美但跟伺候同步鏈路比省心太多。六、寫在最后這回改造給我最大的觸動是AI 應(yīng)用的架構(gòu)難題好多時候不在模型身上在數(shù)據(jù)怎么組織。向量數(shù)據(jù)庫這個詞聽著像要開新世界扒開看向量就是一種數(shù)據(jù)形態(tài)嘛它在關(guān)系庫里完全能活得好好的還順手把事務(wù)、權(quán)限、混合查詢這些老手藝全帶過來了。一套數(shù)據(jù)庫解決所有問題這話說得太滿我不學(xué)。但對中等規(guī)模的 AI 應(yīng)用我的建議就一句先別急著上第三套存儲看看手頭的庫能不能把向量裝下多半能省出一條同步鏈路外加好幾個不眠之夜。下一步打算把工單的時序數(shù)據(jù)也并進(jìn)來讓檢索結(jié)果帶上這故障最近是不是高發(fā)的判斷。庫就在那兒一張表的事兒。老徐說了這回他等著看。