一篇看懂：企業RAG知識庫項目的全生命周期設計_算法|客服|自動化

文章圖片

文章圖片

在當今數字化轉型浪潮中，企業對知識管理的需求日益增長，而AI技術的融入為企業知識庫的構建帶來了新的機遇。本文將深入剖析企業RAG（檢索增強生成）知識庫項目的全生命周期設計，從項目啟動到落地實施，詳細解讀如何從零開始構建知識庫，如何提升知識庫的召回率與準確率，以及如何通過數據處理和系統設計實現知識的有效管理和應用。

在AI項目中分為幾種不同類型的應用，例如AI原生應用（各種端到端的平臺）、AI垂類項目（基于RAG和知識庫的行業知識庫項目、各種基于知識庫和智能體的搭建的應用）
這些項目類型中，知識庫產品落地是較為簡單的，所以本次從知識庫項目的起始到結束全部給大家講明白，在企業內一個知識庫項目從部署大模型到落地輸出成果都需要哪些步驟，從接到需求到項目落地，產品經理又都需要做什么？
雖然本次是以項目視角描述構建過程，但無論是企業內部自建團隊，還是外包給供應商，都可以遵循這套生命周期。
看完本篇文章你可以了解：

如何從0-1構建知識庫？
如何提升知識庫召回率、準確率？常見問題如何定位解決？
如何做數據處理？
構建知識庫后還可以在這個基礎上做什么？

項目構建流程整個項目的落地流程如下，我們也將會按照這個大致的步驟分析和落地本項目

方案評估AI+知識搜索/問答是企業內最好落地的場景之一，且價值較高，作為企業的底層建筑，通常是第一個落地，但是構建和維護高質量的知識庫（包括數據收集、處理、向量化、索引創建等）是一個成本較高的過程，所以企業通常更愿意找專業的公司完成此類工作。

業務痛點分析不同公司在沉淀資料構建知識庫的需求是不一樣的，首先收集企業痛點才好根據痛點需求設計方案，常見企業痛點如下

信息檢索效率低：企業知識散落在多處（在線文檔、本地文件、紙質資料），員工或客戶查找信息耗時耗力。
重復性咨詢成本高：客服、HR、IT支持等部門需要花費大量精力回答重復性問題。
知識傳承困難：核心員工離職易造成知識斷層，新員工上手周期長。
合規與準確性風險：在金融、法律、醫療等領域，確保輸出信息的準確性和合規性至關重要。通用大模型的“幻覺”問題在此類場景下是不可接受的。
內部數據隱私：企業核心數據（如財務、戰略、研發資料）高度敏感，不能依賴公開的在線大模型服務。

指標拆解看完上面的痛點，肯定能發現，雖然確實有這個問題，但還是不夠準確，無法指導落地與實施。
我們產品經理就是要將模糊的業務痛點轉化為清晰、可量化的業務目標與評估指標，并設定項目目標，這樣才能把一個空洞模糊的指標落地下來。
指標拆解法一：公式法
假設北極星指標是 “節省人力成本” 。
節省成本 = (AI處理的會話數) * (人工處理單次會話的平均時長) * (客服時薪)
為了提升“節省成本” ，你可以：

提升 AI處理的會話數：這又可以拆解為總會話數 * AI應答率。
降低人工處理單次會話的平均時長：如果AI作為助手賦能人工，可以通過提供高質量信息來達到此目的。

指標拆解法二：因素拆解法
假設北極星指標是 “用戶自助問題解決” 。
為了讓用戶自助解決問題，必須滿足：
1）用戶愿意用
系統入口是否明顯？ -> 觸達率
2）AI能聽懂用戶的問題

AI是否能正確理解用戶意圖？ -> 意圖識別準確率
用戶是否需要反復換說法？ -> 平均會話輪次

3）知識庫里有相關知識

用戶提問后，系統是否能找到知識？ -> 知識召回率
有多少問題系統完全找不到答案？ -> 零結果率

4）AI給出的答案是優質的

