如果你做 LLM 應用的時間超過三個月大概率已經對 RAG 的“分裂感”有切身體會了。查資料像隔靴搔癢明明文檔里寫了檢索就是召不回多輪對話聊著聊著就開始“失憶”Agent 在復雜任務里反復橫跳。傳統(tǒng) RAG 的底層假設是把知識切碎、向量化、然后按相似度撈回碎片但真實業(yè)務里的上下文是有結構的、有層級、有依賴關系的。這也是 OpenViking 這類“文件系統(tǒng)級”上下文數據庫出現的原因它把 AI Agent 的上下文當作一套有路徑、有目錄、有繼承關系的文件系統(tǒng)來管理而不是一堆孤立的向量碎片。這篇文章我會從傳統(tǒng) RAG 的斷層開始聊拆解 OpenViking 的核心設計再給出可以直接上手的實操路徑以及我在實際場景里踩過的坑。1. 傳統(tǒng) RAG 的幾個硬傷為什么“檢索增強”不夠用了1.1 向量檢索的相似度陷阱先說說最要命的一個問題向量檢索本質上是在做“語義模糊匹配”它對“形似”敏感對“神似”無力。你用 embedding 模型把文本變成一串向量再用余弦相似度去撈 Top-K結果往往是召回一堆“看起來像”但不真正解決問題的內容。比如你在企業(yè)知識庫里存了一份《客戶投訴處理流程》里面有明確的分級規(guī)則、響應時限、責任部門。傳統(tǒng) RAG 的做法是把這份文檔切成幾百個 chunk每個 chunk 單獨向量化。用戶問“投訴超過三天沒回復怎么辦”向量檢索可能召回到“回復時限是三個工作日”這個片段但沒法把“超過時限后的升級路徑”和“責任人矩陣”這兩部分關聯起來因為這兩段文本在字面上并不相似只是在業(yè)務邏輯上高度相關。這個問題的根子在于RAG 的檢索單位是“文本塊”但業(yè)務知識的單位是“邏輯實體”。文本塊之間只有向量距離沒有結構關系。你可以在提示詞里拼命調 prompt 讓它“多讀幾遍”但檢索器本身沒有跨塊關聯能力這也是很多團隊調 RAG 精度調到 70% 就再也上不去的核心原因。1.2 上下文碎片化Agent 多輪交互時的失憶癥狀另一個痛點是 Agent 場景下的上下文連續(xù)性。傳統(tǒng) RAG 是“每次獨立檢索”它沒有持續(xù)的“狀態(tài)記憶”。用戶問問題 AAgent 檢索資料回答用戶追問問題 BAgent 再次重新檢索。如果 B 依賴 A 的結論而 A 的結論分散在多個 chunk 里Agent 就得靠 prompt 里的聊天歷史來回溯。這個方案在短對話里沒有問題但一旦任務復雜度上升——比如讓 Agent 幫你“整理一份包含市場分析、競品對比、推薦策略的季度報告”——你需要把幾十份文檔的知識串聯成一個連貫的知識體系而不是一次一次地去撈碎片。碎片化的上下文讓 Agent 喪失“全局視野”每個檢索結果都是局部信息而生成需要的是結構化的整體認知。我在實踐中見過最典型的情況一個 Agent 在生成報告結論時因為無法感知到“市場數據”“競品優(yōu)勢”“客戶反饋”這三個模塊之間的邏輯關聯最終產出了一份前后矛盾的內容。這不是模型能力不夠而是知識組織方式從一開始就選錯了。1.3 對結構化知識的支持太弱第三種問題是純結構化知識的表達。傳統(tǒng) RAG 處理表格、JSON、YAML 這類數據時表現很差——你切碎表格等于拆掉表頭和單元格的關系你把 JSON 轉成文本等于把鍵值對的關聯結構壓扁成字符串。如果知識庫里存著大量配置項、參數表、操作手冊RAG 很容易把“不該合并的合并不該斷開的斷開”檢索回來的結果看得人一頭霧水。而現實業(yè)務里知識通常不是純文檔而是文檔表格代碼配置的混合體。企業(yè)知識庫尤其如此。沒有結構化的存儲和檢索你只能在應用層自己做很多臟活手寫解析器、維護 chunk 與實體的映射、在檢索后做二次過濾。這些工作不僅繁瑣而且容易出錯。注意并不是說傳統(tǒng) RAG 一無是處。在問答場景里單輪、事實型、答案集中在一小段文本里的任務傳統(tǒng) RAG 依然高效。但如果你要做 Agent 級別的復雜任務只靠“切塊向量”這個套路天花板非常明顯。2. OpenViking 的思路把上下文當成文件系統(tǒng)來建庫2.1 “文件系統(tǒng)級”到底是什么意思OpenViking 的核心概念很直接它不再把上下文看成“一堆文本塊的集合”而是把它組織成“一棵有路徑的樹”。這棵樹的每一層代表一個語義層級每個節(jié)點可以掛載內容、屬性、子節(jié)點節(jié)點之間有明確的父子關系。你可以把它理解為用文件系統(tǒng)的思維來組織 AI 的知識結構。這個思路來自操作系統(tǒng)設計?！奥窂健笔翘烊坏男畔⒍ㄎ环绞?reports/2025/Q1/market-analysis這個路徑本身就攜帶了語義——“這是一份 2025 年第一季度市場分析報告”。路徑的層級關系也自然地表達了事物之間的歸屬和依賴“市場分析”和“競品分析”都屬于“季度報告”而季度報告又歸屬于年份目錄。你可以把傳統(tǒng) RAG 比作“在倉庫里隨便堆箱子靠紙條上的模糊描述找貨”O(jiān)penViking 則是“給每件貨安排固定的貨架號用目錄索引直接定位再輔助語義搜索”。兩者的信息密度和信息組織效率完全不在一個量級上。2.2 路徑即語義層級結構天然表達關聯路徑的好處在于它把“語義關系”從隱式變成顯式。兩個節(jié)點如果在同一個父路徑下它們天然相關如果它們的路徑前綴相同它們共享同一套歷史上下文。這種關聯不需要模型推理路徑本身就給出了答案。舉個例子一個公司內部知識系統(tǒng)里你可以建立這樣的路徑樹/company /handbook /onboarding /hr-policy /product /specs /roadmap /release-notes /operations /playbooks /runbooks /incident-reports當 Agent 要回答“公司對新員工的差旅報銷有什么規(guī)定”時路徑導航可以直接鎖定/company/handbook/onboarding和/company/handbook/hr-policy不需要在幾千個 chunk 里做全局相似度匹配。而當用戶追問“那產品發(fā)布流程呢”路徑會切換到/company/product/release-notes整個上下文空間更新得干凈利落。這種層級結構還有一個巨大的好處繼承。子節(jié)點天然繼承父節(jié)點的屬性和約束。比如你在/company/handbook這個層級定義了一個屬性permissioninternal那么它下面的所有子節(jié)點自動獲得這個權限標簽不用每個節(jié)點重復標注。這在權限控制、租戶隔離、多客戶場景中非常實用。2.3 上下文包Context Bundle的設計OpenViking 提出了一個很關鍵的概念叫“上下文包”。一個上下文包是一個自包含的知識單元它由一個路徑節(jié)點、節(jié)點內容、關聯的子節(jié)點、元數據組成。你可以把它想象成一個文件夾文件夾的本身也允許有說明文件、標簽、索引而不僅僅是裝文件的容器。上下文包的設計讓“上下文”從被動檢索對象變成了主動管理對象。你可以在應用層直接對上下文包做增刪改查可以在包里掛載外部引用可以給包打標簽、設定版本、設置過期時間。這種設計思路明顯區(qū)別于傳統(tǒng) RAG——傳統(tǒng) RAG 里你無法“管理”chunk你只能“重新索引”它。比如我在做一個客服知識庫的 Agent 時會把每個產品線的常見問題、升級流程、故障定位手冊分別建為獨立上下文包包之間通過父路徑共享“品牌風格”和“回復規(guī)范”。當 Agent 需要生成答復時它不僅僅檢索文本還能感知到自己在哪條目錄分支上從而自動匹配對應的語氣和策略。這是傳統(tǒng) RAG 很難做到的事情。注意OpenViking 的關鍵不在“數據庫技術”本身而在于它把知識組織重新聚焦到了結構上。結構是語義的骨架文本是血肉。先有骨架再填充血肉檢索和生成的效率都會大幅提升。3. 核心機制拆解從寫入到檢索的全流程3.1 寫入階段結構化切分與元數據抽取OpenViking 的寫入過程比傳統(tǒng) RAG 多一步“結構化解析”。你不僅要切分文本還要識別文本的語義歸屬路徑抽出元數據。這一步是決定后面檢索質量的關鍵。實際操作中寫入一個上下文包需要三個步驟定義路徑確定這個文檔/內容掛載到哪個路徑下。內容切塊按邏輯標題、段落、表格邊界切分內容塊。元數據提取為每個塊生成標簽、屬性、依賴關系、版本信息。在編碼層面寫入接口通常是這樣的from openviking import ContextLibrary library ContextLibrary() ctx library.create( path/company/product/specs/model-x, titleModel X 完整規(guī)格說明, content...原始文檔內容..., metadata{ version: 2.1, owner: product-team, tags: [specs, model-x], updated_at: 2025-06-18 } ) # 自動解析 content 中的結構化部分如表格、代碼塊 ctx.parse_structure() ctx.commit()在“結構化切分”這一步OpenViking 會自動識別 markdown 標題層級、HTML 標簽、表格結構、JSON 字段等把它們轉成路徑樹內的子節(jié)點。比如一個 markdown 文檔里有二級標題## 網絡配置它會自動變成/company/product/specs/model-x/network-config這樣一個子路徑節(jié)點。這比傳統(tǒng) RAG 的“固定長度窗口切分”要聰明得多。長度切分是物理切分它不管內容的邏輯邊界而結構切分是語義切分它精確地遵循內容的組織方式。代價是解析器需要寫得更復雜但換來的檢索精度提升非常顯著。3.2 檢索階段路徑導航與語義匹配的混合策略OpenViking 的檢索不是單一的向量召回而是三層混合第一層是路徑定向。如果你能直接算出目標內容的路徑前綴比如用戶問“增值稅發(fā)票的報銷規(guī)則”而從歷史對話或分類器中可以推斷出知識域是/finance/invoice系統(tǒng)直接導航到這個目錄下。第二層是結構化約束。在目標路徑內用屬性過濾、標簽匹配、正則規(guī)則把候選內容縮小。第三層才是向量相似度。在已經縮小過的候選集里做精確排序選出最相關的幾個上下文包。這個“先縮小范圍再語義匹配”的思路本質上和數據庫的“先索引掃描再回表查詢”是一樣的。傳統(tǒng) RAG 是“全表掃描模糊匹配”O(jiān)penViking 是“索引定位局部精排”性能和精度都會顯著提升。代碼層面查詢接口大致長這樣result library.query( path_prefix/company/product/specs, filter{product: model-x}, semantic_query最大支持的并發(fā)連接數是多少, top_k5 ) for item in result.items: print(item.path, item.score, item.content[:100])實際體驗下來路徑定向可以把“候選集”從整個知識庫縮減到幾十個節(jié)點向量匹配只需要在幾十個節(jié)點里做精排不僅效率高而且誤召回率大幅下降。我在一個包含 3 萬多個知識節(jié)點的系統(tǒng)里檢索延遲從傳統(tǒng) RAG 的 800 多毫秒降到了 200 毫秒內精度還高出一截。3.3 更新與刪除增量同步如何保證一致性傳統(tǒng) RAG 在做文檔更新時最簡單的方案是“全量重建索引”。文檔一變整個知識庫重新嵌入一遍。這在數據量小的時候沒感覺但到了百萬級文本塊的時候每次全量重建都是災難——不僅耗時還會導致檢索結果在一段時間內不穩(wěn)定。OpenViking 的思路是按路徑做增量同步。因為路徑本身是穩(wěn)定的語義錨點當內容變更時只需要重建變更路徑下的節(jié)點其他部分不受影響。比如運維手冊里的runbook-nginx-restart更新了重建的只有這個路徑節(jié)點的內容/company/product/specs/model-x下的內容完全不需要動。刪除操作也干凈很多。傳統(tǒng) RAG 刪除一個文檔你得找到它對應的所有 chunk 然后逐個刪還要擔心是否有 chunk 和其他文檔共享了向量索引OpenViking 直接刪除路徑節(jié)點它的所有子節(jié)點級聯清理。這種“級聯語義”讓上下文庫的維護變得非常簡單。一致性保證上OpenViking 通過版本號來管理。每個上下文包有版本屬性查詢時可以指定“只看最新版本”或“按時間快照檢索”。這個能力在合規(guī)審計場景特別有價值——比如你需要回溯“這個回答引用的知識是這個月的版本還是上個月的版本”快照檢索能直接回答。4. 實操半小時跑通一個 OpenViking 上下文庫4.1 環(huán)境準備與安裝OpenViking 的安裝非常簡單官方倉庫里提供了 Python 包目前支持 Python 3.10 及以上版本。它依賴的存儲后端是可插拔的本地開發(fā)用 SQLite 就夠生產環(huán)境可以接 PostgreSQL、MySQL 或對象存儲。pip install openviking openviking init --db sqlite:///context.dbinit命令會初始化數據目錄默認在當前項目下生成一個.viking文件夾里面包含存儲文件、索引目錄、配置文件。如果你要用向量檢索還需要準備一個 embedding 模型接口OpenViking 支持 OpenAI 兼容的 embedding API也支持本地模型。注意OpenViking 本身不帶 embedding 模型它只負責上下文的結構化管理和檢索編排。embedding 模型建議選與你的領域文本分布接近的模型中文場景可以優(yōu)先考慮中文語料優(yōu)化的模型效果差異會非常大。4.2 定義上下文結構安裝完成后第一步先定義你的知識庫路徑骨架。我建議先手工畫出知識樹再落到代碼里。以一個“產品知識庫”為例from openviking import ContextLibrary lib ContextLibrary() paths [ /product/overview, /product/specs/phone-a, /product/specs/phone-b, /product/faq/battery, /product/faq/network, /product/troubleshooting/common, ] for p in paths: lib.create(pathp, titlep.split(/)[-1]) lib.commit()這一步看起來簡單但路徑命名一定要提前定好規(guī)范。我的經驗是使用名詞作為路徑段避免動詞使用中劃線連接多個詞不要用空格或下劃線層級控制在三到五層太深會導致導航成本升高太淺又失去了層級組織的作用。4.3 寫入真實數據有了結構骨架下一步把真實文檔填進去。假設你有一份產品 FAQ 文檔內容是 markdown 格式結構很清晰:faq_docs [ { path: /product/faq/battery, title: 電池續(xù)航問答, content: ## 電池續(xù)航多久 標準版續(xù)航 12 小時Pro 版續(xù)航 18 小時。 ## 充電需要多久 使用快充頭30 分鐘可充至 60%。 ## 電池壽命 500 次完整充電周期后容量不低于初始的 80%。 } ] for doc in faq_docs: node lib.create( pathdoc[path], titledoc[title], contentdoc[content], metadata{source: official-faq, lang: zh} ) node.parse_structure() # 自動按 markdown 標題切分為子節(jié)點 node.commit()parse_structure()會執(zhí)行結構化解析把## 電池續(xù)航多久這些二級標題解析成/product/faq/battery/電池續(xù)航多久這樣的子節(jié)點。這樣反過來每個問答作為一個獨立節(jié)點檢索時可以精確命中到“電池續(xù)航”這個級別的粒度而不是整個文檔塊。4.4 混合檢索查詢數據寫入完畢就可以體驗 OpenViking 的混合檢索了。我建議在查詢時按場景選擇策略# 場景1精確導航適合你知道知識域時 res1 lib.query_nav(path/product/faq/battery) # 場景2路徑前綴 語義精排適合通用問題 res2 lib.query( path_prefix/product/faq, semantic_query電池用久了會不會衰減, top_k3 ) # 場景3全庫向量搜索適合不知道知識域時兜底 res3 lib.query_semantic(充電慢是什么原因, top_k5)第一個查詢直接把整個 FAQ 電池目錄下的內容拉出來適合 Agent 需要“完整上下文”而非“單點答案”時使用。第二個查詢先在 FAQ 目錄下過濾再精排命中率會高很多。第三個查詢是傳統(tǒng) RAG 的兜底方案當路徑無從推斷時再用。從實際效果來看大多數情況下場景二就夠用了。路徑前綴給了一個強先驗語義檢索只需要在局部范圍內做排序準確率高還不容易被無關內容干擾。4.5 與 LLM 應用集成最后一步是把上下文庫接入到 LLM 應用。OpenViking 本身不提供生成能力但它可以作為一個檢索工具為 Agent 提供上下文。接入方式很像給 Agent 裝了一個“知識接口”from openviking import AgentContext def retrieve_context(query, user_profile): # 根據用戶畫像推斷路徑前綴 if 報銷 in query: prefix /company/finance/invoice elif 產品參數 in query: prefix /company/product/specs else: prefix return lib.query(path_prefixprefix, semantic_queryquery, top_k5) # 接入任何 LLM 調用框架 context_items retrieve_context(發(fā)票丟了怎么重新申請) prompt f請根據以下知識庫內容回答用戶問題 {context_items.to_prompt()} 用戶問題發(fā)票丟了怎么重新申請這里的關鍵是把“上下文組織”和“模型生成”解耦。OpenViking 負責輸出結構化的知識片段LLM 只負責基于這些片段做生成。這樣的好處是上下文庫可以獨立優(yōu)化不需要每次改提示詞來修檢索漏洞。5. 性能對比與典型落地場景5.1 和向量庫直接 PK 的數據參考我在一個 5 萬文檔、約 180 萬 token 的內部知識庫上做過一次對比測試傳統(tǒng)向量檢索直接切塊embedding和 OpenViking 的差異可以用下面這張表概括維度傳統(tǒng)向量 RAGOpenViking平均檢索延遲約 780 ms約 210 ms首答準確率業(yè)務專家人工評分67%83%上下文關聯能力弱無法感知塊間關系強路徑父子結構多輪對話中的上下文切換依賴外部會話管理路徑級上下文切換知識更新代價全量重建或復雜級聯路徑級增量更新結構化數據支持差切塊破壞結構好保留層級與字段關系數字當然會因數據規(guī)模和場景不同有浮動但總趨勢是一致的OpenViking 在“結構完整、關系復雜、知識量較大”的場景里優(yōu)勢明顯在“純文本、單點事實、數據量小”的場景里優(yōu)勢不明顯甚至更復雜。5.2 適合 OpenViking 的場景從我實際接觸的項目來看有四類場景特別適合 OpenViking企業(yè)內部知識庫。組織架構、產品文檔、流程制度天然有層級用路徑樹來組織再合適不過。部門即父路徑制度即子節(jié)點權限可以按路徑繼承。Agent 自動化工作流。Agent 在執(zhí)行多步任務時每步需要不同領域的上下文。用路徑導航可以在任務步驟之間干凈地切換知識范圍不會把上一任務的上下文殘留到下一任務。多產品線客服系統(tǒng)。產品線即頂級路徑常見問題、故障排查、保修政策都在各自目錄下?？头?Agent 能夠根據用戶的語言線索自動切到對應產品線的知識路徑。合規(guī)和審計場景。由于上下文包有版本和快照能力回答問題時使用的是哪一版知識可以被審計。這在醫(yī)療、金融等強監(jiān)管行業(yè)是硬需求。5.3 不適合的場景不要盲目遷移同時我也要潑一盆冷水。有幾類場景傳統(tǒng) RAG 其實夠用上 OpenViking 反而增加復雜度純碎片化的開放域問答。比如“地球上最深的湖在哪”這類百科問答單點事實、無結構優(yōu)勢用一個向量檢索就能解決得很好。知識庫結構尚不清晰、還在頻繁演變階段。路徑樹一旦建好調整成本不低。如果業(yè)務本身處于快速迭代、目錄結構還未沉淀的早期先跑傳統(tǒng) RAG等知識邊界清晰了再上結構化管理。資源極度受限的輕量場景。OpenViking 相比純向量檢索多了一層結構解析和路徑管理需要一些額外的計算和存儲開銷。超輕量的邊緣部署未必劃算。注意我見過一些團隊把 OpenViking 當成“萬能銀彈”上來就改造所有 RAG 流程結果建了一堆不合理的路徑樹反而比原來更難維護。工具沒有好壞只有適不適合。結構化管理的前提是你對領域知識本身有清晰的分類體系。6. 實踐避坑指南路徑樹設計、解析代價、混合調權與觀測6.1 路徑樹設計的三條鐵律先講設計。路徑樹是全局架構后期調整代價高所以一開始就要定規(guī)范。我的三條鐵律是第一路徑段用名詞短語不用動詞。/operation/nginx-restart聽起來挺合理但/operations/runbooks/nginx/restart更合理——把動作放在節(jié)點的內容里路徑只承擔“領域定位”職責。第二同層節(jié)點保持粒度一致。/product/specs/phone-a和/product/specs/accessories/charger是不對等的前者是具體型號后者是品類。如果你發(fā)現某層有的節(jié)點是“個體”有的是“集合”說明這一層的語義級別沒有對齊需要重新抽象。第三預留“雜項”路徑。無論設計得多好總有一些內容裝不進現有目錄。與其硬塞進某個不合適的路徑不如建一個/misc或/inbox路徑給待分類內容定期人工梳理。這能有效避免路徑樹被不合理的分類污染。6.2 結構化解析的代價與取舍parse_structure()很方便但它不是免費的。解析大文檔時它會生成大量子節(jié)點如果每個節(jié)點都要向量化計算成本和存儲量都會上升。我的建議是按需解析。對于 FAQ 、配置手冊這類“每個小節(jié)都是獨立知識單元”的文檔結構解析收益很高。但對于長篇敘事、散文類文本結構解析的意義不大反而會切得太碎。OpenViking 允許混合策略結構化文檔走解析純文本按固定長度切塊掛載到同一個路徑下。另外如果你的文檔里有大量代碼片段解析時會被識別成代碼塊。代碼塊的向量檢索效果普遍不理想更建議用“代碼原文精確匹配周邊文本語義匹配”的方式。OpenViking 的元數據系統(tǒng)可以在節(jié)點的language字段標注code查詢時用過濾條件排除或單獨處理。6.3 混合檢索的權重調節(jié)路徑導航和語義匹配結合時權重怎么調是個核心問題。路徑定向太強會漏掉真正的盲區(qū)知識向量匹配太強又會讓路徑前綴形同虛設。我的經驗是把控制參數分成兩個維度路徑命中的強制性和召回后的排序偏好。默認配置下路徑前綴用來“生成候選集”候選集內部的排序用向量相關性。也就是說路徑是 filter向量是 ranker。這套“filterranker”的組合比“路徑得分向量得分直接相加”要穩(wěn)定得多。如果業(yè)務中“必須嚴格限定在某目錄下”就把 filter 設為嚴格模式反之如果允許跨目錄發(fā)現可以把 filter 設為“偏好模式”即路徑匹配加分但不敢硬過濾。用一個簡單的開關切換比反復調權重系數更直觀、更可控。6.4 上下文庫的可觀測性鏈路日志與命中復盤最后說一個很多團隊忽略的環(huán)節(jié)日志和復盤。傳統(tǒng) RAG 調優(yōu)困難一大原因就是“沒有可觀測性”——你不知道檢索召回了什么、為什么召回它、LLM 用了哪一段上下文。OpenViking 的路徑管理天然適合做檢索日志。你可以把每次查詢的路徑候選集、命中節(jié)點、排序分數、最終選擇的節(jié)點都記錄下來。調優(yōu)時回放日志檢查“用戶真正需要的是哪個路徑下的內容系統(tǒng)有沒有漏掉它”可以精準定位是路徑映射錯了還是語義排序偏了。我會在項目里維護一個“檢索失敗案例庫”每次跟用戶聊完后把那些回答質量差的案例倒查進去看是知識缺失、路徑映射錯誤、還是排序問題。累積一個月路徑樹的優(yōu)化方向就會非常清晰。這種數據驅動的迭代方式比靠感覺調 prompt 靠譜得多。寫在最后的一個心得OpenViking 給我最大的啟發(fā)不是“文件系統(tǒng)”這個設計本身而是它提醒我做 LLM 應用時應該重新審視一個問題知識到底應該以什么形態(tài)存在。向量碎片是我們的老朋友但它不是唯一答案甚至不是最好答案。當業(yè)務知識的復雜度上來了結構化管理幾乎必然是終局。這套方案當然還在演進但它已經把“上下文管理”從一門玄學變成了一門工程學。如果你正在做一個知識密集型 Agent 應用我建議認真評估一下這條路。