最近在給團隊搭建內部知識庫問答系統時遇到了一個很典型的問題大模型對通用知識很擅長但一碰到企業內部的規章制度、產品文檔、歷史項目總結回答就開始“一本正經地胡說八道”。嘗試過把資料直接拼進 Prompt很快又遇到 Token 長度限制和成本問題。后來把 RAG 體系完整落地了一遍才真正解決了“讓模型基于自有知識回答問題”這個核心訴求。這篇文章會從 RAG 的原理講起然后完整搭建一個本地知識庫問答系統涵蓋文檔加載、切塊、向量化、檢索、重排序和本地模型生成最后再聊一聊高級檢索的實戰思路。適合剛開始接觸 AI 應用開發、想搞懂 RAG 全流程的讀者也適合已經在做 LLM 應用、想優化召回效果的開發者。1. 什么是 RAG先解決“模型不知道”的問題1.1 大模型的知識局限大模型的知識來自訓練時見過的數據所以它有兩個天然短板一是訓練數據有截止時間新產生的信息它不知道二是私有知識它幾乎不可能學到比如公司內部的客戶資料、設備手冊、項目復盤、專有規范這些數據不會出現在公開語料里。如果直接把問題拋給模型它只能依靠參數里記憶的“模糊印象”來回答結果就是一本正經地編造。這不是模型不夠聰明而是它的知識邊界本身就固定了。RAG 的解決思路非常直接不要求模型記住所有知識而是在回答之前先從一個外部知識庫中檢索出相關的片段把這些片段作為上下文一起交給模型讓模型基于這些材料作答。1.2 RAG 的基本工作流程先給一個整體的流程印象用戶提問 - 查詢理解可選 - 檢索從知識庫中找回相關文檔片段 - 增強把檢索結果組裝進 Prompt - 生成大模型基于上下文生成答案 - 返回答案與引用來源整個過程可以拆成兩個離線階段和一個在線階段離線索引階段把文檔切塊對每個塊做向量化Embedding然后寫入向量數據庫。在線檢索階段把用戶問題向量化到向量數據庫里做相似度檢索取回 TopK 候選片段。在線生成階段把“用戶問題 檢索片段 系統提示詞”拼在一起交給大模型生成最終回答。這里的核心思路是讓模型學會“查資料”而不是“背資料”。1.3 RAG 與微調的邊界很多初學者會把 RAG 和微調Fine-tuning搞混。簡單區分一下維度RAG微調知識更新替換/新增文檔即可需要重新訓練私有知識引入通過檢索注入上下文通過調整模型參數幻覺控制較好可引用來源有限仍可能編造成本主要是向量化和檢索服務訓練和推理成本較高適合場景知識庫問答、實時信息查詢指令遵循、領域風格調整實際項目里兩者不是二選一而是可以結合使用。先用 RAG 解決知識的及時性和可追溯性再用微調優化模型的表達方式和工具調用能力。2. 環境準備與項目結構2.1 運行環境與版本說明本文的實戰部分以本地環境為例避開云服務依賴方便你完整復現。版本建議如下但需要根據你的實際環境調整操作系統Windows 10/11、Ubuntu 20.04 或 macOS 均可Python3.9 及以上本地模型推理llama.cpp Qwen2-7B-Instruct 量化模型向量模型BAAI/bge-small-zh-v1.5中文效果較好資源占用低向量數據庫FAISS開發環境足夠生產可替換為 Milvus 或 pgvectorWeb 框架FastAPI分詞與關鍵詞檢索jieba BM25用于混合檢索注意不同版本之間接口可能有差異比如langchain的 API 改動一直比較頻繁。本文盡量少依賴框架封裝用原生 Python 實現核心鏈路這樣你理解原理后換成任何框架都能快速上手。2.2 安裝依賴建議先創建虛擬環境python -m venv rag_env source rag_env/bin/activate # Windows 使用 rag_env\Scripts\activate接下來安裝必要依賴pip install fastapi uvicorn faiss-cpu sentence-transformers pip install llama-cpp-python pip install jieba rank-bm25如果你的機器沒有 NVIDIA GPUllama-cpp-python會走 CPU 推理速度會慢一些但勝在部署簡單。如果要安裝支持 GPU 的版本可以自行查閱對應平臺的編譯方式。2.3 項目目錄結構為了方便維護我們把項目拆分成模塊rag_demo/ ├── app/ │ ├── __init__.py │ ├── main.py # FastAPI 入口 │ ├── config.py # 全局配置 │ ├── loader.py # 文檔加載與切塊 │ ├── embedder.py # Embedding 模型封裝 │ ├── store.py # 向量索引與檢索 │ ├── retriever.py # 混合檢索 重排序 │ └── llm.py # 本地模型加載與生成 ├── data/ │ └── docs/ # 原始知識文檔 ├── index/ # 向量索引持久化目錄 └── requirements.txt這個結構不算復雜但模塊邊界清晰。索引構建、檢索、生成是獨立的環節后續替換任意一個組件都不會影響整體流程。3. RAG 核心原理拆解3.1 索引階段切塊與向量化索引階段的第一步是切塊Chunking。為什么要切塊因為大模型輸入長度有限不可能把整本書塞進 Prompt。檢索的粒度越細能命中的片段越精準。多個小片段可以組合出更豐富的上下文。切塊不是越短越好。切得太短語義不完整切得太長噪音太多還浪費 Token。比較常見的策略是固定長度切塊按字符數或 Token 數切比如每塊 300~500 字符。按段落切塊先按換行符拆成段落再把長段落繼續拆。按語義切塊用分割模型識別語義邊界比如標題、小節、句子邊界。父子切塊小片段用于檢索命中后返回對應的父級大片段用于生成。切塊之后每一個塊會通過 Embedding 模型轉換成一個高維向量。向量化的目標是語義相近的文本在向量空間里的距離更近。這里有個容易踩的坑不要在檢索時才對文檔臨時向量化。必須提前把整份文檔庫向量化并建好索引用戶查詢時才能做到毫秒級檢索。3.2 檢索階段相似度計算與召回檢索階段做的事情是計算用戶問題向量與知識庫中每個片段向量的相似度找出最相似的 TopK 片段。常見相似度計算方式余弦相似度Cosine最常用適合文本向量。內積Dot Product在歸一化向量上等價于余弦相似度。歐氏距離值越小越相似。以 FAISS 為例IndexFlatIP就是內積索引。如果向量都做了歸一化內積結果等價于余弦相似度。import numpy as np from sentence_transformers import SentenceTransformer model SentenceTransformer(BAAI/bge-small-zh-v1.5) query 如何申請設備維修 query_vector model.encode(query, normalize_embeddingsTrue) doc_vectors model.encode( [設備維修需要填寫申請單, 請假流程說明, 采購審批權限], normalize_embeddingsTrue ) scores np.dot(doc_vectors, query_vector) print(scores)輸出結果中得分最高的就是與問題最相關的片段。不過單純的向量檢索有一個問題它對關鍵詞匹配不敏感。比如用戶搜索“維修”文檔里寫的是“故障處理”雖然語義相近但向量召回可能不夠精確。這就是后面要講的混合檢索解決的問題。3.3 生成階段Prompt 增強與上下文約束檢索到相關片段后不是直接把片段丟給模型而是組裝成一個結構清晰的 Prompt。一個典型的 RAG Prompt 結構如下你是一個智能問答助手。請嚴格根據下面提供的參考文檔回答問題。 如果參考文檔中沒有足夠信息請直接回答“當前知識庫中沒有相關內容”不要編造。 參考文檔 [1] 設備維修需要填寫維修申請單交由部門主管審批。 [2] 緊急故障可以電話聯系運維中心熱線12345。 用戶問題如何申請設備維修這里有幾個關鍵點明確告訴模型“只能依據參考文檔回答”減少幻覺。要求“沒有信息時承認不知道”避免模型強行編造。給文檔編號方便模型在回答中引用。在 Prompt 中保留來源信息便于前端展示引用。Prompt 的設計直接決定了 RAG 回答質量的下限。同一個檢索結果用不同的 Prompt 模板生成出的答案可能差別很大。4. 從 0 搭建本地 RAG 知識庫問答系統接下來進入實戰環節。我們會基于 llama.cpp Qwen2-7B FastAPI 構建一個完整的本地 RAG 知識庫問答系統。核心鏈路是加載文檔 - 切塊 - 向量化 - 建立索引 - 檢索 - 增強 - 生成。4.1 文檔加載與切塊實現先實現文檔加載與切塊的模塊。這里以讀取.txt和.md文件為例你也可以擴展為 PDF、Word 等格式。文件路徑app/loader.pyimport os from typing import List def load_documents(docs_dir: str) - List[str]: 加載目錄下的所有文本文件 docs [] for root, _, files in os.walk(docs_dir): for name in files: if name.endswith((.txt, .md)): file_path os.path.join(root, name) with open(file_path, r, encodingutf-8) as f: content f.read() docs.append({source: file_path, content: content}) return docs def split_text(text: str, chunk_size: int 400, overlap: int 80) - List[str]: 按固定長度切塊并保留重疊區間避免切斷語義 chunks [] start 0 while start len(text): end start chunk_size chunk text[start:end] if chunk.strip(): chunks.append(chunk) if end len(text): break start end - overlap return chunks def build_chunks(docs_dir: str) - List[dict]: 加載文檔并返回帶有元信息的切塊列表 all_chunks [] docs load_documents(docs_dir) for doc in docs: chunks split_text(doc[content]) for idx, chunk in enumerate(chunks): all_chunks.append({ id: f{doc[source]}#{idx}, source: doc[source], text: chunk, }) return all_chunks這里切塊時增加了overlap參數目的是讓相鄰片段之間保留一部分上下文減少因為硬切導致的語義斷裂。比如一段話在 400 字符處正好被切斷重疊部分能保證下一塊的開頭有足夠信息。4.2 向量化與索引構建接下來實現 Embedding 封裝和 FAISS 索引構建。文件路徑app/embedder.pyfrom sentence_transformers import SentenceTransformer class Embedder: def __init__(self, model_name: str BAAI/bge-small-zh-v1.5): self.model SentenceTransformer(model_name) def embed_documents(self, texts): return self.model.encode(texts, normalize_embeddingsTrue) def embed_query(self, text): return self.model.encode(text, normalize_embeddingsTrue)文件路徑app/store.pyimport json import os import numpy as np import faiss class VectorStore: def __init__(self, embedder, index_dir: str index): self.embedder embedder self.index_dir index_dir self.index None self.metadata [] def build(self, chunks: list): 根據切塊列表構建 FAISS 索引 texts [c[text] for c in chunks] vectors self.embedder.embed_documents(texts) dim vectors.shape[1] self.index faiss.IndexFlatIP(dim) self.index.add(vectors) self.metadata chunks os.makedirs(self.index_dir, exist_okTrue) faiss.write_index(self.index, os.path.join(self.index_dir, faiss.index)) with open(os.path.join(self.index_dir, metadata.json), w, encodingutf-8) as f: json.dump(self.metadata, f, ensure_asciiFalse, indent2) def load(self): 加載已有的索引和元數據 index_path os.path.join(self.index_dir, faiss.index) meta_path os.path.join(self.index_dir, metadata.json) if not os.path.exists(index_path) or not os.path.exists(meta_path): raise FileNotFoundError(索引文件不存在請先執行 build()) self.index faiss.read_index(index_path) with open(meta_path, r, encodingutf-8) as f: self.metadata json.load(f) def search(self, query: str, top_k: int 5): 向量相似度檢索 query_vector self.embedder.embed_query(query).reshape(1, -1) scores, indices self.index.search(query_vector, top_k) results [] for score, idx in zip(scores[0], indices[0]): if idx 0: continue results.append({ score: float(score), text: self.metadata[idx][text], source: self.metadata[idx][source], }) return results這里選用IndexFlatIP作為索引結構。它是暴力精確檢索數據量不大時速度足夠快而且效果最準確。等數據量到了百萬級再換成 IVF 或 HNSW 也不遲。4.3 基于 FastAPI 實現檢索接口現在我們把檢索能力包裝成 HTTP 接口便于前端或其他服務調用。文件路徑app/main.pyfrom fastapi import FastAPI from pydantic import BaseModel from app.embedder import Embedder from app.store import VectorStore app FastAPI() embedder Embedder() store VectorStore(embedder) store.load() class SearchRequest(BaseModel): query: str top_k: int 5 app.post(/search) def search(req: SearchRequest): results store.search(req.query, req.top_k) return {query: req.query, results: results}啟動服務uvicorn app.main:app --host 0.0.0.0 --port 8000調用接口curl -X POST http://localhost:8000/search \ -H Content-Type: application/json \ -d {query: 如何申請設備維修, top_k: 3}返回結果里包含相似度得分、命中的文本片段和來源文件路徑方便后續拼接 Prompt 和展示引用。4.4 接入 Qwen2 本地模型生成答案檢索只是拿到了資料真正回答用戶問題還需要大模型。我們通過 llama.cpp 加載量化后的 Qwen2-7B 模型在本地進行推理。文件路徑app/llm.pyfrom llama_cpp import Llama class LocalLLM: def __init__(self, model_path: str, n_ctx: int 4096): self.llm Llama( model_pathmodel_path, n_ctxn_ctx, n_threads8, verboseFalse, ) def generate(self, prompt: str): output self.llm( prompt, max_tokens1024, temperature0.2, top_p0.9, stop[/s, Human:, 用戶:], ) return output[choices][0][text].strip()這里把temperature設置得比較低0.2是為了讓模型更嚴格地依據參考文檔作答減少隨機編造。接下來把檢索、Prompt 增強和生成串成一個完整接口。更新app/main.pyfrom fastapi import FastAPI from pydantic import BaseModel from app.embedder import Embedder from app.store import VectorStore from app.llm import LocalLLM app FastAPI() embedder Embedder() store VectorStore(embedder) store.load() # 根據實際模型路徑調整 llm LocalLLM(model_path./models/qwen2-7b-instruct-q4_k_m.gguf) class AskRequest(BaseModel): question: str top_k: int 5 def build_prompt(question: str, contexts: list) - str: docs_text \n\n.join( [f[{i1}] {item[text]}來源{item[source]} for i, item in enumerate(contexts)] ) prompt f你是一個智能問答助手。請嚴格根據下面提供的參考文檔回答問題。 如果參考文檔中沒有足夠信息請直接回答“當前知識庫中沒有相關內容”不要編造。 參考文檔 {docs_text} 用戶問題{question} 請給出準確、簡潔的回答并標注答案主要參考了哪個文檔編號。 return prompt app.post(/ask) def ask(req: AskRequest): # 1. 檢索 contexts store.search(req.question, req.top_k) # 2. 構造 Prompt prompt build_prompt(req.question, contexts) # 3. 生成 answer llm.generate(prompt) return { question: req.question, answer: answer, references: [ {text: c[text], source: c[source]} for c in contexts ], }整個流程非常清晰先檢索再增強最后生成。前端拿到answer展示答案拿到references生成引用來源這樣用戶可以看到模型回答的依據。4.5 運行與驗證完整執行流程如下。第一步準備文檔。在data/docs目錄下放入你的知識文檔比如device_repair.md# 設備維修流程 設備出現故障后使用人需要在 OA 系統中填寫維修申請單。 申請單需要注明設備編號、故障描述和期望維修時間。 部門主管審批通過后由行政部統一對接維修廠商。 緊急故障可以直接撥打運維中心電話 400-1234-567。第二步構建索引。簡單寫一個構建腳本python -c from app.loader import build_chunks; from app.embedder import Embedder; from app.store import VectorStore; chunks build_chunks(data/docs); print(chunks:, len(chunks)); store VectorStore(Embedder()); store.build(chunks); print(build done)第三步啟動服務并提問uvicorn app.main:app --host 0.0.0.0 --port 8000curl -X POST http://localhost:8000/ask \ -H Content-Type: application/json \ -d {question: 設備壞了怎么報修}預期輸出中answer會引用文檔里的設備維修流程references會包含命中的原文和來源路徑。到這里一個最小可用的本地 RAG 系統就跑通了。接下來我們繼續做高級檢索優化因為基礎版在真實場景里往往不夠用。5. 高級檢索實戰讓 RAG 更聰明5.1 混合檢索向量 關鍵詞純向量檢索擅長語義相似但有時會漏掉“關鍵詞完全一致”的文檔。比如用戶問“維修電話”文檔里確實寫了一個維修電話向量檢索可能因為句子整體語義偏移而沒有召回。解決方案是混合檢索同時跑向量檢索和關鍵詞檢索如 BM25再把兩路結果合并去重。BM25 是一個經典的關鍵詞相關性排序算法。簡單說它根據詞頻、文檔長度等因素計算查詢詞和文檔的相關性對“精確詞命中”非常敏感。文件路徑app/retriever.pyimport jieba from rank_bm25 import BM25Okapi from app.store import VectorStore class HybridRetriever: def __init__(self, vector_store: VectorStore, chunks: list): self.vector_store vector_store self.chunks chunks tokenized_docs [list(jieba.cut(c[text])) for c in chunks] self.bm25 BM25Okapi(tokenized_docs) def retrieve(self, query: str, top_k: int 5, vec_weight: float 0.5): # 向量檢索 vec_results self.vector_store.search(query, top_k * 2) # 關鍵詞檢索 tokenized_query list(jieba.cut(query)) bm25_scores self.bm25.get_scores(tokenized_query) bm25_top_ids sorted( range(len(bm25_scores)), keylambda i: bm25_scores[i], reverseTrue )[: top_k * 2] # 合并結果 score_map {} for item in vec_results: score_map[item[source] # item[text][:20]] { text: item[text], source: item[source], score: item[score] * vec_weight, } for idx in bm25_top_ids: key self.chunks[idx][source] # self.chunks[idx][text][:20] if key not in score_map: score_map[key] { text: self.chunks[idx][text], source: self.chunks[idx][source], score: 0, } score_map[key][score] bm25_scores[idx] * (1 - vec_weight) # 按融合分數排序 sorted_items sorted( score_map.values(), keylambda x: x[score], reverseTrue ) return sorted_items[:top_k]融合策略用的是加權求和。vec_weight控制向量和關鍵詞的比重實際項目里可以通過評估集來調參。也可以使用 RRFReciprocal Rank Fusion等更穩定的融合方法。5.2 重排序Rerank 提升精度混合檢索取回的 TopK 里依然可能存在“看著相關但實際不對”的片段。這時候可以加一個重排序Rerank環節先用輕量級檢索擴大召回再用一個更精確的交叉編碼器模型逐對精排。重排序的本質是把“給定問題判斷文檔是否相關”變成一個二分類問題。交叉編碼器把問題和文檔拼接后輸入模型輸出相關性分數比單純向量相似度更準。from sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-base) def rerank(query: str, candidates: list, top_k: int 3): pairs [(query, c[text]) for c in candidates] scores reranker.predict(pairs) scored list(zip(candidates, scores)) scored.sort(keylambda x: x[1], reverseTrue) return [c for c, s in scored[:top_k]]重排序會增加一次模型推理的耗時但能明顯提升最終答案的準確性。生產環境里通常把它用于 TopK 精細篩選比如先召回 20 條再用 Rerank 選 3 條進入 Prompt。5.3 查詢改寫與 HyDE用戶的問題往往不夠精確比如“這個流程需要哪些人審批”如果沒有上下文檢索系統很難判斷“這個流程”指什么。這時候可以在檢索前做查詢改寫Query Rewriting把模糊問題轉換成更明確的檢索語句。一種簡單的方法是讓大模型先把問題改寫為適合檢索的查詢詞。你是一個搜索查詢優化器。請根據用戶的原始問題生成 3 個適合檢索的查詢詞。 要求保留關鍵實體和業務術語不要修改事實信息。 原始問題這個流程需要哪些人審批另一種思路是 HyDEHypothetical Document Embeddings。它的做法是先讓大模型根據問題生成一個“假設性答案”然后用這個答案去檢索。因為假設性答案與目標文檔在語義上更接近往往比直接檢索問題效果更好。請根據你的知識回答下面問題。答案可以是猜測性的也可以是概括性的。 問題是請提供設備維修申請流程。然后把生成的答案向量化去向量庫搜索。這種方式很適合“問題簡短、文檔復雜”的場景。5.4 Agentic RAG 簡介傳統 RAG 是“一次檢索一次生成”。Agentic RAG 則把檢索過程交給 Agent 智能規劃可以多輪檢索、調用工具、逐步推理。比如用戶問“對比一下 A 和 B 兩種方案的差異”Agent 可能會先檢索 A 方案相關文檔。再檢索 B 方案相關文檔。還可能檢索“對比框架”“評估指標”等材料。最后匯總生成對比結論。這比一次性檢索做得更深但實現復雜度也高很多。適合從“單點問答”升級到“復雜分析”的場景?？梢韵日莆栈A RAG再逐步引入 Agent 能力。6. 常見問題與排查清單6.1 召回結果差檢索不到相關內容常見原因解決思路切塊太大語義被稀釋縮小 chunk_size增加 overlap切塊太小上下文不完整增大 chunk_size或使用父子切塊Embedding 模型不適合中文換用 bge-small-zh 或 bge-large-zh問題描述與文檔表述差異大引入查詢改寫、HyDE 或混合檢索數據量太少檢查文檔是否完整加載是否有編碼問題排查時最直接的方式是先打印檢索結果不經過生成環節?？纯捶祷氐钠问欠裾娴南嚓P。如果片段本身不對問題大概率在索引或檢索策略上而不是 Prompt 和模型的問題。6.2 切塊不合理導致回答破碎固定長度切塊雖然簡單但經常把完整段落攔腰截斷。比如一句話從第 390 個字符開始到第 410 個字符結束切塊后這句話只出現一半模型自然讀不懂。建議優先“按標題層級 段落”切塊。比如 Markdown 文檔先按##拆成章節再處理單個章節里的長段落。也可以用父子切塊子塊短小用于精確檢索命中的子塊關聯到父塊生成時把父塊內容作為上下文。6.3 本地模型推理慢llama.cpp在 CPU 上跑 7B 模型速度確實不快。優化思路有幾個使用更小的量化等級比如 Q4_K_M 比 Q8 更快。減少n_ctx上下文長度降低顯存/內存占用?？刂苖ax_tokens不要無腦生成長答案。對檢索片段做摘要只把關鍵信息放進 Prompt。如果條件允許升級 GPU 或使用 API 版模型。另外可以加一層緩存相同問題在短時間內直接返回歷史答案減少模型調用次數。6.4 中文 Embedding 效果不佳通用英文 Embedding 模型處理中文經常“水土不服”。建議優先選擇中文優化的 BGE 系列模型比如BAAI/bge-small-zh-v1.5。這類模型在中文語義匹配、短文本檢索上的表現更穩定。同時要注意查詢側和文檔側盡量用同一個 Embedding 模型不要混用否則向量空間不一致相似度計算沒有意義。7. 最佳實踐與工程建議7.1 數據質量優先于模型參數RAG 的效果上限由知識庫質量決定。文檔里有錯別字、格式混亂、內容過期后面做再多優化都是事倍功半。建議在進入 RAG 流程前做一輪數據清洗去除頁眉頁腳、水印、無關廣告。統一編碼格式避免亂碼。對表格數據優先轉成 Markdown 表格或結構化的文本描述。給文檔補充元信息比如來源部門、更新時間、版本號。這些元信息不僅能幫你跟蹤知識來源還可以在 Prompt 中加入“信息更新時間”讓模型自行判斷知識是否過時。7.2 建立評估集持續回歸沒有評估的 RAG 系統很難迭代。建議從業務問題中整理 50~100 條典型的“問題-答案-參考文檔編號”作為黃金測試集。每次調整切塊策略、Embedding 模型或重排序邏輯都跑一遍評估集對比答案質量和召回指標。常用的評估指標包括召回率Recall正確文檔是否出現在檢索結果中。命中率Hit RateTopK 中是否包含正確答案。忠實度生成答案是否嚴格基于參考文檔。答案相關性用戶視角的答案滿意度。評估可以通過 LLM 自動打分也可以人工抽檢。重點不是追求某個指標完美而是找到當前業務場景里的瓶頸在哪個環節。7.3 性能與緩存策略生產環境里RAG 鏈路很長每個環節都可能成為瓶頸。優化優先級一般是文檔數量上量后向量檢索從IndexFlatIP換成IndexHNSW或IVF。給檢索結果加 Redis 緩存同樣的查詢不再重復計算。Rerank 只在最后一步對少量候選做不要對全庫做。盡量流式輸出答案減少首字延遲感知。對高頻問題做預生成答案命中后直接返回不走完整鏈路。7.4 安全與權限邊界企業知識庫往往包含敏感數據。RAG 系統上線前要重點做權限隔離按用戶角色過濾可檢索的文檔集合。文檔入庫時標記可見范圍檢索時強制附加權限過濾條件。不在日志中記錄完整問答內容避免敏感信息泄露。對生成內容做脫敏校驗防止模型間接泄露訓練數據。尤其要注意RAG 并不會自動擁有權限意識。如果文檔庫里有機密文件而檢索層沒有過濾任何用戶都可能通過巧妙提問拿到不該看的內容。權限必須放進檢索鏈路而不是指望模型自行判斷。8. 總結與下一步學習路線到這里你已經完整走通了 RAG 的核心鏈路文檔加載、切塊、向量化、向量檢索、Prompt 增強、本地模型生成也了解了混合檢索、重排序、查詢改寫、Agentic RAG 等高級優化方向。下一步建議這樣安排學習第一步動手跑通本文的項目替換成你自己的文檔感受完整流程。第二步搭建一個小規模評估集觀察不同切塊參數和 TopK 對答案質量的影響。第三步引入混合檢索和 Rerank對比優化前后的效果差異。第四步熟悉 Dify、LangChain、LlamaIndex 等框架了解它們如何把本文的底層邏輯封裝成可配置模塊。第五步把檢索鏈路的權限、緩存、日志監控補齊再考慮 Agent 和復雜任務編排。RAG 不是一套固定的代碼而是一套可以持續優化的方法論。把每個環節的原理吃透工具換代時你也能快速遷移。希望這篇文章能幫你少走一些彎路有疑問歡迎在評論區一起交流。