答案是否準確無誤，沒有幻覺？ -> 答案準確性
答案是否解決了用戶的問題？ -> 答案采納率
系統響應速度快不快？ -> 平均響應時長

系統設計需求細化與確認1）細化需求：現在需要深入現場，和真正使用系統的一線用戶以及管理知識源的專家進行交流。細化并確認中的需求，尤其是智能問答的應用場景、對話流程、知識庫的具體內容和結構，設計出項目架構。
2）開展調研：列出調研明細，雙方分別需要如何配合，原則就是根據你的目標列出你要做什么，你需要對方（客戶）什么人員、怎么配合你、提供什么資料，調研方法通常是以下這些：
（1）用戶訪談：
對象：挑選典型用戶，包括新手、專家、高頻使用者和偶爾使用者。
問題清單 (半結構化)：準備問題提綱，觀察客戶現有工作流程中的問題，根據問題挖掘痛點，發現隱性知識和求助路徑，探索期望功能和交互方式。
（2）現場觀察：
內容：如果條件允許，直接坐在用戶旁邊，觀察他們如何工作。這能發現很多用戶在訪談中因習以為常而忽略的細節。
（3）問卷調查：
優勢：當用戶群體龐大時，可以通過問卷快速收集量化數據。
內容：可以調查最常查詢的知識類型、對當前信息查找方式的滿意度評分、最希望優先解決的問題等。
3）收集資料：客戶各種數據都需要提供，且需要明確資料收集的方式。

企業內部數據：如歷史紙質資料、各個系統的歷史資料、掃描件、各種在線文檔……
外網公開數據：各種公開資料，通常使用爬蟲的方式收集，不過如果是信創項目，爬蟲可能存在風險，這也是需要提前與客戶溝通的內容。
付費外采數據：內部資料不足或者不夠優質，如各種公司的資料、行業報告等，就需要付費了。

4）數據整理：與客戶的業務專家共同設計知識結構，定好全部數據的儲存框架、策略，否則后續的維護和查重工作也非常頭大。
5）對接方式：不同的數據對接方式是不一樣的，比如客戶有數據中臺，那我們直接對接數據中臺，客戶紙質文件是需要落地轉為電子文件的。

需求驗證1）數據范圍界定：明確知識來源，如內部Wiki、PDF/Word文檔庫、數據庫、付費外采的行業報告等。
2）POC產品選擇：市面上可以選擇的知識庫、智能體搭建產品有 fastgpt、n8n、coze、dify、AppBuilder等等，后續會專門出一篇關于產品評測選擇的文章。
3）技術路徑：

是否需要知識庫 (RAG)：對于需要依據特定、私有、高時效性知識進行回答的場景， RAG是必選項，它可以有效解決LLM的知識局限和幻覺問題。
是否需要微調 (Fine-tuning)：當需要模型模仿特定風格（如客服語氣）或掌握特定領域的復雜指令時，可以考慮微調。但微調成本高，對數據質量要求苛刻，需謹慎評估。

判斷是否需要微調：微調的成本是非常高的，判斷方式主要基于以下幾點
1）數據模塊
-數據偏移：微調提供的數據和模型原始數據差異過大，模型在新任務上表現反而不會好
-數據質量差：微調需標注準確、覆蓋全面，噪聲數據會大大影響模型性能
2）訓練模塊
-過擬合：訓練方式不當或者數據量不夠，泛化能力下降，過度專注單一任務
-數據遺忘：訓練可能導致原預訓練數據被遺忘，所以一定要選擇合適匹配的模型進行訓練
3）成本模塊
-人力/時間成本：微調需足夠高質量數據（如數千條標注數據），項目預算是否可以覆蓋

4）驗證目的：先收集測試數據，通過測試數據就可以知道，這個過程能夠更深層的梳理出本次項目可能存在的風險

