你有沒(méi)有遇到過(guò)這種情況想做一道菜網(wǎng)上搜了一堆菜譜但每個(gè)菜譜都默認(rèn)你有某種食材或調(diào)料而你想問(wèn)的是“能不能不放花生”“有沒(méi)有替代豬肉的辦法”“宮保雞丁和魚(yú)香肉絲都用什么技法”這類(lèi)需要把菜譜拆開(kāi)、跨菜譜比較的問(wèn)題。普通搜索返回的是整篇文章LLM直接回答又容易一本正經(jīng)地胡說(shuō)八道。我去年一直在琢磨怎么把菜譜變成可查詢(xún)、可推理的結(jié)構(gòu)化知識(shí)最后做了這個(gè)“圖 RAG 烹飪問(wèn)答系統(tǒng)”底層用 Neo4j 存菜譜知識(shí)圖譜用 Milvus 做語(yǔ)義向量召回再把兩者的結(jié)果組裝成上下文丟給 LLM 生成答案。這個(gè)項(xiàng)目已經(jīng)跑通了一個(gè)可演示的版本思路也可以遷移到其他垂直領(lǐng)域的知識(shí)問(wèn)答。這篇文章是完整的工程實(shí)踐記錄涉及數(shù)據(jù)建模、環(huán)境安裝、代碼實(shí)現(xiàn)和排坑過(guò)程適合正在做 RAG 應(yīng)用、或者想了解怎么把圖數(shù)據(jù)庫(kù)和向量數(shù)據(jù)庫(kù)結(jié)合在一起使用的開(kāi)發(fā)者參考。1. 為什么烹飪問(wèn)答需要“圖向量”雙路召回1.1 菜譜天然是圖結(jié)構(gòu)菜譜不是一段純文本它是一張關(guān)系網(wǎng)。一道菜包含多種食材、多種調(diào)料、多個(gè)步驟和技法食材之間有替代關(guān)系比如“花生”可以被“腰果”替代但“醬油”很難被“鹽”替代菜肴屬于某個(gè)菜系又和另一道菜共用同樣的技法。這種多對(duì)多的關(guān)系用關(guān)系型數(shù)據(jù)庫(kù)硬存也行但查詢(xún)“哪些菜不需要用油”“糖和蜂蜜能不能互換”就會(huì)寫(xiě)出一大堆 JOIN而且越查越復(fù)雜。圖數(shù)據(jù)庫(kù)就是為這種關(guān)系網(wǎng)絡(luò)準(zhǔn)備的Neo4j 里的節(jié)點(diǎn)和關(guān)系能直接表達(dá)“A 是 B 的替代品”“C 使用了 D 技法”查詢(xún)起來(lái)非常自然。早期我想用純向量數(shù)據(jù)庫(kù)做這個(gè)問(wèn)答因?yàn)椴俗V文本可以先向量化再檢索實(shí)現(xiàn)簡(jiǎn)單。但很快發(fā)現(xiàn)一個(gè)問(wèn)題向量檢索擅長(zhǎng)的是“語(yǔ)義相似”它知道“宮保雞丁”和“雞丁炒花生米”在語(yǔ)義上有點(diǎn)像但它不知道雞丁和花生米之間是否存在某種依賴(lài)關(guān)系也無(wú)法推理“去掉花生米之后這道菜的結(jié)構(gòu)還成立嗎”。圖數(shù)據(jù)庫(kù)恰恰補(bǔ)上了這塊短板——它能把菜譜中的實(shí)體和關(guān)系暴露給后續(xù)的生成步驟讓 LLM 不只是“讀到”一段文本而是“看到”一個(gè)可理解、可驗(yàn)證的知識(shí)結(jié)構(gòu)。1.2 純向量檢索的短板與圖 RAG 的互補(bǔ)邏輯我一開(kāi)始只用了向量檢索效果怎么說(shuō)呢問(wèn)它“魚(yú)香肉絲有沒(méi)有不放豬肉的做法”它能搜到一些魚(yú)香肉絲菜譜但給出來(lái)的答案就是把菜譜原封不動(dòng)貼出來(lái)沒(méi)有任何替代建議因?yàn)樗緵](méi)檢索到“豬肉”這個(gè)實(shí)體在食材關(guān)系網(wǎng)中的位置。后來(lái)我在檢索結(jié)果里強(qiáng)行塞入實(shí)體關(guān)系效果立刻變好。這讓我意識(shí)到RAG 的上下文不一定是“一堆文本塊”還可以是“一個(gè)從知識(shí)圖譜里提取出來(lái)的子圖”。這種把圖結(jié)構(gòu)作為上下文的一部分喂給 LLM 的做法就是所謂圖 RAG。具體來(lái)說(shuō)這個(gè)系統(tǒng)的雙路召回邏輯是先用 Milvus 做語(yǔ)義粗篩從所有菜譜中找到與用戶(hù)問(wèn)題最相關(guān)的 Top-K 個(gè)菜譜然后把這幾個(gè)候選菜譜在 Neo4j 里對(duì)應(yīng)的節(jié)點(diǎn)撈出來(lái)沿著關(guān)系向外擴(kuò)展一跳拿到關(guān)聯(lián)的食材、技法、替代關(guān)系最后把“候選菜譜文本 圖擴(kuò)展出的關(guān)系三元組”合并成結(jié)構(gòu)化的上下文交給 LLM 生成回答。向量負(fù)責(zé)“廣度”圖負(fù)責(zé)“深度”LLM 負(fù)責(zé)“組織語(yǔ)言和推理”。1.3 系統(tǒng)整體架構(gòu)與數(shù)據(jù)流概覽整個(gè)系統(tǒng)由四個(gè)模塊組成菜譜數(shù)據(jù)處理、Neo4j 圖譜、Milvus 向量庫(kù)、LLM 服務(wù)編排。處理流程如下收集菜譜原始文本我用的是開(kāi)源中文菜譜數(shù)據(jù)集大約 4000 道菜。用規(guī)則模板 簡(jiǎn)單命名實(shí)體識(shí)別從菜譜中抽取出菜名、食材列表、調(diào)料列表、步驟、技法、口味標(biāo)簽。將抽取結(jié)果節(jié)點(diǎn)化寫(xiě)入 Neo4j菜譜節(jié)點(diǎn)、食材節(jié)點(diǎn)、技法節(jié)點(diǎn)、口味節(jié)點(diǎn)以及它們之間的關(guān)系。同時(shí)把菜譜的核心信息拼接成一段文本例如“菜名魚(yú)香肉絲食材豬里脊、木耳、胡蘿卜…技法炒口味魚(yú)香……”向量化后寫(xiě)入 Milvus。用戶(hù)提問(wèn)時(shí)先用 LLM 做一層查詢(xún)理解提取食材/菜名等實(shí)體然后用這些實(shí)體直接到 Neo4j 查相關(guān)圖譜同時(shí)把原始問(wèn)題送入 Milvus 進(jìn)行向量檢索。把圖譜查詢(xún)結(jié)果和向量召回結(jié)果合并構(gòu)造 prompt調(diào)用 LLM 生成最終答案。流程圖我故意不畫(huà)文字描述可能更直觀(guān)。整個(gè)系統(tǒng)用 Python 編寫(xiě)Neo4j 和 Milvus 都是獨(dú)立服務(wù)LLM 可以接 OpenAI 兼容接口也可以接本地部署的模型我后來(lái)為了省錢(qián)換成了 Ollama 跑的 Qwen。下面從建模開(kāi)始逐層拆解。2. 知識(shí)圖譜建模用 Neo4j 把菜譜變成可以推理的圖2.1 菜譜數(shù)據(jù)獲取與清洗數(shù)據(jù)是項(xiàng)目的起點(diǎn)。我用了一個(gè)開(kāi)源的中文菜譜數(shù)據(jù)集包含菜名、原料列表、步驟、菜系等字段。原始數(shù)據(jù)質(zhì)量參差不齊最大的問(wèn)題有三個(gè)同一食材有不同寫(xiě)法“馬鈴薯”和“土豆”“花生米”和“花生仁”調(diào)料和食材混在一個(gè)字段里步驟是長(zhǎng)文本很難直接拆出技法。我的處理思路是先做詞表歸一化把常見(jiàn)同義詞映射到一個(gè)標(biāo)準(zhǔn)名稱(chēng)再根據(jù)一個(gè)預(yù)置的食材調(diào)料詞典把原料字段分割成結(jié)構(gòu)化列表。這個(gè)詞典我維護(hù)了大概 800 個(gè)常見(jiàn)條目雖然不能覆蓋全部食材但覆蓋了訓(xùn)練數(shù)據(jù)集里 90% 以上的情況。清洗后的數(shù)據(jù)格式大致是{ name: 魚(yú)香肉絲, cuisine: 川菜, ingredients: [豬里脊, 木耳, 胡蘿卜, 冬筍, 泡椒, 蔥姜蒜], seasonings: [醬油, 醋, 糖, 鹽, 淀粉], steps: [里脊切絲加鹽、淀粉腌制備用, 木耳、胡蘿卜、冬筍切絲, 熱鍋涼油下肉絲滑熟, 爆香泡椒、蔥姜蒜加入配菜翻炒, 調(diào)入醬油、醋、糖勾芡出鍋], techniques: [炒, 滑炒, 勾芡], flavors: [魚(yú)香, 酸甜, 微辣] }清洗這一步容易被忽略但它是整個(gè)項(xiàng)目的地基。如果食材沒(méi)有歸一化圖里的同一個(gè)食材可能會(huì)拆成好幾個(gè)節(jié)點(diǎn)替代關(guān)系就會(huì)斷裂。我后來(lái)特意加了一個(gè)合并步驟把 Neo4j 中同名的食材節(jié)點(diǎn)合并這樣關(guān)系才能聚攏。2.2 節(jié)點(diǎn)與關(guān)系設(shè)計(jì)Recipe、Ingredient、Technique、Flavor、替代關(guān)系知識(shí)圖譜沒(méi)有唯一正確的設(shè)計(jì)但有一個(gè)原則節(jié)點(diǎn)要代表“會(huì)被反復(fù)查詢(xún)的實(shí)體”關(guān)系要代表“會(huì)被反復(fù)提問(wèn)的語(yǔ)義”。我的圖譜包含以下節(jié)點(diǎn)類(lèi)型Recipe菜譜屬性有 name、cuisine、description。Ingredient食材/調(diào)料屬性有 name、category食材還是調(diào)料。Technique技法屬性有 name例如炒、蒸、炸、烤。Flavor口味標(biāo)簽屬性有 name例如魚(yú)香、麻辣、清淡。DietaryTag膳食標(biāo)簽屬性有 name例如素食、清真、無(wú)麩質(zhì)。這個(gè)節(jié)點(diǎn)對(duì)替代推薦特別有用。關(guān)系類(lèi)型及含義關(guān)系起點(diǎn)終點(diǎn)含義CONTAINSRecipeIngredient菜譜包含該食材USES_TECHNIQUERecipeTechnique菜譜使用了某種技法HAS_FLAVORRecipeFlavor菜譜具有某種口味CAN_SUBSTITUTEIngredientIngredient兩種食材在特定場(chǎng)景下可以互換RELATED_RECIPERecipeRecipe共用至少兩種食材的菜譜相似CAN_SUBSTITUTE關(guān)系是圖譜里最有價(jià)值的部分。我從兩個(gè)渠道構(gòu)建一部分是人工整理的常見(jiàn)替代規(guī)則比如花生替代腰果、豬油替代植物油、白糖替代冰糖另一部分是從“共用食材和技法”的關(guān)系中推導(dǎo)候選替代關(guān)系再人工過(guò)濾。最終得到約 600 條替代邊不多但足夠覆蓋常見(jiàn)問(wèn)題。2.3 Cypher 導(dǎo)入從 CSV 批量創(chuàng)建圖譜數(shù)據(jù)清洗完成后我用 Cypher 語(yǔ)句把結(jié)構(gòu)化數(shù)據(jù)導(dǎo)入 Neo4j。這里不推薦逐條執(zhí)行 CREATE 語(yǔ)句數(shù)據(jù)量大時(shí)太慢。我直接導(dǎo) CSV 文件。步驟如下把菜譜、食材、技法、口味分別導(dǎo)出為 CSV 文件。把菜譜-食材關(guān)系、菜譜-技法關(guān)系等導(dǎo)出為關(guān)系 CSV 文件。用LOAD CSV WITH HEADERS FROM file:///recipes.csv AS row逐行創(chuàng)建節(jié)點(diǎn)。為了加速創(chuàng)建關(guān)系先為節(jié)點(diǎn)創(chuàng)建唯一約束例如CREATE CONSTRAINT recipe_name_unique FOR (r:Recipe) REQUIRE r.name IS UNIQUE。核心導(dǎo)入語(yǔ)句示例// 創(chuàng)建食材節(jié)點(diǎn) LOAD CSV WITH HEADERS FROM file:///ingredients.csv AS row MERGE (i:Ingredient {name: row.name}) SET i.category row.category; // 創(chuàng)建菜譜節(jié)點(diǎn) LOAD CSV WITH HEADERS FROM file:///recipes.csv AS row MERGE (r:Recipe {name: row.name}) SET r.cuisine row.cuisine, r.description row.description; // 創(chuàng)建關(guān)系 LOAD CSV WITH HEADERS FROM file:///recipe_ingredient.csv AS row MATCH (r:Recipe {name: row.recipe_name}) MATCH (i:Ingredient {name: row.ingredient_name}) MERGE (r)-[:CONTAINS]-(i);這里有個(gè)注意點(diǎn)CSV 導(dǎo)入時(shí)如果數(shù)據(jù)里有中文逗號(hào)或換行符容易導(dǎo)致解析錯(cuò)位。我的解決辦法是導(dǎo)出 CSV 時(shí)統(tǒng)一用\t作為分隔符然后在LOAD CSV里指定FIELDTERMINATOR \t。另外源數(shù)據(jù)里食材名稱(chēng)可能帶前后空格導(dǎo)入前要清洗否則MATCH匹配不上。2.4 Neo4j 安裝與配置的坑Windows 桌面版、APOC 插件Neo4j 的安裝值得一提因?yàn)椴煌到y(tǒng)差別很大。我在 Windows 上用的是 Neo4j Desktop。下載安裝后需要?jiǎng)?chuàng)建一個(gè)本地?cái)?shù)據(jù)庫(kù)設(shè)置密碼。常見(jiàn)問(wèn)題有兩個(gè)一是初始密碼要求比較復(fù)雜容易記不住建議直接存到密碼管理器里二是導(dǎo)入 CSV 時(shí)提示“Couldnt load the external resource”這是因?yàn)槟J(rèn)導(dǎo)入目錄是數(shù)據(jù)庫(kù)的import文件夾不是任意路徑。把 CSV 文件放到數(shù)據(jù)庫(kù)目錄/import/下就能解決。另一個(gè)繞不開(kāi)的坑是 APOC 插件。我原本想用apoc.load.json解析數(shù)據(jù)但 Neo4j Desktop 里啟用 APOC 需要手動(dòng)把插件 jar 包放進(jìn)plugins目錄并且在配置文件里開(kāi)啟。不同 Neo4j 版本對(duì) APOC 版本要求不同如果對(duì)不上啟動(dòng)會(huì)報(bào)錯(cuò)。我的建議是Noe4j 5.x 用對(duì)應(yīng)的 APOC 5.x 版本不要圖新去官方 GitHub 的 Releases 頁(yè)面找匹配版本。如果你和我一樣只是簡(jiǎn)單導(dǎo)入 CSV其實(shí)不用 APOC核心 Cypher 就能完成。所以 APOC 不是必需品遇到問(wèn)題可以跳過(guò)。安好之后我推薦在瀏覽器打開(kāi)http://localhost:7474用 Neo4j Browser 檢查圖譜。寫(xiě)幾個(gè) Cypher 查詢(xún)看看節(jié)點(diǎn)有沒(méi)有建立關(guān)系。我第一次導(dǎo)入后發(fā)現(xiàn)很多菜譜節(jié)點(diǎn)沒(méi)有連上食材排查后發(fā)現(xiàn)是食材名稱(chēng)里多了一個(gè)空格用TRIM函數(shù)清理后就正常了。這種小問(wèn)題很耗時(shí)間但踩過(guò)坑之后就好了。3. 語(yǔ)義向量庫(kù)用 Milvus 承載菜譜的語(yǔ)義檢索3.1 文本切分與向量化模型選擇圖譜負(fù)責(zé)確定性關(guān)系向量庫(kù)負(fù)責(zé)把菜譜文本的整體語(yǔ)義納入檢索。我的做法是把每道菜生成一段“菜譜摘要文本”格式為菜名魚(yú)香肉絲菜系川菜食材豬里脊、木耳、胡蘿卜、冬筍技法炒、滑炒、勾芡口味魚(yú)香、酸甜這段文本直接送入 embedding 模型生成向量。不需要做復(fù)雜的分塊因?yàn)槊康啦说男畔⒘坎淮笠欢挝谋咀阋员磉_(dá)核心語(yǔ)義。如果某道菜步驟特別多我可以把步驟也拼在后面但實(shí)驗(yàn)下來(lái)對(duì)召回結(jié)果影響不大。模型方面我嘗試過(guò)text2vec-large-chinese和bge-large-zh-v1.5最終選了后者。原因是英文中文混合場(chǎng)景下 bge 更穩(wěn)且向量維度是 1024Milvus 支持起來(lái)沒(méi)有壓力。如果你用 OpenAI 的 embedding 接口也行但中文語(yǔ)義檢索效果未必比本地模型好而且有網(wǎng)絡(luò)和費(fèi)用考量。3.2 Milvus 安裝非 Docker 方式與集合設(shè)計(jì)Milvus 是個(gè)分布式向量數(shù)據(jù)庫(kù)常規(guī)推薦用 Docker 啟動(dòng)但如果你在 Windows 上不想裝 Docker其實(shí)也有辦法。Milvus Lite 是一個(gè)可以嵌入到 Python 應(yīng)用中的輕量版本適合開(kāi)發(fā)測(cè)試。不過(guò)我的項(xiàng)目用的是 Milvus 2.3 standalone 的 Windows 非 Docker 安裝方式這里必須說(shuō)清楚官方本身不支持 Windows 直接運(yùn)行 Milvus 服務(wù)但可以通過(guò) WSL2 運(yùn)行或者使用 Docker Desktop 的 Linux 容器。如果不用 Docker我的做法是在一臺(tái)固定機(jī)器上用 Linux 虛擬機(jī)裝 Milvus standalone然后本地 Python 通過(guò)局域網(wǎng)訪(fǎng)問(wèn)。WSL2 的安裝方式相對(duì)簡(jiǎn)單很多教程寫(xiě)“Milvus Windows 安裝非 Docker”實(shí)際都是在 WSL2 里跑。你可以把下面的命令在 WSL2 的 Ubuntu 里執(zhí)行。# 下載 milvus standalone 安裝腳本 wget https://github.com/milvus-io/milvus/releases/download/v2.3.4/milvus-standalone-docker-compose.yml # 編輯 docker-compose.yml把映射端口改成自己需要的 # 啟動(dòng) docker compose up -d這本質(zhì)上還是 Docker 容器但省掉了安裝 Docker Desktop 的步驟。如果你連 Docker 都不想要還有一個(gè) Milvus Lite 方案pip install milvus-lite然后直接用默認(rèn)本地存儲(chǔ)跑。我的建議是開(kāi)發(fā)階段用 Milvus Lite部署階段再用真正的 Milvus 服務(wù)。兩者 API 幾乎一致切換成本很小。Milvus 集合設(shè)計(jì)比較簡(jiǎn)單。我創(chuàng)建了一個(gè)recipe_vectors集合字段如下字段名類(lèi)型說(shuō)明idINT64主鍵我用自增整數(shù)recipe_nameVARCHAR(255)菜譜名稱(chēng)textVARCHAR(2048)摘要文本embeddingFLOAT_VECTOR(1024)向量?jī)?nèi)容建集合時(shí)要注意索引參數(shù)。我用的是IVF_FLAT索引nlist128。查詢(xún)參數(shù)設(shè)nprobe16。說(shuō)實(shí)話(huà)數(shù)據(jù)量只有幾千條用FLAT索引暴力搜索也很快但為了測(cè)試更大的數(shù)據(jù)集還是建了 IVF 索引。3.3 Attu 管理界面版本匹配問(wèn)題Milvus 自帶命令行沒(méi)有可視化界面很多人會(huì)裝 Attu 這個(gè) GUI 工具來(lái)查看數(shù)據(jù)。這里有個(gè)高頻坑Attu 和 Milvus 的版本必須匹配。比如 Milvus 2.3.x 的客戶(hù)端就不能用太老的 Attu 連接我一開(kāi)始裝了 Attu 2.3 的早前版本連接時(shí)總是報(bào)錯(cuò)“Unsupported media type”后來(lái)升級(jí)到 v2.4 才正常。建議安裝前先去 Attu 的 GitHub Releases 頁(yè)面看一下說(shuō)明確認(rèn)支持你的 Milvus 版本。另外連接地址要寫(xiě)對(duì)如果 Milvus 跑在 WSL2 里你在 Windows 瀏覽器里訪(fǎng)問(wèn)的是localhost:8000但在代碼里連接 Milvus 時(shí)要用 WSL2 的 IP通?？梢酝ㄟ^(guò)ifconfig查到不能直接用 localhost否則連接會(huì)被拒絕。3.4 寫(xiě)入與查詢(xún)向量——近鄰搜索參數(shù)我用pymilvus完成寫(xiě)入和查詢(xún)。寫(xiě)入的核心代碼from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType connections.connect(aliasdefault, hostlocalhost, port19530) fields [ FieldSchema(nameid, dtypeDataType.INT64, is_primaryTrue), FieldSchema(namerecipe_name, dtypeDataType.VARCHAR, max_length255), FieldSchema(nametext, dtypeDataType.VARCHAR, max_length2048), FieldSchema(nameembedding, dtypeDataType.FLOAT_VECTOR, dim1024), ] schema CollectionSchema(fields, descriptionrecipe semantic vectors) collection Collection(recipe_vectors, schema) collection.create_index(embedding, {index_type: IVF_FLAT, metric_type: COSINE, params: {nlist: 128}})查詢(xún)時(shí)我把用戶(hù)問(wèn)題向量化后調(diào)用collection.searchsearch_params {metric_type: COSINE, params: {nprobe: 16}} results collection.search( data[question_vector], anns_fieldembedding, paramsearch_params, limit5, output_fields[recipe_name, text] )這里有個(gè)小經(jīng)驗(yàn)距離度量我用COSINE而不是L2。因?yàn)槲谋鞠蛄康哪ｉL(zhǎng)和菜譜長(zhǎng)度有一定關(guān)系余弦相似度更能反映語(yǔ)義方向的一致。如果發(fā)現(xiàn)召回結(jié)果里混入一些奇怪菜譜可以調(diào)大nprobe或limit再結(jié)合圖譜過(guò)濾。4. 檢索增強(qiáng)編排怎么把圖和向量結(jié)果喂給 LLM4.1 兩階段召回向量粗篩 圖擴(kuò)展精排回到最初的痛點(diǎn)用戶(hù)問(wèn)“魚(yú)香肉絲有沒(méi)有不放豬肉的做法”如果只做向量召回系統(tǒng)會(huì)返回魚(yú)香肉絲的菜譜文本但不會(huì)返回“可以用雞胸肉替代豬里脊”的結(jié)論。必須讓圖數(shù)據(jù)庫(kù)參與進(jìn)來(lái)。我的編排流程是先用 LLM 對(duì)問(wèn)題進(jìn)行實(shí)體識(shí)別提取出菜名和食材名。例如這個(gè)問(wèn)題會(huì)提取出{ recipes: [魚(yú)香肉絲], ingredients: [豬肉] }。然后走兩路召回向量召回計(jì)算問(wèn)題向量在 Milvus 里返回 Top-5 菜譜名比如[魚(yú)香肉絲, 青椒肉絲, 木須肉]。圖譜召回拿著實(shí)體去 Neo4j 查先找魚(yú)香肉絲節(jié)點(diǎn)再查它包含哪些食材重點(diǎn)查 “豬肉” 這個(gè)食材節(jié)點(diǎn)有哪些替代關(guān)系同時(shí)查共享“炒”技法或相近口味的其他菜譜。兩路召回結(jié)果取并集。如果向量召回中的菜譜在圖譜里不存在就以圖譜為準(zhǔn)如果圖譜里有關(guān)系但向量沒(méi)召回也沒(méi)關(guān)系圖譜數(shù)據(jù)會(huì)直接進(jìn)入上下文。4.2 上下文組裝如何形成 LLM 可讀的 JSON這是整個(gè)系統(tǒng)最巧妙的部分。LLM 不能直接讀圖所以我把圖查詢(xún)結(jié)果序列化成三元組列表并和向量召回的文本拼在一起。一個(gè)典型的上文結(jié)構(gòu)如下{ question: 魚(yú)香肉絲有沒(méi)有不放豬肉的做法, vector_recall: [ {recipe_name: 魚(yú)香肉絲, text: 菜名魚(yú)香肉絲食材豬里脊、木耳、胡蘿卜...}, {recipe_name: 青椒肉絲, text: 菜名青椒肉絲食材豬里脊、青椒...} ], graph_facts: [ {type: contains, from: 魚(yú)香肉絲, to: 豬里脊}, {type: contains, from: 魚(yú)香肉絲, to: 木耳}, {type: can_substitute, from: 豬里脊, to: 雞胸肉, constraint: 口感略相似調(diào)味不變}, {type: can_substitute, from: 豬肉, to: 牛肉, constraint: 適合不喜歡豬肉脂肪的情況}, {type: technique, from: 魚(yú)香肉絲, to: 滑炒} ] }我把這些 JSON 直接拼到 prompt 里要求 LLM 優(yōu)先使用 graph_facts 中的關(guān)系做推理不要憑空編造食材替代。這樣做的好處是讓生成過(guò)程有據(jù)可循回答“能替代”或“不能替代”時(shí)能引用圖譜里的關(guān)系給出理由。4.3 調(diào)用 LLM 生成答案OpenAI 兼容接口 提示詞模板LLM 調(diào)用我用的是 OpenAI 兼容接口這樣可以方便地切換不同后端。下面的代碼演示了如何構(gòu)造請(qǐng)求import json from openai import OpenAI client OpenAI(base_urlhttp://localhost:11434/v1, api_keynone) def generate_answer(context: dict) - str: sys_prompt 你是資深中餐大廚。請(qǐng)根據(jù)提供的食譜知識(shí)和食材關(guān)系用簡(jiǎn)潔明確的語(yǔ)言回答問(wèn)題。如果圖譜中給出了替代關(guān)系請(qǐng)直接引用。如果沒(méi)有明確的替代關(guān)系請(qǐng)說(shuō)明食譜中沒(méi)有明確記錄替代方案。不要編造關(guān)系。 user_prompt f問(wèn)題{context[question]}\n\n檢索信息\n{json.dumps(context, ensure_asciiFalse)}\n\n請(qǐng)根據(jù)以上信息回答。 resp client.chat.completions.create( modelqwen2.5:7b, messages[{role: system, content: sys_prompt}, {role: user, content: user_prompt}], temperature0.3 ) return resp.choices[0].message.content我后來(lái)把模型切成 Qwen 2.5 7B 跑在 Ollama 上回答質(zhì)量雖然比 GPT-4 略遜色但速度夠快且離線(xiàn)可用。如果需要更好的推理能力可以換成更大的模型或 GPT-4 系列不過(guò) prompt 里的 graph_facts 要寫(xiě)得足夠清晰否則大模型也會(huì)忽略。4.4 一個(gè)完整問(wèn)題的檢索鏈路代碼演示我把整個(gè)檢索和生成過(guò)程封裝成一個(gè)answer()函數(shù)def answer(question: str): # 1. 用LLM做實(shí)體識(shí)別 entities extract_entities(question) # 2. 向量召回 vec_docs vector_search(question, top_k5) # 3. 圖譜召回 graph_facts graph_search(entities) # 4. 合并上下文 context {question: question, vector_recall: vec_docs, graph_facts: graph_facts} # 5. 調(diào)用LLM生成答案 final generate_answer(context) return finalextract_entities也是調(diào)用 LLM用一個(gè)簡(jiǎn)單的提示詞讓它輸出 JSON。vector_search就是上一節(jié)提到的 Milvussearch。graph_search則是幾個(gè) Cypher 查詢(xún)的組合核心代碼// 根據(jù)菜譜名找食材 MATCH (r:Recipe {name: $recipe_name})-[:CONTAINS]-(i:Ingredient) RETURN i.name // 查食材的替代關(guān)系 MATCH (a:Ingredient {name: $ingredient_name})-[:CAN_SUBSTITUTE]-(b:Ingredient) RETURN a.name, b.name // 查共享食材的相似菜譜用共現(xiàn)食材數(shù)排序 MATCH (r:Recipe {name: $recipe_name})-[:CONTAINS]-(i:Ingredient)-[:CONTAINS]-(other:Recipe) WHERE other r WITH other, count(i) AS shared ORDER BY shared DESC LIMIT 3 RETURN other.name, shared這些查詢(xún)?cè)?Python 中用neo4j驅(qū)動(dòng)執(zhí)行返回的 Record 轉(zhuǎn)成字典列表。要點(diǎn)是一個(gè)問(wèn)題可能涉及多個(gè)食材和菜譜因此每個(gè)實(shí)體都要查一次然后把結(jié)果合并注意去重。5. 實(shí)測(cè)效果與排坑記錄從“答非所問(wèn)”到“懂行老饕”5.1 測(cè)試問(wèn)題與檢索結(jié)果對(duì)比系統(tǒng)跑通后我做了幾組測(cè)試下面用表格列出典型問(wèn)題和效果對(duì)比。問(wèn)題純向量 RAG 的回答圖 向量 RAG 的回答魚(yú)香肉絲有沒(méi)有不放豬肉的做法給出了魚(yú)香肉絲的完整菜譜讓用戶(hù)自己做取舍直接指出可用雞胸肉或牛肉替代豬里脊并說(shuō)明圖譜中有明確替代關(guān)系同時(shí)推薦了青椒肉絲作為類(lèi)似選擇的參考宮保雞丁可以不放花生嗎介紹宮保雞丁的做法建議把花生去掉提示花生在宮保雞丁中主要提供酥脆口感如果沒(méi)有花生可以用腰果或杏仁替代并說(shuō)明這是基于食材替代關(guān)系得出的結(jié)論哪些菜適合蒸返回了幾個(gè)包含“蒸”字的菜譜片段從圖譜中直接檢索到標(biāo)簽為“蒸”的技法節(jié)點(diǎn)關(guān)聯(lián)的菜譜列表并額外推薦了“粉蒸肉”“蒸魚(yú)”等經(jīng)典菜可以看出圖結(jié)構(gòu)帶來(lái)的增量信息不是“另一個(gè)文本塊”而是推理路徑。LLM 的回答不再是羅列而是“判斷依據(jù)”。5.2 關(guān)鍵坑一實(shí)體對(duì)齊與同義詞擴(kuò)展圖 RAG 最容易被忽視的坑是實(shí)體對(duì)齊。如果我提取出的食材是“豬里脊”而圖譜中的食材叫“里脊肉”查詢(xún)就匹配不到。我做了三層處理第一層在實(shí)體識(shí)別時(shí)提示 LLM 盡量輸出標(biāo)準(zhǔn)名稱(chēng)第二層在 Neo4j 查詢(xún)時(shí)對(duì)每個(gè)實(shí)體名生成一個(gè)同義詞集合例如通過(guò)apoc.text.phonetic或自定義同義詞表第三層也是最簡(jiǎn)單的在提取實(shí)體后先做一次模糊匹配用 Neo4j 的CONTAINS或 Levenshtein 相似度找到標(biāo)準(zhǔn)名。我實(shí)際用了近似匹配MATCH (i:Ingredient) WHERE i.name CONTAINS $keyword OR $keyword CONTAINS i.name RETURN DISTINCT i.name LIMIT 5但這會(huì)產(chǎn)生很多噪聲所以最終方案是維護(hù)一個(gè)同義詞映射字典例如{雞胸肉: [雞脯肉, 雞胸], 里脊肉: [豬里脊, 里脊]}。識(shí)別出的實(shí)體先查字典沒(méi)有的話(huà)再走模糊匹配。這個(gè)字典隨著測(cè)試中發(fā)現(xiàn)的漏配逐漸擴(kuò)充。5.3 關(guān)鍵坑二Neo4j 連接池與并發(fā)查詢(xún)當(dāng)查詢(xún)邏輯變復(fù)雜Neo4j 驅(qū)動(dòng)的連接管理也會(huì)出問(wèn)題。我之前每個(gè)請(qǐng)求都新創(chuàng)建一個(gè)GraphDatabase.driver()很快報(bào)“Too many open files”。正確做法是全局維護(hù)一個(gè) driver 實(shí)例讓它內(nèi)部管理連接池from neo4j import GraphDatabase driver GraphDatabase.driver(bolt://localhost:7687, auth(neo4j, password)) # 在應(yīng)用啟動(dòng)時(shí)初始化不要每次查詢(xún)都調(diào)用 driver() 構(gòu)造器查詢(xún)時(shí)用driver.session()會(huì)自動(dòng)從池中獲取連接用完釋放。但要注意如果某個(gè)查詢(xún)耗時(shí)較長(zhǎng)應(yīng)該將 session 內(nèi)的事務(wù)盡量簡(jiǎn)短。我把一個(gè)復(fù)雜的圖譜查詢(xún)拆成多個(gè)獨(dú)立小查詢(xún)用多線(xiàn)程并發(fā)執(zhí)行總耗時(shí)反而更低。5.4 關(guān)鍵坑三Milvus 無(wú) Docker 安裝后的服務(wù)狀態(tài)管理我最初用 Milvus Lite 開(kāi)發(fā)后面換到獨(dú)立的 Milvus 服務(wù)后遇到最折騰的問(wèn)題是服務(wù)啟動(dòng)依賴(lài) etcd。Milvus standalone 的 Docker Compose 會(huì)同時(shí)啟動(dòng) etcd、minio 和 milvus 三個(gè)容器哪個(gè)掛了都會(huì)起不來(lái)。用docker compose logs milvus查看日志時(shí)最常見(jiàn)的錯(cuò)誤是 etcd 連接超時(shí)。我的解決方式是在啟動(dòng) Milvus 之前先確認(rèn) etcd 容器健康或者在 docker-compose.yml 里增加健康檢查和 restart 策略。如果你在 Windows 下用 WSL2注意要把 WSL2 本機(jī)內(nèi)存分配調(diào)大否則 Milvus 啟動(dòng)時(shí)容易 OOM。還有一個(gè)跟部署相關(guān)的點(diǎn)pymilvus客戶(hù)端和服務(wù)端版本要匹配。我客戶(hù)端從 2.2 升到 2.3 后舊代碼里connections.connect沒(méi)變但返回的結(jié)果集類(lèi)型變了output_fields字段名稱(chēng)大小寫(xiě)也略微不同。遇到問(wèn)題后去 GitHub Issues 一搜發(fā)現(xiàn)很多人遇到同樣的問(wèn)題。所以固定依賴(lài)版本非常重要?jiǎng)e一有新版本就升級(jí)。6. 還能怎么玩圖 RAG 在其它領(lǐng)域的擴(kuò)展思路烹飪問(wèn)答只是圖 RAG 的一個(gè)切入點(diǎn)。這套“知識(shí)圖譜建立關(guān)系結(jié)構(gòu) 向量庫(kù)建立語(yǔ)義索引 LLM 做生成推理”的組合可以遷移到很多場(chǎng)景。比如醫(yī)療領(lǐng)域的“用藥禁忌查詢(xún)”藥物之間的相互作用可以用圖關(guān)系表示癥狀描述和藥物說(shuō)明書(shū)文本可以向量化問(wèn)“高血壓患者能不能吃布洛芬”LLM 就能從圖中找到藥物節(jié)點(diǎn)之間的禁忌關(guān)系而不是靠猜。又比如工業(yè)維修問(wèn)答設(shè)備故障代碼、零件依賴(lài)關(guān)系、歷史維修記錄正好是圖結(jié)構(gòu)向量召回相關(guān)故障描述圖擴(kuò)展出可能的原因和零件關(guān)系生成答案時(shí)自然帶上維修步驟。我在遷移到這個(gè)系統(tǒng)時(shí)最大的體會(huì)不是寫(xiě)代碼而是想清楚“哪些知識(shí)必須用圖表達(dá)哪些知識(shí)用向量表達(dá)”。如果關(guān)系是顯式的、可枚舉的例如“A 替代 B”“A 屬于 B”放圖數(shù)據(jù)庫(kù)如果關(guān)系是模糊的、語(yǔ)義的例如“這個(gè)菜譜看起來(lái)像另一道菜”“這段描述和用戶(hù)問(wèn)題相關(guān)”放向量數(shù)據(jù)庫(kù)。兩者不是替代關(guān)系而是分工。這套項(xiàng)目的代碼我放在 GitHub 上了有需要的朋友可以留言交流。最后分享一個(gè)小技巧測(cè)試圖 RAG 系統(tǒng)時(shí)不要只問(wèn)你準(zhǔn)備好的問(wèn)題試著讓朋友隨便說(shuō)一句“我想吃酸甜口的但沒(méi)有雞肉”看系統(tǒng)能不能正確處理“酸甜”口味和“雞肉”缺失這兩個(gè)約束。如果這個(gè)都能回答得像樣說(shuō)明你的圖譜和提示詞工程真的過(guò)關(guān)了。