做RAG方案選型的朋友大概率都遇到過這種尷尬技術方案匯報PPT翻了一堆github上star數對比拉了好幾輪真正上線時卻發(fā)現demo里跑得飛起的問答系統(tǒng)落到自己業(yè)務數據上就各種答非所問。前陣子我在復盤一個企業(yè)知識庫項目時把dsh-knowledge和市面上主流的三類RAG方案放在同一套維度下做了次細致的橫向對比收獲很大。這篇就聊聊這套對比框架以及我踩過的坑——如果你正在糾結到底選哪條路做知識庫這篇應該能幫你省下幾周的研究時間。先說清楚這文章解決什么問題面對純向量檢索RAG、知識圖譜增強RAGKG-RAG、結構化知識庫/Ontology RAG這三條常見路線外加dsh-knowledge這類偏工程落地的知識庫方案怎么用同一套維度把它們擺在桌面上比適合誰看主要是兩類人一類是正在做技術選型的技術負責人、架構師另一類是剛接觸RAG、被各種概念繞暈的算法工程師或后端開發(fā)。1. 為什么RAG選型這么難先搞清楚3個被忽視的前提1.1 「RAG」這個詞已經被用濫了這兩年聊RAG大家默認說的是向量檢索 大模型生成的組合拳。但真正落過地的人都知道這只是最基礎的一種形態(tài)。RAG的全稱是Retrieval-Augmented Generation核心思想是先檢索、后生成但檢索什么、怎么檢索、檢索結果怎么組織才是決定方案能不能用的關鍵。我在實際項目里見過太多這樣的情況業(yè)務方提需求時說的是我們要做一個RAG知識庫結果真的做進去才發(fā)現他們要的是能把幾十個業(yè)務系統(tǒng)的數據統(tǒng)一管理起來、能回答跨系統(tǒng)的問題、老板問的指標能答得上來的系統(tǒng)。這已經不是單純的向量檢索能覆蓋的了而是涉及數據建模、知識組織、多路召回的綜合工程。所以選型的第一步不是比較各家方案的準確率有多高而是先確認你要解決的到底是讓大模型多一個外部記憶的問題還是讓組織內部的知識能被系統(tǒng)化使用的問題。這兩者差很遠。1.2 三類RAG的本質區(qū)別查得快、查得準、查得懂我把市面上常見的RAG方案歸成三類方便對照第一類是純向量檢索RAG。就是經典的文檔切塊—向量化—存向量庫—相似度檢索四步走。代表作就是LangChain里那個最樸素的RetrievalQA鏈配上FAISS、Milvus、Chroma這類向量庫。這類方案的優(yōu)勢是上手極快適合給大模型配一個外部資料庫的場景比如把產品手冊喂進去回答XX功能怎么用這種問題。第二類是知識圖譜增強RAG也叫KG-RAG。在向量檢索的基礎上增加了一層實體關系網絡。先做實體識別和關系抽取把散落的文檔信息沉淀成節(jié)點—邊結構檢索時既做向量召回也做圖譜路徑查找。代表形式是GraphRAG、微軟開源的GraphRAG框架以及各種結合Neo4j的實現。這類方案的長處在于多跳推理比如A部門和B部門哪個季度成本更高單看某一篇文檔是找不到現成答案的但圖譜里能沿著關系路徑一路推理出來。第三類是結構化知識庫/Ontology RAG。這類方案強調先建模、后入庫通過本體ontology、Schema或信息架構把知識組織成有嚴格層級、有屬性約束、有關系類型約束的結構化形式再在檢索時利用這些結構信息做精確匹配或約束推理。它比知識圖譜更重建模成本更高但查詢可控性最強適合監(jiān)管、醫(yī)療、金融這種對答案準確性要求極高的場景。這三類方案不是簡單的優(yōu)劣關系而是定位不同第一類主打快第二類主打全第三類主打準。1.3 dsh-knowledge 在方案光譜中的位置那么dsh-knowledge卡在哪個位置從我接觸到的信息和實際體驗來看它更像一個面向知識庫應用落地的整體方案而不是單一的檢索算法。它做的事是把知識獲取、知識表示、知識存儲和問答應用串起來既不是那種裸的向量檢索流水線也不會一上來就要求你交出一張完整的知識圖譜。換句話說它走的是中間路線用結構化的思路組織知識但保留了落地時的靈活性。這個定位其實挺討巧的因為它解決了很多團隊知道知識圖譜好但根本建不起來的現實難題。后面我會專門用一章講它的差異化這里先把它作為對比中的一個錨點——我們最終要看的是它和另外三類方案在同樣的維度上各自的得分是多少。提示選型最忌諱的是拿著A方案的長處去比B方案的短處。下面這套五維對照框架就是為了保證大家在同一套尺子上量東西。2. 五維對照框架拿同一把尺子量不同方案2.1 維度一數據建模能力——你能多忠實地表達業(yè)務世界數據建模能力是選型的第一道分水嶺。純向量RAG在這一維上基本沒有建模——文檔切成chunk就是它的全部世界一個chunk本質上就是一段無結構的文本語義靠向量隱含表達你沒法在系統(tǒng)里回答這個chunk里面的價格字段指什么。這種隱式表達對上簡單問答還行遇到需要精確引用某個字段、某個指標的業(yè)務就很吃力。知識圖譜增強RAG的建模能力明顯上了一個臺階。它有實體、關系、屬性三件套能把張三在A部門任職A部門屬于BG1事業(yè)群這種事實顯式表達出來。但值得注意的是傳統(tǒng)知識圖譜的建模偏關系抽出來就行約束和校驗都比較弱。結構化知識庫/Ontology RAG在建模上是最重的。它要求你在數據進來之前就想清楚業(yè)務里有哪幾類核心對象對象之間有哪些關系每個關系的定義域、值域是什么有沒有繼承、組合這類結構這種建模方式前期投入很大但一旦模型穩(wěn)定后續(xù)的查詢質量和可維護性都遠超前兩類。dsh-knowledge在這個維度上的做法從我觀察到的工程實踐來看是提供了一套介于無Schema和強Schema之間的知識組織方式它允許你定義知識的結構但不強制你把所有知識都嚴格映射到一個全局本體上。這對很多數據本身參差不齊的企業(yè)場景來說非常實用。2.2 維度二檢索質量與召回邏輯——不同問題類型下的表現第二個維度是硬碰硬的核心檢索質量。但必須注意質量不是一個籠統(tǒng)的詞要拆成不同問題類型來看。對于事實型問答比如XX產品的退換貨政策是什么純向量RAG通常夠用把政策文檔切成合理大小的chunkTop-K召回后讓大模型總結基本能答得八九不離十。它的短板在多跳推理型問答比如上個季度華東區(qū)的退貨率環(huán)比變化了多少這個答案分散在銷售表、區(qū)域報告、時間序列三個不同的文檔里向量檢索在召回階段就很難一次把三塊信息同時撈出來。KG-RAG在多跳推理上就很有優(yōu)勢。因為它保存了華東區(qū)—屬于—銷售區(qū)域、退貨率—統(tǒng)計于—季度報告這類關系檢索時可以像查地圖一樣走關系鏈路而不是純粹靠語義相似度去猜。結構化知識庫/Ontology RAG在精確匹配型問答上最強。比如查詢ICD-10編碼E11.9對應的疾病名稱這本質上就是一次精確檢索或約束查詢向量相似度的思路反而繞了遠路。它在這種場景下的準確率是接近100%的因為答案是建模時就已經確定好的事實。dsh-knowledge的檢索邏輯更接近混合檢索既做向量召回也利用知識組織結構做路徑過濾和約束。實際測試中它在事實型問題上的表現不輸純向量方案在多跳型問題上比純向量方案有明顯提升而建造成本又比搭一整套知識圖譜低很多。2.3 維度三維護成本與更新時效——很現實的一關這一維度最容易被新手上手階段忽略但上線三個月后它就會回來找你的麻煩。純向量RAG的維護成本最低更新也最直觀新增文檔切塊向量化插入向量庫刪除文檔按ID刪向量就行。但它的隱患也在這——它沒有知識版本的概念同一份數據如果被反復導入向量庫里會堆出大量重復或沖突的chunk召回時經常出現新信息和舊信息打架的情況。知識圖譜增強RAG的維護就麻煩多了。實體識別、關系抽取的準確性直接決定圖譜質量而后者是需要有人持續(xù)review的。圖譜里一旦出現錯誤關系比如把A部門和B部門合作抽成了B部門屬于A部門這種錯誤會在檢索時被悄悄放大而且極難發(fā)現。說實話沒配專門的圖譜運維角色KG-RAG上線半年后基本會變成一件看著很專業(yè)但沒人敢信的擺設。結構化知識庫/Ontology方案的維護成本是前高后平建模階段投入大得讓人想放棄但一旦Schema穩(wěn)定了日常的增刪改反而非?？煽匾驗橐磺卸加幸?guī)約自動校驗可以擋掉大部分低級錯誤。它最大的問題是變更Schema的成本——業(yè)務一變模型一改連帶數據遷移和檢索邏輯全要跟著動。dsh-knowledge的做法是盡量把知識維護這個動作收攏成一個個標準化流程比如支持從表格、文檔等常見載體半自動導入知識并保留結構校驗環(huán)節(jié)。這樣一來維護工作被分布到日常運營中而不是堆積成周期性的大型治理項目。2.4 維度四擴展性與團隊門檻——技術棧和人的匹配度擴展性有兩個方向一個是數據規(guī)模變大系統(tǒng)能不能撐住另一個是業(yè)務范圍變廣方案能不能順滑地覆蓋新場景。純向量RAG的擴展性最好解釋數據量大就加節(jié)點向量庫的分布式方案已經很成熟了而且它對團隊的技能要求最低一個會Python、用過LangChain的工程師就能跑通全流程。這也是它成為入門首選的原因。KG-RAG的擴展性說句公道話圖譜本身是可以無限擴展的但它的瓶頸在于知識抽取—入庫這條管線的吞吐量。你可以在架構上擴展數據庫節(jié)點但實體識別的準確率會隨著領域變化而下降每進入一個新領域往往就要調一輪抽取模型。團隊門檻明顯升高——既要有人懂NLP還要有人懂圖數據庫建模。結構化/Ontology方案的可擴展性取決于你愿不愿意為新場景擴展Schema。數據量擴展沒問題但每新增一類業(yè)務對象都要經過建模評審—Schema變更—數據遷移—檢索邏輯適配這一串流程。團隊里至少要有一個懂領域本體建模的人這個角色非常稀缺。dsh-knowledge在這方面的優(yōu)勢我覺得是它把知識結構和技術組件做了適度解耦團隊只需維護知識結構本身技術上依賴的向量庫、檢索服務都可以做成通用組件。對10-30人的小團隊來說這個門檻是比較友好的。2.5 維度五應用場景適配度——技術最終要長在業(yè)務里最后一個維度其實是檢驗方案和業(yè)務到底配不配。純向量RAG適合的場景知識變化頻繁但內容相對松散的場景比如產品幫助中心、企業(yè)內部制度文檔問答、客服知識庫。這類問題的特點是答案就在某一段文檔里不需要復雜的推理。KG-RAG適合的場景需要跨文檔聚合、關系分析、輔助決策支持的場景比如供應鏈風險分析、科研文獻綜述、內部情報分析。它能在你不知道該搜什么的時候順著關系把潛在答案找出來。結構化/Ontology RAG適合的場景強監(jiān)管、強流程、答案必須可解釋的行業(yè)場景。比如醫(yī)療診斷輔助ICD編碼、藥品說明書查詢、金融監(jiān)管報送規(guī)則問答、法律條款精確定位。這些場景問的是標準答案不是參考信息。dsh-knowledge因為走中間路線適用面反而更寬它既能在客服知識庫這種場景里替代純向量方案也能在企業(yè)經營分析問答中覆蓋部分多跳場景適合那種業(yè)務雖然有邊界但知識形態(tài)比較雜的組織。為了便于直觀對比我把五維度的觀感匯總成一張表基于常見實踐和公開資料整理供參考對比維度純向量RAG知識圖譜增強RAG結構化/Ontology RAGdsh-knowledge中間路線數據建模能力弱無顯式結構中有實體關系強嚴格Schema中強輕量結構可配多跳推理能力弱強中強依賴查詢設計中強精確匹配能力弱中強中強維護成本低高前高后平中等上手門檻低高極高中低典型時延適合開放問答適合關系分析適合精準確認適合混合場景3. 三類 RAG 方案的實戰(zhàn)細節(jié)拆解3.1 純向量RAG快但別對它期待太多這里直接給一段我常用的最小實現代碼雖然網上到處都是但如果你第一次上手照著這個跑通對純向量RAG到底做了什么會有體感。from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import FAISS # 加載文檔 loader TextLoader(product_manual.txt) documents loader.load() # 切塊這里我習慣先按章節(jié)再按長度避免切斷語義 text_splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap100, separators[\n\n, \n, 。, , , , ], ) chunks text_splitter.split_documents(documents) # 向量化并入庫 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore FAISS.from_documents(chunks, embeddings) # 檢索 retriever vectorstore.as_retriever(search_kwargs{k: 4})這段代碼背后的幾個參數值得琢磨一下。chunk_size選800是經驗值太短會切碎語義太長會導致向量混淆800字對中文來說信息密度適中。chunk_overlap選100是為了避免剛好處于切邊界的句子被丟掉語義羽翼。separators的順序也很講究我是按語義完整度從高到低排的。這些都是純向量方案的手藝活性能上限也基本被卡在這幾個參數里。但這個方案有個通病——檢索是盲人摸象。它只看你這個問題和哪個chunk的字面/語義接近看不到chunk之間的關系。我踩過的最典型的一個坑是把一份年度運營報告切成50個chunk后問今年整體表現如何Top-K召回了4個chunk全是細碎的數據描述沒有一個chunk里有整體表現這個結論性陳述。最后大模型只能靠這4塊碎片硬編一個答案出來。這就是很多人覺得RAG效果不行的真相——不是大模型的問題是召回本身就沒召回到關鍵信息。3.2 知識圖譜增強RAG能推理但圖本身要有人養(yǎng)KG-RAG的落地套路大致是三步實體識別、關系抽取、圖存儲。實體識別我會用GLiNER這類輕量模型做zero-shot抽取比傳統(tǒng)的命名實體識別NER工具泛化性要好一些不用為每個新領域重新訓練。關系抽取則要結合業(yè)務預設的關系類型別指望它能自己學習出所有關系。存儲層面用Neo4j的Cypher查詢比較典型。這里給一個簡單的原型代碼思路from neo4j import GraphDatabase driver GraphDatabase.driver(bolt://localhost:7687, auth(neo4j, password)) def extract_entities_and_relations(text): # 用GLiNER抽取實體用小型關系分類器抽取關系 # 實際返回: [(頭實體, 關系, 尾實體), ...] pass def build_graph(records): with driver.session() as session: for record in records: for subj, rel, obj in record: session.run( MERGE (a:Entity {name: $subj}) MERGE (b:Entity {name: $obj}) MERGE (a)-[r:REL {type: $rel}]-(b), subjsubj, relrel, objobj )這段代碼里最需要注意的就是MERGE的用法。它就是圖數據庫里的有則找到無則創(chuàng)建避免重復插入。實際項目中真正復雜的是關系抽取的質量控制比如公司的營收增長了20%這句話到底該抽成公司, 增長指標, 20%還是公司, 年度營收, 增長20%需要非常清晰的schema設計才能保證一致性。我在項目里測試過GraphRAG微軟開源的長文檔問答效果確實驚艷——它會把文章里的實體關系聚類成社區(qū)結構回答問題時會以社區(qū)為單位做檢索多跳能力很強。但對應的代價是索引構建時間極長長文本圖譜抽取對token消耗巨大而且抽取質量在小語種或強專業(yè)領域里會明顯下滑。這些成本如果不提前算清楚上線很可能會翻車。3.3 結構化知識庫 / Ontology RAG精確但建模要命Ontology這個詞把很多初學者嚇到了但它的本質就是用一套明確的規(guī)則描述世界——定義概念、定義屬性、定義關系然后在這個框架里放數據。在落地時沒必要用數學意義上的完備ontology只要有一個符合業(yè)務實際的Schema就夠了。很多團隊直接用關系數據庫或者圖數據庫承載這個結構反而更輕。拿一個企業(yè)財務問答場景來舉例假如要回答研發(fā)部門的Q3差旅費是多少。先定義一個簡單Schema類部門Department、費用項目ExpenseItem屬性部門的名稱、預算費用項目的金額、季度、報銷人關系部門—產生—費用項目然后數據錄入時每條報銷記錄就按這個結構落到庫里。查詢時直接檢索部門.name研發(fā)部 AND 費用項目.類型差旅費 AND 費用項目.季度Q3就行了。這種查詢準確率幾乎100%但前提是你把所有報銷記錄都按這個結構整理入庫了——這就是代價。這個方案里最重磅的誘惑是結合大模型做Text-to-SQL或Text-to-Cypher。你可以直接讓大模型把自然語言翻譯成結構查詢再由數據庫嚴格返回結果。但這里有個大坑大模型翻譯出的查詢語句經常有疏漏比如漏了時間條件或部門限定一旦你沒做查詢結果的邏輯校驗錯誤答案就靜悄悄地出來了。我的做法是給NL2SQL加了一層查詢模板校驗先讓模型選查詢模板再讓模型填參數這樣出錯率會下降很多。4. dsh-knowledge 核心能力與差異化分析4.1 它到底解決了什么痛點聊完三類方案的邊界再看dsh-knowledge就清晰多了。說白了它的核心價值是解決了純向量方案不夠準知識圖譜方案建不起這個中間帶問題。我把它理解為一套知識工程檢索增強的落地工具集它鼓勵用戶先定義領域知識的骨架即所謂的知識維再自動把散落的文檔內容掛到這個骨架上。這個骨架不需要像Ontology那么嚴格但能提供足夠的結構化信息讓檢索階段可以沿著骨架做約束和過濾。實際效果上我測試中比較突出的一點是它把多實體、多屬性、多關系的數據同時塞進知識庫時不會像純向量方案那樣出現信息之間互相干擾的情況。比如一份文檔里同時提到價格和成本兩個概念純向量檢索時它們語義相近經常發(fā)生串擾但在dsh-knowledge的結構化組織下這兩個概念會被顯式區(qū)分問答時系統(tǒng)知道你要問的是哪個維度。4.2 與其他方案的邊界不是替代是補位選型最怕什么都想要。dsh-knowledge不是用來替代純向量RAG的當你的場景只需要翻文檔找答案用純向量方案就夠了完全沒必要引入額外結構它也不是用來替代KG-RAG的如果你的場景需要從海量實體關系中挖掘未知模式KG-RAG的專業(yè)深度它比不了。它適合的是那種有一定結構但還沒有強到能定義出完整本體的中間態(tài)。我接觸過不少企業(yè)的知識庫項目都卡在這個階段數據源很多產品文檔、FAQ、工單、制度文件格式參差不齊但要完全手工建本體的話業(yè)務人員不配合、數據量又太大。dsh-knowledge這樣的方案在這類場景里優(yōu)勢明顯——它不逼你先交一份完美的ontology再開工而是讓你邊導入數據邊沉淀結構。這么說吧選型時可以把它當做一個結構化增強的RAG底座看待你既能用它做語義問答又能用它的結構信息做過濾、推薦和統(tǒng)計。4.3 目標團隊畫像誰用起來最順手從落地角度我總結了三類適合引入dsh-knowledge的團隊畫像你可以對號入座第一類是業(yè)務有一定復雜度、但技術人力有限的中型團隊。團隊人數在10-50人之間有1-2個懂NLP或搜索的工程師但養(yǎng)不起一個專門的圖譜團隊。做知識庫是為了提升內部效率不是為了學術創(chuàng)新。第二類是數據很亂但業(yè)務邊界清晰的行業(yè)團隊。比如做設備運維的公司手里的數據有設備手冊、維修工單、配件清單、故障案例格式千奇百怪但行業(yè)對象設備、故障代碼、維修動作是有限的。這類場景用純向量方案太浪費用知識圖譜又太重正好落在中間帶。第三類是已經在用純向量RAG、但上線后被準確率困擾的團隊。這類團隊最典型的表現是Demo跑得很好生產環(huán)境被業(yè)務部門吐槽答案太散、不敢用。與其推翻重來換一套方案不如在現有基礎上引入結構化知識層把關鍵業(yè)務知識結構化后再參與檢索效果提升通常非常明顯。5. 選型決策流程與避坑清單5.1 五步走把模糊需求落成明確選項我自己的選型流程會堅持走完下面五步哪怕時間緊也至少走前三步第一步列出所有真實查詢場景并給每個場景打標。比如產品FAQ問答是事實型競品參數對比是多跳型計算某區(qū)域季度成本是精確計算型。這一步的本質是把業(yè)務需求翻譯成檢索需求。第二步按問題類型統(tǒng)計分布。如果80%以上都是事實型優(yōu)先考慮純向量方案夠用就好如果大量是多跳推理就得考慮KG-RAG或dsh-knowledge這類帶結構的方案如果涉及精確查詢和強約束結構化方案是必選項。第三步估算維護成本尤其是人力成本。這一步我吃過虧。之前有個項目因為團隊里沒有圖譜運維經驗的人KG-RAG上線三個月就出現知識錯亂最后只能打折用。所以選型時不僅要看有沒有能力建還要看長期有沒有人養(yǎng)。第四步小規(guī)模并行驗證。不要信PPT對比直接拿你們最核心的30-50個真實問題在兩個候選方案上各跑一遍統(tǒng)計準確率和拒答率。這里有個技巧好的方案應該知道什么時候該說不知道而不是亂答一氣。我把這個拒答率當作評估指標能過濾掉很多華而不實的方案。第五步算全成本。包含硬件成本GPU/向量庫節(jié)點、開發(fā)成本管線建設和調優(yōu)、維護成本知識更新、錯誤訂正、以及最容易被忽略的知識初始建設成本——把現有資料變成可檢索結構花的那些人力工時。這一步往往是最后決策的勝負手。5.2 常見錯誤認知三句話句句都有人踩我在社區(qū)和技術交流里反復見到幾個誤區(qū)這里統(tǒng)一說下。第一句是RAG一定比微調好。這得分場景。如果你的知識是高度動態(tài)的比如每天有新的政策文件RAG確實有優(yōu)勢但如果你有一批穩(wěn)定、結構化的知識比如公司財務制度把它微調進模型里反而更省事檢索都不用做。第二句是知識圖譜一定比向量檢索高級。技術沒有高級低級只有合適不合適。很多團隊花兩個月建出來的圖譜準確率還不如簡單切塊向量檢索高原因就是關系抽取質量太差、圖譜里全是噪音?？粗呒壍珱]用是比看著樸素但能用更嚴重的浪費。第三句是Ontology一定適合企業(yè)知識庫。Ontology適合的是答案有唯一標準的場景而很多企業(yè)知識庫恰恰是開放式、探索式的這個方案歷史上失敗過沒有這種問題就沒有唯一答案硬套Ontology只會既貴又別扭。5.3 落地階段的三個實操提醒技術選型最終要落實到工程里這里分享三個特別容易踩的落地細節(jié)。第一個是知識更新要走先校驗、后入庫的流程。無論用哪種方案別讓業(yè)務方直接往庫里灌數據。我見過太多垃圾進、垃圾出的知識庫項目其實就是少了校驗環(huán)節(jié)。哪怕只做一個簡單的去重、格式檢查、必填字段校驗都能省掉后面大量排錯的時間。第二是給檢索結果設計可解釋性接口。用戶問為什么給這個答案系統(tǒng)至少能回答根據文檔A和文檔B。這一點在結構化方案里尤其重要因為結構化查詢的命中原因比向量相似度更容易解釋。別小看這一點它是業(yè)務方信任知識庫的關鍵。第三是做好知識冷啟動的預期管理。任何RAG項目上線第一天效果都不會完美。有的團隊期望第一天就達到90%準確率結果只做到70%就把它否了。正確做法是上線時定一個可接受基準比如先做到60-70%然后通過持續(xù)補充知識、修正錯誤把準確率滾到85%以上。知識庫是越用越準的不是一次建好的。我個人在實際操作里最深的體會是RAG選型本質上不是技術選型而是業(yè)務建模選型。你選了純向量等于默認不建模全靠語義選了知識圖譜等于認下了復雜建模持續(xù)運維的代價選了dsh-knowledge這類中間路線等于走了一條性價比優(yōu)先的路——不求每個指標最牛但求在大多數場景下都夠用、可維護、能落地。最后再分享一個小技巧無論最后選了哪條路都別把方案焊死在一個供應商身上。把知識結構和檢索實現解耦開數據模型是數據模型向量庫/圖數據庫是組件這樣未來遷移和升級都不至于重來一遍。這個架構潔癖會在半年后狠狠回報你。