技術預研：要判斷客戶目前積累的數據和我們沉淀的算法，是否可以達到業務需求，任何項目都是盡可能采取更小成本的方式落地，初期產品大多會以最簡單的方式，比如Prompt工程初步做驗證，整體評估下來如果數據不滿足，產品需要協助算法在客戶內部獲取數據
評估算力資源：需要評估項目所需的GPU型號和顯存，取決于模型的參數量以及采用的操作方式，如下表是常見的部署方式和所需資源，通常由產品經理、算法工程師和研發工程共同完成

需求詳細定義

功能需求: 比如AI Agent的對話能力、意圖識別、多輪對話、上下文理解、知識推薦、任務執行（如開單、查詢）
集成需求：與客戶內部系統，如CRM、ERP、單點登錄系統、用戶權限信息等
知識庫需求: 知識的來源、具體格式、采集、清洗、結構化、標簽化、版本控制、權限管理、更新機制、檢索效率、召回率、準確率等
非功能需求: 性能（并發數、響應時間）、可用性（易用性、UI/UX）、安全性（數據加密、訪問控制、合規性）、可擴展性、可維護性
AI模型需求: 模型適配（除了已經適配的模型，客戶可能采了別人的模型需要做適配）、領域微調需求（通常不做微調）、模型評估指標、持續學習能力（badcase優化、抓取實時數據、數據集持續優化）
產出: 詳細需求規格說明書、用例、需求調研報告，這部分的內容是非常寶貴的，在深入客戶現場調研清楚需求后，后續可以抽象需求形成產品的標準化功能，推廣至更多客戶

系統架構與功能設計如圖，我們需要對整個產品的架構進行設計，包括你后續的計劃（最終要做成的樣子），示例圖中因為有后續建設Agent的部分，僅給大家做個參考

架構設計: 知識庫系統架構、集成接口設計。
AI模型設計: 領域詞典、意圖分類、實體抽取、對話管理策略、知識表示（如有知識圖譜）。
知識庫設計: 知識分類體系、元數據標準、知識圖譜Schema設計（如果有）。
UI/UX設計: Agent交互界面、知識庫管理后臺界面。
產出: 系統架構設計文檔、數據庫設計文檔、接口設計文檔、UI/UX設計稿。

數據埋點規劃“沒有測量，就沒有優化” ，有數據才能知道如何優化，所以有數據是必須的。前面拆解完指標，在設計整體方案時產品經理還需要設計數據采集方案且融入到知識庫本身的解決方案中，后期給客戶、給研發做宣貫。
需要采集的數據：

后端日志：每次請求的用戶ID、問題、時間戳、召回的知識源、生成的答案、響應時長等。
前端埋點：用戶點擊了哪個入口、會話開始/結束時間、是否點擊“贊/踩”、是否復制了答案、是否在得到答案后很快關閉了窗口。
用戶主動反?。涸諉扛齟鳶負筇峁┟魅返姆蠢“磁ィㄈ?\uD83D\uDC4D/\uD83D\uDC4E ，或“已解決”/“未解決”）。
離線評估數據：建立人工評測流程，定期抽樣問題進行“準確性”、“相關性”等維度的打分。

知識庫構建知識庫構建流程整個知識庫建設的流程如下，他是屬于我們解決方案的一個部分，能夠大大提升通用領域大模型在專有領域的落地效果和可靠性，降低模型幻覺。

數據收集:從多源（文檔、FAQ、數據庫、API）收集知識，為后續進行清洗、抽取、轉換、標注做準備，通常數據來源以下渠道：

對于在線系統：編寫腳本，利用API定期拉取更新的文檔。不過同時需要注意處理權限問題。
對于文件服務器：編寫腳本（如Python的os和shutil庫），定期掃描指定文件夾，同步新增或修改的文件。
對于數據庫：編寫SQL查詢，從業務數據庫中導出結構化的知識（如FAQ對）。
手動上傳：為無法自動采集的零散文件（如郵件附件、本地Word），提供一個統一的知識管理后臺上傳入口（前面推薦的平臺都會有這個入口）。

注意事項：

