1. 項目全景我在搭一個什么樣的“博客知識庫”1.1 一句話講清項目在做的事我給自己定了這樣一個目標用AI編程把一個博客站點從零搭起來并且讓博客自帶一個能問答的RAG知識庫。這個知識庫不是花架子而是要真的能回答我積累的文章、筆記、技術資料里的具體問題。簡單拆一下就是兩件事。第一博客本身得有內容展示能力能寫文章、能歸檔、能搜索最好還好看。第二博客里要掛一個對話入口用戶問了問題之后系統先去知識庫里檢索最相關的片段再讓大模型基于這些片段生成回答。整個過程跑通之后我的博客就不只是“展示文章”而是一個能主動答疑、能沉淀知識的站點。1.2 為什么值得做一次這樣的實戰我觀察到一個很普遍的現象很多人寫了大量技術文章、積累了海量本地筆記但真到要找某個結論的時候還是靠CtrlF或者憑記憶翻目錄。博客更慘文章多了之后訪客根本不知道你寫過什么搜索框一搜還經常搜不到重點。RAG檢索增強生成恰好能解決這個問題。它先把文檔切成小塊、轉成向量用戶提問時先從庫里把最相關的片段撈出來再讓大模型結合這些片段組織答案。這樣一來答案有出處、邏輯能追溯比純靠大模型“背答案”靠譜得多。而AI編程又能大幅降低搭建門檻博客框架、接口、前端交互很多代碼可以直接讓AI工具生成我只需要做校驗、拼接和調參。1.3 這個項目適合誰如果你是這樣的人這個項目可以直接照抄思路有一個博客或打算建博客但不想手動折騰前端細節平時用Obsidian、Notion或Markdown積累了大量筆記想給它們加一個問答入口想學RAG但不想只看概念需要一條能落地的完整路徑想試試AI編程到實戰程度而不是只在對話里讓AI寫個幾行的demo。我自己就是這類人。整個過程走下來最大的感受是AI編程解決的是“我從0到1寫好代碼”的效率問題RAG解決的是“知識從零散到系統”的組織問題兩個結合起來個人站點的價值會被放大很多。2. 第一戰讓AI幫我從零搭博客2.1 選型博客框架和AI編程工具動手前先定技術棧。博客這一層我優先考慮的不是好看而是“生成代碼后容易維護”和“部署成本低”。很多人的選擇是Hugo或VitePress前者是靜態站點生成器后者是Vue驅動的文檔站點工具。我最終用了VitePress原因是它的結構足夠簡單核心是Markdown文件加一個配置文件AI生成的代碼量小我改起來也容易。AI編程工具方面我選的是Cline它能直接讀取項目文件在終端里執行命令還能按我的指令批量改代碼適配VitePress這類結構化項目很順手。用這類工具的時候有個細節要記住不要讓它一次性把整個項目“腦補”出來而是分階段下指令重構、糾錯、再重構。2.2 第一輪構建指令該怎么寫很多人用AI編程犯的第一個錯是“幫我做一個博客”這句話太寬了。我實際第一輪指令是這樣的在空目錄下初始化一個VitePress項目采用默認主題 首頁需要展示文章列表右上角有文章歸檔和知識庫問答兩個入口 配置文件使用TypeScript格式路由用現有文件結構自動生成。這個指令明確了兩件事一是項目類型AI可以直接按VitePress的標準結構創建文件二是頁面骨架AI知道需要哪些導航和布局。第一輪我不要求它寫出完整樣式先把結構立起來。生成之后我手動補了一句npm install等依賴裝完再讓它跑一次npm run dev。我始終不建議在指令里讓AI“順便把依賴都裝好”因為不同環境網絡狀況不同裝依賴的失敗信息千奇百怪讓AI去猜不如自己掌控。2.3 迭代調試從能跑到能看骨架跑起來之后我開始加功能。歸檔頁、標簽頁、文章列表的摘要展示這些功能在VitePress里大多有現成配置或主題支持我只需要讓AI改對應的.md文件或.vue組件。這個階段最容易出現的問題是“AI把代碼改崩了”。我有一次讓它加一個“最近更新”模塊它直接把首頁布局組件給重構了運行后控制臺報錯整個頁面白屏。我當時的處理辦法是讓AI先回滾到最近一次可用版本再單獨為“最近更新”寫一個獨立組件引入到首頁而不是改動原有組件。把這個原則翻譯一下就是增量功能用獨立模塊不要動主骨架。這條經驗在AI編程里特別值錢因為它能有效兜住AI愛把文件改得面目全非的毛病。2.4 寫博客內容時如何讓AI協助更高效博客內容本身就是知識庫的原材料所以這里值得多說一句。我寫作時用Obsidian每篇文章頂部寫好元信息包括標題、標簽、摘要、日期。這個習慣一開始是為了美觀后來發現它對RAG切分和檢索特別友好因為元信息本身就可以作為檢索時的過濾條件。章節標題我盡量寫得“像問題”比如“為什么RAG需要切分文檔”“如何選擇Embedding模型”這樣知識庫被檢索到時更容易匹配用戶的問題語義。這一點是我摸索出來的知識庫的質量從寫作階段其實就已經決定了不是向量化階段才開始的。3. 重頭戲RAG知識庫完整流水線3.1 為什么RAG不是“把文件塞進向量庫”很多人對RAG的理解是把PDF往Dify里一傳等索引完成就能問答了。這是工具的用法但不是工程的做法。真實的RAG流水線包含加載、切分、清洗、向量化、存儲、檢索、重排、生成八個環節每一步出問題最終效果都會打折。我有一次給一個文檔搭RAG文件本身是HTML格式里面全是導航、推薦位、頁碼這些無關內容。如果不清洗就直接向量化檢索出來的片段很可能是一段頁面導航文字大模型還會一本正經地引用它答案自然一塌糊涂。所以數據預處理必須放在第一位這里省時間后面只會在“檢索不準”上花更多時間。3.2 數據準備與切分策略我博客和筆記的內容以Markdown為主清洗起來相對簡單。我的做法是先按文章為單位保留元信息再把正文按二級標題切成塊。切分顆粒度是RAG效果的關鍵之一。塊太大檢索到的片段包含太多無關內容大模型的答案會發散塊太小語義不完整模型難以理解上下文。我的實踐值是每個塊大概300到500字重疊窗口設30到50字確保標題能和正文一起被切進同一個塊里。舉個例子文章標題RAG實戰筆記 二級標題向量化流程 正文第一步將文本轉成向量... 切分結果塊1RAG實戰筆記 向量化流程 第一步將文本轉成向量...這個結構能讓檢索結果自帶“出處上下文”生成階段引用起來也更準確。做這塊時我直接用LangChain的MarkdownHeaderTextSplitter它比普通字符切分強很多因為它知道Markdown的層級結構不會把一個二級標題下的內容拆得七零八落。3.3 向量庫選擇與Embedding銜接向量庫我用的是輕量級的Chromadb原因很樸素它是純本地運行不需要單獨起服務也沒有煩人的鑒權配置對一個個人博客級別的RAG系統足夠了。如果你有更高的并發或分布式需求再考慮升級到pgvector或Milvus但對個人項目來說先用輕量方案跑通流程最重要。Embedding模型的選擇同樣關鍵。我用的是開源下發的本地模型這樣數據不出本地也避免每次調用外部API的延遲和費用。選模型時要關注兩個指標一是支持的最大序列長度至少要覆蓋分塊后的文本長度二是向量維度維度太低可能丟失語義太高了存儲和計算壓力大一般768或1024維是常見選擇。3.4 檢索層讓召回更準的三個動作知識庫檢索最怕的就是“召回了看似相關、實際跑題”的片段。我做了三個動作來改善第一混合檢索。不要只用向量相似度還要配合關鍵詞匹配。有的問題語義明確比如“Dify安裝”關鍵詞打分比語義向量更靠譜有的問題描述模糊比如“這個配置我改壞了該怎么辦”向量檢索更優。兩者加權合并效果比我單獨用向量檢索明顯更好。第二重排序。第一輪檢索可以多召回一些候選片段比如20條然后用重排序模型在本地對這20條按相關性重新打分只取前5條送進大模型。這一步能顯著提高答案的精確度代價是多花幾十毫秒的時間個人博客完全能接受。第三過濾條件。如果你準備了元信息那就在檢索前把范圍縮小比如“只查2024年之后的文章”“只查RAG分類下的筆記”。我后來發現這步尤其有用它從源頭降低干擾模型回答時也更聚焦。如果你用的是Dify這類成熟平臺它內部其實已經封裝了召回和重排序的選項但你要理解每一個開關的含義而不是一股腦開成最高配置。實際經驗是配置越復雜調試時越難定位問題。3.5 生成層提示詞與引用溯源檢索完之后就是生成回答。提示詞的寫法直接影響回答質量。我用的核心模板是這樣的你是博客的知識問答助手。請根據以下資料回答問題。 如果資料中沒有相關答案請明確說“知識庫中還沒有相關內容” 不要編造。回答末尾附上引用資料的標題和二級標題。 資料 {context} 問題 {question}這個模板有三個關鍵點第一限制模型不能編造這對RAG來說比什么都重要第二要求引用來源我可以展示給用戶看增加信任感第三告訴模型沒找到就直接說避免無中生有的幻覺。引用溯源還有一個好處就是讓用戶能回到原文閱讀知識庫和博客本身就是一體的點擊引用可以直接跳到對應文章體驗會自然很多。3.6 RAG測評別靠感覺用指標說話知識庫搭完之后不能我問兩個問題覺得“還行”就收工。我針對自己的知識庫整理了一套測評方法。我用的指標是RAGAS框架里的三類忠實度答案有沒有瞎編、相關性答案有沒有偏離問題、上下文精確率召回的片段里到底有多少是真正有用的。把它們跑一遍比我主觀判斷靠譜得多。操作上我準備了一批測試問題集每類知識至少三四個問題然后單獨調用知識庫無向量檢索模式對比召回結果再把答案拿去評測。如果發現某些問題召回不到相關片段優先懷疑切分顆粒度和檢索TopK設置如果召回到了但答案差那就要檢查提示詞和生成模型。這套方法建議每個打算認真做RAG的人都要走一遍。網上很多教程教你怎么搭一個RAG卻不教你怎么判斷它好不好結果就是上線了才發現答案離譜體驗非常崩。4. 把知識庫接進博客并讓檢索更準4.1 從本地服務到博客頁面最早RAG流水線只是在本地Python腳本里跑通過命令行問答但這顯然沒辦法給博客訪客用。于是我把RAG模塊封裝成一個獨立的API服務提供兩個接口一個用于上傳或同步文章一個用于問答請求。問答接口的流程是接收用戶問題去向量庫檢索相關片段拼裝提示詞調用大模型接口生成回答最后把回答和引用文章列表返回前端。博客前端在“知識庫問答”頁面里調用這個接口用Markdown渲染答案同時展示引用來源。這里我踩了個坑就是前端直接請求本地API會碰到跨域問題。解決辦法是給API服務加上CORS允許來源配置把博客域名放進去。如果是部署在服務器上還需要用Nginx把API路徑反向代理到博客同域名下順便把HTTPS證書掛上這樣才能保證頁面里是夠安全地調用。4.2 查不準按這個順序排查在實際使用中我幾乎每天都會遇到幾個“檢索不準”的問題。經過一段時間的排查我把步驟固定下來了。第一先看召回片段本身有沒有問題。我會在測試頁面里把每次回答對應的上下文片段打印出來如果片段明顯不對那說明切分或檢索有問題。第二檢查用戶問法和知識庫內容表述是否差異過大比如用戶說“博客部署不上”但文章標題寫的是“VitePress發布流程”這時可以考慮給文檔起別名或增強同義詞替換。第三檢查向量模型是否匹配有些模型對短文本不友好或者分塊長度超過模型上限導致后半截被截斷這些都是隱性問題。有一個特別經典的坑更新了知識庫文檔之后問答結果還是舊內容。很多向量庫不會自動刪除過期文檔而是直接追加新向量導致舊版本內容仍然能被檢索到。解決辦法是在寫入新文檔前先按文檔ID刪除舊記錄。這問題我在Dify升級后也遇到過后來我都是在同步前做一次明確的清理操作。4.3 幾個RAG實戰中的常見報錯下面這幾個問題我在不同階段都碰到過如果你也在做類似項目大概率會遇到。問題現象解決辦法向量庫索引為空檢索結果為空問答答“不知道”檢查文檔解析是否有報錯確認切分后塊數量大于0回答明顯照抄某段話答案長而空洞沒有歸納檢查上下文是否過多降低TopK或調整提示詞引用來源與回答無關模型用別的片段撐答案提高上下文精確率優先用重排序過濾Dify升級后無法保存知識庫修改知識庫報Internal Server Error升級后重置向量庫索引參數尤其是模型維度配置4.4 別急著上Graph RAG和Agentic RAG熱詞里經常能看到Graph RAG、Agentic RAG這樣的新概念。我建議個人項目先不要追。Graph RAG確實擅長處理實體關系的多跳推理比如“張三發明了A技術A技術被用在B產品里”但代價是建圖、抽取、存儲的復雜度都很高配置不好反而拖慢檢索。Agentic RAG更激進讓智能體自己決定怎么檢索、調什么工具數據處理正確性和可控性要求更高出錯時排查的難度也更大。我把它們當作后續演進方向但當前階段先把基礎的“檢索-重排-生成”鏈路做扎實系統穩定了再考慮升級。做工程切忌一上來就想著用最先進的架構先用簡單方案跑通再談優化。5. 踩坑實錄與我的復盤硬經驗5.1 這套方案真正值錢的三個資產復盤下來這個項目給我留下的不只是兩個可運行的系統而是三樣能復用的東西。第一是內容資產。我在搭知識庫的過程中把散落在各個地方的文章、筆記、代碼片段全部集中整理了一遍格式統一了、元信息補全了這些內容本身就是長期積累的財富。第二是調試方法論。對于“AI生成代碼”和“RAG問答效果”這兩件不確定性強的事我形成了固定排查順序先縮小問題范圍再分模塊打日志驗證最后才改參數或重構。這套方法用到其他項目中同樣有效。第三是提示詞資產。我給AI編程、給RAG生成、給知識庫問答都寫了一套穩定的提示詞模板后續再開新項目可以直接復用不用從零摸索。5.2 哪些環節別迷信AI自動完成我雖然一直在用AI編程但有幾個環節堅持人工把控。安全相關配置不能全部交給AI。比如API密鑰、數據庫密碼、服務器防火墻規則這些讓AI自動生成有風險萬一它把密鑰硬編碼進前端代碼或者把端口完全對外開放后果不堪設想。數據處理細節也不能全權交給AI。文檔清洗、切分策略、元信息格式這些需要結合自己的內容特點來定AI不了解你的業務背景。你可以讓AI生成代碼但清洗規則如何定、保留哪些字段必須自己決定。部署上線流程建議手動走一遍。我第一次用AI寫Dockerfile和Nginx配置結果端口映射寫錯容器內部服務監聽在127.0.0.1上外面一直訪問不到。手動過一遍部署流程能讓你對系統每個環節有一個明確的認知出了故障也不至于慌。5.3 我的幾點真心體會這個項目做完之后我最深的體會是工具進步改變的只是體力部分——生成代碼、跑通流水線、組合組件這些確實快了很多但真正決定上限的還是你自己對內容的理解和對問題本質的把握。小技巧我再分享一個如果你在調RAG效果時始終不滿意不妨試試把用戶問題改寫成更標準化的一句描述再檢索比如用戶問“博客打不開怎么辦”先讓模型生成一句改寫“如何解決博客無法訪問的問題”再做向量檢索。這個簡單的先改寫后檢索技巧往往比換模型、調參數更能帶來驚喜。最后我建議大家不要把知識庫當成一次性的項目來做它就是你的第二大腦需要持續往里喂內容定期清理失效信息重新評估檢索效果。隨著文章越來越多你會發現知識庫的價值不是線性增長而是滾雪球式的增長。