忽視數據源的動態性：未建立自動化同步機制，導致知識庫信息嚴重滯后于源頭。
低估非文本內容的處理難度：對于掃描件、圖片、復雜表格，若沒有合適的OCR或版面分析方案，會造成大量關鍵信息丟失。

規劃知識庫結構良好的結構便于后續的權限管理和應用調用，在項目中，通常需要客戶的業務專家支持一起規劃結構。

按業務領域：如“產品知識庫”、“HR政策知識庫”、“銷售話術知識庫” 。
按數據敏感度：如“公開信息知識庫”、“內部核心知識庫” 。
按部門：如“市場部資料庫”、“研發部文檔庫” 。

格式轉換及初步清洗:【一篇看懂：企業RAG知識庫項目的全生命周期設計】1）清理格式：在上傳前，手動打開Word/PDF文檔，刪除不必要的頁眉頁腳、封面、目錄。修正文檔中的錯別字和格式錯誤。
2）優化結構：對于長文檔，盡量使用清晰的標題層級（如Word的標題1 標題2）。這能幫助平臺的自動分段功能更好地理解文檔結構。
3）轉換格式：如果平臺對某些格式（如掃描版PDF）支持不佳，需要在平臺之外先用OCR工具將其轉換為純文本或格式化的Word文檔。
4）圖文處理：有些復雜文檔不光格式復雜，甚至還有圖文同時存在的情況，圖片的處理跟文字相比會麻煩點，可能涉及的方法有以下三種：

OCR提取圖中文字：調用OCR服務，獲取圖片中的所有文字
圖像描述生成：將圖片輸入到這些模型中，讓模型生成一段描述性文字
上下文關聯描述 (實際工作中最有效)：緊鄰圖片上方和下方的文本段落，切片時與圖片切分到一個chunk里

數據去重對清洗后的文檔內容或初步切分的chunk進行哈希計算，去除完全重復的部分。這一步成本低，效益高，建議先做。
哈希檢測：通過計算文本的哈希值（如MD5 SHA256），將文本映射為唯一的、定長的指紋，從而實現快速、精準的內容比對。

精確切分不同的文本類型切分的策略也不一樣，針對性設計切分的方式
1）固定長度切分：最基礎，但容易割裂語義。通常配合重疊（Overlap）來緩解（也就是每一個片段的開頭和結尾跟上下切片有重疊）。
2）遞歸/分隔符切分：更智能，優先尋找自然的語義邊界（如段落、句子）進行切分，是目前的主流方法。
3）語義切分：基于Embedding向量的相似度來判斷語義連貫性，效果更佳但計算成本更高。
4）元數據附加：為每個chunk打上豐富的“標簽”信息（來源、標題、日期、類別）。
5）注意事項：

“One-Size-Fits-All”的切分策略：對不同類型（如代碼、財報、對話記錄）的文檔使用相同的切分參數，效果一般都不行。
Chunk尺寸的極端化：切分太小，導致上下文信息不足， LLM難以理解；切分太大，導致包含過多無關噪聲，降低了檢索的信噪比。
索引方式：通常是平臺默認的向量索引，但FastGPT等平臺還支持全文索引，可以開啟以增強關鍵詞匹配能力。

文本補全/內容增強原始知識可能很簡潔或缺乏上下文，很可能導致后續召回率低，所以針對這種情況就要單獨做文本補全和內容增強。
1）假設性問題生成：利用LLM為知識“答案”反向生成多個可能的“問題” ，極大地擴展了召回的入口。
2）內容摘要與關鍵詞提?。豪肔LM生成精煉的摘要作為原文的補充或元數據，增強語義表示。
3）注意事項：

LLM生成內容的質量失控：未對LLM的生成進行有效約束（通過Prompt Engineering），可能導致生成的問題與原文偏離，引入噪聲。
成本與收益失衡：對知識庫中的所有內容都進行LLM增強，成本極高。應考慮優先對高價值、查詢頻率高的知識進行增強。

索引入庫如果使用的是在線平臺，通常會自動對數據進行入庫，若自己搭建可以參考下列方法：
1）向量數據庫選型：根據數據規模、并發需求、運維能力和成本，選擇合適的向量數據庫（如Milvus Qdrant Pinecone等）。
2）索引構建：在數據庫中選擇并配置合適的索引算法（如HNSW IVF-PQ），在檢索速度和準確率之間取得平衡。
3）批量寫入：采用批量方式將數據寫入數據庫，以獲得最佳的寫入性能。
4）注意事項/關鍵陷阱：

索引配置與應用場景不匹配：例如，對需要100%精確召回的場景使用了犧牲精度的近似索引。
元數據索引缺失：未對附加的元數據字段（如日期、類別）創建索引，導致基于這些條件的過濾查詢速度極慢，無法在生產環境中使用。
忽視可擴展性：初期選擇了無法水平擴展的輕量級方案，當數據量和用戶量增長時，系統性能迅速成為瓶頸。

知識庫項目常見問題AI知識庫（尤其是在 RAG 檢索增強生成框架中）在應用和落地過程中存在一些痛點，比如：
另外還要注意：在企業環境中，不同部門、不同級別的員工能看到的知識是不同的。數據安全和權限隔離是B端產品的紅線。比如普通員工看到了公司財務機密；銷售A組看到了銷售B組的客戶資料。產品設計之初就要深度集成企業的權限體系（如LDAP/AD域）。在知識入庫時就要打上權限標簽，在檢索和生成時進行嚴格的權限過濾，確保用戶只能看到其權限范圍內的信息。

評測我們將測試與優化分為兩大核心指標：召回率和準確性。這兩個指標有時會相互制約，優化的過程就是在它們之間找到最佳平衡。

檢索召回率對于一個用戶問題，系統能否從知識庫中找到所有相關的知識片段。召回率低是“答非所問”或“我不知道”的首要原因。
1）構建測試集
與業務專家合作，手動創建一份高質量的測試集（建議至少100-200個問題）。最關鍵的是，對于每個問題，需要人工標注出它在知識庫中對應的正確答案源（一個或多個文檔/知識片段ID）。
2）離線批量評測
編寫一個評測腳本，遍歷測試集中的所有問題。對于每個問題，只執行檢索步驟，而不進行生成。記錄下系統實際召回的知識片段ID列表。
3）失敗案例分析
找出所有召回率低（<100%）的問題，進行人工分析，歸類失敗原因。
優化方案

一：優化知識切分
問題表現：一個完整的答案被切分到兩個不相鄰的chunks里，導致只能召回其中一個。
優化方案：
調整Chunk Size和Overlap：增加chunk_overlap ，讓上下文信息在相鄰chunks之間有更多重疊。適當增大chunk_size ，但要注意不要引入太多噪聲。
調整切分方法：從固定長度切分切換到語義切分或按標題結構切分，確保語義單元的完整性。
二：Query重寫
同義詞擴展：識別出Query中的關鍵詞，并用同義詞詞典將其擴展。
子問題分解：對于復雜問題，讓LLM將其分解為多個更簡單的子問題，然后對每個子問題分別進行檢索。
歷史對話融合：在多輪對話中，用戶的后續問題往往省略了上下文。需要將當前問題與歷史對話內容結合，生成一個完整的、無歧義的新問題。
LLM生成式重寫：讓LLM根據用戶的原始問題，先生成一個它想象中的“完美答案”（一個假設性文檔）。然后，不用這個生成的答案，而是將這個假設性文檔進行向量化，用它的向量去知識庫里搜索最相似的真實文檔。
三：更換或微調Embedding模型
對于特定領域的術語或近義詞，當前Embedding模型無法準確理解其相似性。：查閱MTEB排行榜，選擇一個在你的語言和領域上表現更好的預訓練模型。
微調 (Fine-tuning)：如果預算和數據充足，可以基于你自己的數據（特別是badcase）對Embedding模型進行微調，讓它更懂行業術語。
四：采用混合檢索（多路召回）
向量檢索：強大的語義理解能力，能處理同義詞、近義詞和不同措辭。
稀疏向量/關鍵詞檢索精準匹配關鍵詞，對于包含專業術語、產品型號、人名的查詢非常有效。
圖譜檢索：如果你的知識庫構建了知識圖譜，可以直接查詢實體及其關系。
結構化數據查詢：直接查詢數據庫中的表格數據。

答案相關性在“找對”的基礎上，評估排序模型（Re-ranker）“排得好不好” 。它是否把最相關的“關鍵證物”放在了最前面，供LLM優先“審閱”

歸一化折損累計增益
檢索出的文檔與問題的相關程度（可以由人工標注，如：非常相關=3 ，相關=2 ，不相關=1）。越靠前的結果權重越高。
對比分析 (A/BTest)
將經過Re-ranker排序后的上下文，和未經排序的上下文，分別喂給同一個LLM生成答案。然后由人工判斷，哪一組生成的答案質量更高。這是一種非常直觀的端到端評測方法，能直接體現Re-ranker帶來的價值。

問答準確率在召回了相關信息的前提下， LLM最終生成的答案是否正確、忠實于原文且沒有幻覺
端到端（End-to-End）評測
使用“黃金測試集” ，但這次運行完整的“檢索+生成”流程，獲取最終的AI回答。
人工評估 (Human Evaluation)：這是目前最可靠的準確性評估方式。邀請評估員（最好是業務專家）對每個回答，從以下幾個維度進行打分（例如1-5分制）：

忠實度 (Faithfulness)：答案是否完全基于提供的上下文？有沒有捏造信息（幻覺）？
答案準確性 (Answer Correctness)：答案本身的事實是否正確？
完整性 (Completeness)：答案是否全面地回答了用戶的問題？
簡潔性 (Conciseness)：答案是否簡潔明了，沒有多余的廢話？

自動化評估
操作：對于大規模測試，可以借助自動化評估框架，如 RAGAS 。 RAGAS可以計算出一些量化指標，作為人工評估的補充。
RAGAS核心指標：

Faithfulness：通過LLM判斷答案是否忠于上下文。
Answer Relevancy：答案與問題的相關性。
Context Precision：檢索到的上下文的相關性。
Answer Correctness：答案與標準答案（ground truth）的語義相似度。

1.優化Prompt (最直接有效)
加強上下文控制：在Prompt中用更強硬的措辭（如“禁止”、“絕不允許”）來約束LLM ，強制它只使用提供的上下文。
明確降級策略：清晰地告訴LLM ，當知識不足時應該如何回應（例如，回復“我不知道”）。
使用Few-Shot示例：提供一兩個高質量的“問題-上下文-完美回答”的示例，讓LLM模仿。
2.調整檢索參數 (Top-K & Score Threshold)
調整Top-K：減小K值（例如從5減到3），只將最相關的幾個知識片段提供給LLM ，減少噪聲。
設置相似度閾值：過濾掉那些雖然在Top-K內，但本身相關性得分就不高的chunks 。
3.更換或優化LLM
不同的LLM在遵循指令和邏輯推理能力上有巨大差異。通常，更強大的模型（如GPT-4 Claude 3 Opus）能更好地理解和總結上下文，從而提高準確性。
微調 (Fine-tuning)：對于需要遵循特定、復雜格式或邏輯的場景，可以考慮對生成模型進行微調。但這是最后的手段，成本較高。

進階建設落地還缺失了什么？僅做知識庫其實還有很大的局限，真實業務場景中的問題往往是復雜的、多輪的、需要澄清的，而不是簡單的“一問一答” 。用戶問“A項目的方案和B項目的預算對比如何？” ，簡單的知識庫無法處理這種需要整合多個信息點的復雜查詢。這就需要引入Agent的概念。設計能夠拆解復雜問題、規劃執行步驟、甚至在信息不足時主動向用戶追問的智能體，將知識庫從一個被動的“數據庫”變成一個主動的“工作助理” 。

場景擴展知識庫和Agent是相輔相成的，有了專業性的知識，又有了更合適的思考方式，生成的內容采用率會大大提升。我們可以一起看看都有什么場景可以讓我們落地，最大化利用知識庫：

智能客服 / 企業內問答機器人：客戶/員工的大量重復性問題，耗費人力，響應不及時；
領域專家助理：銷售、法務、研發等專業人員，需要快速從海量資料中找到精準信息來支持工作；
報告/文案自動生成：撰寫周報、專業性報告、會議紀要、營銷文案等格式化文檔，費時費力；
競品情報智能分析：市場信息龐雜，人工分析競品動態和用戶反饋效率低、不全面；
合同/標書風險審查：人工審查上百頁的合同或標書，容易遺漏關鍵風險點；
復雜工單/故障歸因分析：復雜的系統故障，需要資深工程師查閱大量日志和文檔才能定位根因；

那么在Agent搭建上我們要關注什么？

意圖識別意圖識別是非常重要的，大模型只有理解了用戶需要的是什么，才能更好的回答，借助agent的思考規劃能力，能夠將落地回答采納率大大提升。
方法一：基于關鍵詞與規則
預先定義一套關鍵詞或正則表達式規則。將每個規則與一個特定的意圖（或工具）綁定。當用戶輸入時，用這些規則去匹配。匹配成功，則觸發對應的意圖。
方法二：傳統NLU分類模型
為每個意圖，收集并標注大量的用戶語料。使用這些標注好的數據，訓練一個文本分類模型，當用戶輸入時，用訓練好的模型來預測其最可能的意圖類別。
方法三：基于LLM的零/少樣本分類
設計一個Prompt ，將用戶輸入和所有意圖的描述一起發給LLM ，讓LLM來判斷用戶輸入最符合哪個意圖。無需訓練數據，迭代極快：增加一個新意圖，只需要在Prompt的工具列表中增加一項描述即可，極大地提升了靈活性。

工具實現與封裝首先要準備好有哪些是需要在智能體中調用的工具，比如數據庫查詢能力、天氣日期查詢等。主要有兩種方法， Function call和MCP ，如何選擇？

如果你的項目工具集相對穩定，對安全性和穩定性要求極高，優先選擇Function Calling 。
如果你的項目需要頻繁地增刪工具，或者你想在自己的小模型上快速實現工具調用能力，或者你的目標是部署在端側設備上， MCP是一個非常值得考慮的、更輕量靈活的方案。

Function call
這個方式就像是給工具設計一個精確的API接口

精準、可控、安全：因為函數和參數都是你預先嚴格定義的，模型只能在你的“白名單”里做選擇，不會胡亂調用。
復雜參數支持：能處理復雜的、結構化的參數，如嵌套的JSON對象。
主流支持： OpenAI、Google Gemini等主流模型API都原生支持，使用方便。
不夠靈活：每次新增或修改工具，都需要重新定義Schema并修改代碼，不夠靈活。
依賴模型能力：強依賴大模型自身的工具調用意圖識別能力。

MCP
直接用自然語言描述你的工具，就像寫一份簡單的說明文檔。

極其靈活：增刪改查工具，只需要修改“說明文檔”文本即可，無需修改代碼和復雜的Schema 。
輕量高效：對于小模型（如端側模型）非常友好，因為其實現方式更簡單，開銷更小。
符合直覺：用自然語言描述工具，更符合人的思維習慣。
安全性、可控性稍弱：因為是弱結構化的，理論上模型輸出的格式可能會有偏差（雖然MCP通過校準技術很大程度上解決了這個問題）。
復雜參數處理能力：對于深層嵌套的復雜參數，可能不如JSON Schema那樣明確和穩定。
生態和標準化：目前主要是MiniCPM系列模型在主推，生態和標準化程度不如Function Calling 。

提示詞撰寫產品經理和用戶撰寫的提示詞最大的不同，就是有沒有“目標” 。作為產品，寫出來的提示詞一定是能夠解決問題、可定位、可優化的，所以我們的提示詞一定要遵循一定的框架，再配合高階用法實現目標，可參考如下方法：
提示詞的基本框架-RTF
RTF框架是一種非常實用、普適性極強的Prompt結構，包含Role（角色）、Task（任務）、Format（格式）。一個好的Prompt ，特別是用于復雜任務的Prompt ，一般都包含這三個要素。

R – Role (角色)：為LLM設定一個具體、專業的身份。這個身份就像給演員一個劇本，讓他能立刻進入狀態，知道該用什么樣的知識、語氣和視角來回應。
T – Task (任務)：清晰、無歧義地描述LLM需要完成的具體工作。這是Prompt的核心和骨架。
F – Format (格式)：明確規定LLM輸出結果的結構、樣式和組織方式。

這是一個基礎框架，要想更好的實現目的，也要配合其他的方法比如CoT ，可以顯著提升提示詞效果。
思維鏈法（CoT）
強迫LLM將一個復雜問題分解為多個更簡單的子問題，并逐步解決。這個過程本身有助于模型更深入地思考，調動更多的計算資源來處理每一步，從而減少直接跳到錯誤結論的概率。這種方法我們在很多地方都能見到，比如manus、deep research、模型推理框架。

提升準確性：在算術、常識推理和符號推理等任務上， CoT能將LLM的準確率提升數倍。
增強可解釋性：通過閱讀LLM的“思考過程” ，我們可以理解它是如何得出結論的，這對于調試和信任AI的回答至關重要。如果過程錯了，我們能清晰地知道錯在哪里。

上下文控制法
在RAG（檢索增強生成）場景下，這是一種專門用于約束LLM行為的Prompt技術。其核心是建立一套嚴格的規則，強制LLM的回答只能來源于你提供的“上下文”（即從知識庫檢索出的信息），并定義當上下文不足時的“降級策略” 。

角色設定：首先，賦予AI一個“嚴謹”、“一絲不茍”的角色，如“你是一個精確的知識庫助手” 。
核心指令：明確指出回答必須“嚴格基于”、“完全根據”提供的上下文。
負面約束：使用強烈的否定詞匯來建立紅線。 “禁止”、“絕不允許”、“不要猜測” 。
降級策略 (Fallback)：清晰地定義當上下文信息不足時的標準回答。例如：“如果無法回答，請直接說‘我不知道’” 。這是防止AI在知識不足時強行回答的關鍵。
溯源要求：強制要求AI在回答后附上信息來源（通常在元數據中）。

Few-Shots
在向LLM提出正式任務之前，先在Prompt中給它提供幾個（通常是1到5個）完整的輸入/輸出示例，注意不要太多，太多的上下文將會影響問答時間。

作用：LLM非常擅長模式匹配和模仿。示例能讓它快速、準確地理解你期望的輸出格式、風格、甚至是復雜的任務邏輯，這通常比冗長的文字描述更有效。對于一些難以用語言清晰描述的復雜任務（如代碼轉換、特定風格的文本生成），提供示例是最佳的溝通方式。示例可以消除指令中的任何潛在歧義。
注意事項：選擇具有代表性的、高質量的示例，如果可能，包含一些邊界情況的例子。

不要期望一次就能寫出完美的Prompt 。 Prompt工程是一個不斷試錯、評估和優化的過程，以上的方法都是可以配合使用的，現在也有非常多其他的撰寫提示詞的方法，在調試提示詞時，推薦使用字節的promptpilot這個平臺，可以一邊調試一邊修改，很高效的產品。

總結知識庫應用非常廣泛，往往是企業融入AI的第一個項目，有了知識庫作為基礎，能夠不斷的在這個基礎之上設計各種不同的agent ，實現從chat到act的轉變。希望這篇文章對大家在知識庫項目上的理解有所助力。
本文由 @思敏原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash ，基于 CC0 協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。