国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

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

在AI項目中分為幾種不同類型的應用，例如AI原生應用（各種端到端的平臺）、AI垂類項目（基于RAG和知識庫的行業(yè)知識庫項目、各種基于知識庫和智能體的搭建的應用）

這些項目類型中，知識庫產(chǎn)品落地是較為簡單的，所以本次從知識庫項目的起始到結(jié)束全部給大家講明白，在企業(yè)內(nèi)一個知識庫項目從部署大模型到落地輸出成果都需要哪些步驟，從接到需求到項目落地，產(chǎn)品經(jīng)理又都需要做什么？

雖然本次是以項目視角描述構(gòu)建過程，但無論是企業(yè)內(nèi)部自建團隊，還是外包給供應商，都可以遵循這套生命周期。

看完本篇文章你可以了解：

1. 如何從0-1構(gòu)建知識庫？
2. 如何提升知識庫召回率、準確率？常見問題如何定位解決？
3. 如何做數(shù)據(jù)處理？
4. 構(gòu)建知識庫后還可以在這個基礎(chǔ)上做什么？

項目構(gòu)建流程

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

方案評估

AI+知識搜索/問答是企業(yè)內(nèi)最好落地的場景之一，且價值較高，作為企業(yè)的底層建筑，通常是第一個落地，但是構(gòu)建和維護高質(zhì)量的知識庫（包括數(shù)據(jù)收集、處理、向量化、索引創(chuàng)建等）是一個成本較高的過程，所以企業(yè)通常更愿意找專業(yè)的公司完成此類工作。

業(yè)務(wù)痛點分析

不同公司在沉淀資料構(gòu)建知識庫的需求是不一樣的，首先收集企業(yè)痛點才好根據(jù)痛點需求設(shè)計方案，常見企業(yè)痛點如下

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

指標拆解

看完上面的痛點，肯定能發(fā)現(xiàn)，雖然確實有這個問題，但還是不夠準確，無法指導落地與實施。

我們產(chǎn)品經(jīng)理就是要將模糊的業(yè)務(wù)痛點轉(zhuǎn)化為清晰、可量化的業(yè)務(wù)目標與評估指標，并設(shè)定項目目標，這樣才能把一個空洞模糊的指標落地下來。

指標拆解法一：公式法

假設(shè)北極星指標是 “節(jié)省人力成本”。

節(jié)省成本 = (AI處理的會話數(shù)) * (人工處理單次會話的平均時長) * (客服時薪)

為了提升“節(jié)省成本”，你可以：

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

指標拆解法二：因素拆解法

假設(shè)北極星指標是 “用戶自助問題解決”。

為了讓用戶自助解決問題，必須滿足：

1）用戶愿意用

系統(tǒng)入口是否明顯？ -> 觸達率

2）AI能聽懂用戶的問題

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

3）知識庫里有相關(guān)知識

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

4）AI給出的答案是優(yōu)質(zhì)的

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

系統(tǒng)設(shè)計

需求細化與確認

1）細化需求：現(xiàn)在需要深入現(xiàn)場，和真正使用系統(tǒng)的一線用戶以及管理知識源的專家進行交流。細化并確認中的需求，尤其是智能問答的應用場景、對話流程、知識庫的具體內(nèi)容和結(jié)構(gòu)，設(shè)計出項目架構(gòu)。

2）開展調(diào)研：列出調(diào)研明細，雙方分別需要如何配合，原則就是根據(jù)你的目標列出你要做什么，你需要對方（客戶）什么人員、怎么配合你、提供什么資料，調(diào)研方法通常是以下這些：

（1）用戶訪談：

對象：挑選典型用戶，包括新手、專家、高頻使用者和偶爾使用者。

問題清單 (半結(jié)構(gòu)化)：準備問題提綱，觀察客戶現(xiàn)有工作流程中的問題，根據(jù)問題挖掘痛點，發(fā)現(xiàn)隱性知識和求助路徑，探索期望功能和交互方式。

（2）現(xiàn)場觀察：

內(nèi)容：如果條件允許，直接坐在用戶旁邊，觀察他們?nèi)绾喂ぷ鳌＿@能發(fā)現(xiàn)很多用戶在訪談中因習以為常而忽略的細節(jié)。

（3）問卷調(diào)查：

優(yōu)勢：當用戶群體龐大時，可以通過問卷快速收集量化數(shù)據(jù)。

內(nèi)容：可以調(diào)查最常查詢的知識類型、對當前信息查找方式的滿意度評分、最希望優(yōu)先解決的問題等。

3）收集資料：客戶各種數(shù)據(jù)都需要提供，且需要明確資料收集的方式。

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

4）數(shù)據(jù)整理：與客戶的業(yè)務(wù)專家共同設(shè)計知識結(jié)構(gòu)，定好全部數(shù)據(jù)的儲存框架、策略，否則后續(xù)的維護和查重工作也非常頭大。

5）對接方式：不同的數(shù)據(jù)對接方式是不一樣的，比如客戶有數(shù)據(jù)中臺，那我們直接對接數(shù)據(jù)中臺，客戶紙質(zhì)文件是需要落地轉(zhuǎn)為電子文件的。

需求驗證

1）數(shù)據(jù)范圍界定：明確知識來源，如內(nèi)部Wiki、PDF/Word文檔庫、數(shù)據(jù)庫、付費外采的行業(yè)報告等。

2）POC產(chǎn)品選擇：市面上可以選擇的知識庫、智能體搭建產(chǎn)品有 fastgpt、n8n、coze、dify、AppBuilder等等，后續(xù)會專門出一篇關(guān)于產(chǎn)品評測選擇的文章。

3）技術(shù)路徑：

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

判斷是否需要微調(diào)：微調(diào)的成本是非常高的，判斷方式主要基于以下幾點

1）數(shù)據(jù)模塊

-數(shù)據(jù)偏移：微調(diào)提供的數(shù)據(jù)和模型原始數(shù)據(jù)差異過大，模型在新任務(wù)上表現(xiàn)反而不會好

-數(shù)據(jù)質(zhì)量差：微調(diào)需標注準確、覆蓋全面，噪聲數(shù)據(jù)會大大影響模型性能

2）訓練模塊

-過擬合：訓練方式不當或者數(shù)據(jù)量不夠，泛化能力下降，過度專注單一任務(wù)

-數(shù)據(jù)遺忘：訓練可能導致原預訓練數(shù)據(jù)被遺忘，所以一定要選擇合適匹配的模型進行訓練

3）成本模塊

-人力/時間成本：微調(diào)需足夠高質(zhì)量數(shù)據(jù)（如數(shù)千條標注數(shù)據(jù)），項目預算是否可以覆蓋

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

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

需求詳細定義

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

系統(tǒng)架構(gòu)與功能設(shè)計

如圖，我們需要對整個產(chǎn)品的架構(gòu)進行設(shè)計，包括你后續(xù)的計劃（最終要做成的樣子），示例圖中因為有后續(xù)建設(shè)Agent的部分，僅給大家做個參考

• 架構(gòu)設(shè)計: 知識庫系統(tǒng)架構(gòu)、集成接口設(shè)計。
• AI模型設(shè)計: 領(lǐng)域詞典、意圖分類、實體抽取、對話管理策略、知識表示（如有知識圖譜）。
• 知識庫設(shè)計: 知識分類體系、元數(shù)據(jù)標準、知識圖譜Schema設(shè)計（如果有）。
• UI/UX設(shè)計: Agent交互界面、知識庫管理后臺界面。
• 產(chǎn)出: 系統(tǒng)架構(gòu)設(shè)計文檔、數(shù)據(jù)庫設(shè)計文檔、接口設(shè)計文檔、UI/UX設(shè)計稿。

數(shù)據(jù)埋點規(guī)劃

“沒有測量，就沒有優(yōu)化”，有數(shù)據(jù)才能知道如何優(yōu)化，所以有數(shù)據(jù)是必須的。前面拆解完指標，在設(shè)計整體方案時產(chǎn)品經(jīng)理還需要設(shè)計數(shù)據(jù)采集方案且融入到知識庫本身的解決方案中，后期給客戶、給研發(fā)做宣貫。

需要采集的數(shù)據(jù)：

• 后端日志：每次請求的用戶ID、問題、時間戳、召回的知識源、生成的答案、響應時長等。
• 前端埋點：用戶點擊了哪個入口、會話開始/結(jié)束時間、是否點擊“贊/踩”、是否復制了答案、是否在得到答案后很快關(guān)閉了窗口。
• 用戶主動反饋：在每個答案后提供明確的反饋按鈕（如 ??/??，或“已解決”/“未解決”）。
• 離線評估數(shù)據(jù)：建立人工評測流程，定期抽樣問題進行“準確性”、“相關(guān)性”等維度的打分。

知識庫構(gòu)建

知識庫構(gòu)建流程

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

數(shù)據(jù)收集:

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

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

注意事項：

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

規(guī)劃知識庫結(jié)構(gòu)

良好的結(jié)構(gòu)便于后續(xù)的權(quán)限管理和應用調(diào)用，在項目中，通常需要客戶的業(yè)務(wù)專家支持一起規(guī)劃結(jié)構(gòu)。

• 按業(yè)務(wù)領(lǐng)域：如“產(chǎn)品知識庫”、“HR政策知識庫”、“銷售話術(shù)知識庫”。
• 按數(shù)據(jù)敏感度：如“公開信息知識庫”、“內(nèi)部核心知識庫”。
• 按部門：如“市場部資料庫”、“研發(fā)部文檔庫”。

格式轉(zhuǎn)換及初步清洗:

1）清理格式：在上傳前，手動打開Word/PDF文檔，刪除不必要的頁眉頁腳、封面、目錄。修正文檔中的錯別字和格式錯誤。

2）優(yōu)化結(jié)構(gòu)：對于長文檔，盡量使用清晰的標題層級（如Word的標題1, 標題2）。這能幫助平臺的自動分段功能更好地理解文檔結(jié)構(gòu)。

3）轉(zhuǎn)換格式：如果平臺對某些格式（如掃描版PDF）支持不佳，需要在平臺之外先用OCR工具將其轉(zhuǎn)換為純文本或格式化的Word文檔。

4）圖文處理：有些復雜文檔不光格式復雜，甚至還有圖文同時存在的情況，圖片的處理跟文字相比會麻煩點，可能涉及的方法有以下三種：

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

數(shù)據(jù)去重

對清洗后的文檔內(nèi)容或初步切分的chunk進行哈希計算，去除完全重復的部分。這一步成本低，效益高，建議先做。

哈希檢測：通過計算文本的哈希值（如MD5, SHA256），將文本映射為唯一的、定長的指紋，從而實現(xiàn)快速、精準的內(nèi)容比對。

精確切分

不同的文本類型切分的策略也不一樣，針對性設(shè)計切分的方式

1）固定長度切分：最基礎(chǔ)，但容易割裂語義。通常配合重疊（Overlap）來緩解（也就是每一個片段的開頭和結(jié)尾跟上下切片有重疊）。

2）遞歸/分隔符切分：更智能，優(yōu)先尋找自然的語義邊界（如段落、句子）進行切分，是目前的主流方法。

3）語義切分：基于Embedding向量的相似度來判斷語義連貫性，效果更佳但計算成本更高。

4）元數(shù)據(jù)附加：為每個chunk打上豐富的“標簽”信息（來源、標題、日期、類別）。

5）注意事項：

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

文本補全/內(nèi)容增強

原始知識可能很簡潔或缺乏上下文，很可能導致后續(xù)召回率低，所以針對這種情況就要單獨做文本補全和內(nèi)容增強。

1）假設(shè)性問題生成：利用LLM為知識“答案”反向生成多個可能的“問題”，極大地擴展了召回的入口。

2）內(nèi)容摘要與關(guān)鍵詞提?。豪肔LM生成精煉的摘要作為原文的補充或元數(shù)據(jù)，增強語義表示。

3）注意事項：

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

索引入庫

如果使用的是在線平臺，通常會自動對數(shù)據(jù)進行入庫，若自己搭建可以參考下列方法：

1）向量數(shù)據(jù)庫選型：根據(jù)數(shù)據(jù)規(guī)模、并發(fā)需求、運維能力和成本，選擇合適的向量數(shù)據(jù)庫（如Milvus, Qdrant, Pinecone等）。

2）索引構(gòu)建：在數(shù)據(jù)庫中選擇并配置合適的索引算法（如HNSW, IVF-PQ），在檢索速度和準確率之間取得平衡。

3）批量寫入：采用批量方式將數(shù)據(jù)寫入數(shù)據(jù)庫，以獲得最佳的寫入性能。

4）注意事項/關(guān)鍵陷阱：

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

知識庫項目常見問題

AI知識庫（尤其是在 RAG 檢索增強生成框架中）在應用和落地過程中存在一些痛點，比如：

另外還要注意：在企業(yè)環(huán)境中，不同部門、不同級別的員工能看到的知識是不同的。數(shù)據(jù)安全和權(quán)限隔離是B端產(chǎn)品的紅線。 比如普通員工看到了公司財務(wù)機密；銷售A組看到了銷售B組的客戶資料。產(chǎn)品設(shè)計之初就要深度集成企業(yè)的權(quán)限體系（如LDAP/AD域）。在知識入庫時就要打上權(quán)限標簽，在檢索和生成時進行嚴格的權(quán)限過濾，確保用戶只能看到其權(quán)限范圍內(nèi)的信息。

評測

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

檢索召回率

對于一個用戶問題，系統(tǒng)能否從知識庫中找到所有相關(guān)的知識片段。召回率低是“答非所問”或“我不知道”的首要原因。

1）構(gòu)建測試集

與業(yè)務(wù)專家合作，手動創(chuàng)建一份高質(zhì)量的測試集（建議至少100-200個問題）。最關(guān)鍵的是，對于每個問題，需要人工標注出它在知識庫中對應的正確答案源（一個或多個文檔/知識片段ID）。

2）離線批量評測

編寫一個評測腳本，遍歷測試集中的所有問題。對于每個問題，只執(zhí)行檢索步驟，而不進行生成。記錄下系統(tǒng)實際召回的知識片段ID列表。

3）失敗案例分析

找出所有召回率低（<100%）的問題，進行人工分析，歸類失敗原因。

優(yōu)化方案

一：優(yōu)化知識切分

問題表現(xiàn)：一個完整的答案被切分到兩個不相鄰的chunks里，導致只能召回其中一個。

優(yōu)化方案：

調(diào)整Chunk Size和Overlap：增加chunk_overlap，讓上下文信息在相鄰chunks之間有更多重疊。適當增大chunk_size，但要注意不要引入太多噪聲。

調(diào)整切分方法：從固定長度切分切換到語義切分或按標題結(jié)構(gòu)切分，確保語義單元的完整性。

二：Query重寫

同義詞擴展：識別出Query中的關(guān)鍵詞，并用同義詞詞典將其擴展。

子問題分解：對于復雜問題，讓LLM將其分解為多個更簡單的子問題，然后對每個子問題分別進行檢索。

歷史對話融合：在多輪對話中，用戶的后續(xù)問題往往省略了上下文。需要將當前問題與歷史對話內(nèi)容結(jié)合，生成一個完整的、無歧義的新問題。

LLM生成式重寫：讓LLM根據(jù)用戶的原始問題，先生成一個它想象中的“完美答案”（一個假設(shè)性文檔）。然后，不用這個生成的答案，而是將這個假設(shè)性文檔進行向量化，用它的向量去知識庫里搜索最相似的真實文檔。

三：更換或微調(diào)Embedding模型

對于特定領(lǐng)域的術(shù)語或近義詞，當前Embedding模型無法準確理解其相似性。：查閱MTEB排行榜，選擇一個在你的語言和領(lǐng)域上表現(xiàn)更好的預訓練模型。

微調(diào) (Fine-tuning)：如果預算和數(shù)據(jù)充足，可以基于你自己的數(shù)據(jù)（特別是badcase）對Embedding模型進行微調(diào)，讓它更懂行業(yè)術(shù)語。

四：采用混合檢索（多路召回）

向量檢索 ：強大的語義理解能力，能處理同義詞、近義詞和不同措辭。

稀疏向量/關(guān)鍵詞檢索 精準匹配關(guān)鍵詞，對于包含專業(yè)術(shù)語、產(chǎn)品型號、人名的查詢非常有效。

圖譜檢索：如果你的知識庫構(gòu)建了知識圖譜，可以直接查詢實體及其關(guān)系。

結(jié)構(gòu)化數(shù)據(jù)查詢 ：直接查詢數(shù)據(jù)庫中的表格數(shù)據(jù)。

答案相關(guān)性

在“找對”的基礎(chǔ)上，評估排序模型（Re-ranker）“排得好不好”。它是否把最相關(guān)的“關(guān)鍵證物”放在了最前面，供LLM優(yōu)先“審閱”

歸一化折損累計增益

檢索出的文檔與問題的相關(guān)程度（可以由人工標注，如：非常相關(guān)=3，相關(guān)=2，不相關(guān)=1）。越靠前的結(jié)果權(quán)重越高。

對比分析 (A/BTest)

將經(jīng)過Re-ranker排序后的上下文，和未經(jīng)排序的上下文，分別喂給同一個LLM生成答案。然后由人工判斷，哪一組生成的答案質(zhì)量更高。這是一種非常直觀的端到端評測方法，能直接體現(xiàn)Re-ranker帶來的價值。

問答準確率

在召回了相關(guān)信息的前提下，LLM最終生成的答案是否正確、忠實于原文且沒有幻覺

端到端（End-to-End）評測

使用“黃金測試集”，但這次運行完整的“檢索+生成”流程，獲取最終的AI回答。

人工評估 (Human Evaluation)：這是目前最可靠的準確性評估方式。邀請評估員（最好是業(yè)務(wù)專家）對每個回答，從以下幾個維度進行打分（例如1-5分制）：

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

自動化評估

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

RAGAS核心指標：

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

1.優(yōu)化Prompt (最直接有效)

加強上下文控制：在Prompt中用更強硬的措辭（如“禁止”、“絕不允許”）來約束LLM，強制它只使用提供的上下文。

明確降級策略：清晰地告訴LLM，當知識不足時應該如何回應（例如，回復“我不知道”）。

使用Few-Shot示例：提供一兩個高質(zhì)量的“問題-上下文-完美回答”的示例，讓LLM模仿。

2.調(diào)整檢索參數(shù) (Top-K & Score Threshold)

調(diào)整Top-K：減小K值（例如從5減到3），只將最相關(guān)的幾個知識片段提供給LLM，減少噪聲。

設(shè)置相似度閾值：過濾掉那些雖然在Top-K內(nèi)，但本身相關(guān)性得分就不高的chunks。

3.更換或優(yōu)化LLM

不同的LLM在遵循指令和邏輯推理能力上有巨大差異。通常，更強大的模型（如GPT-4, Claude 3 Opus）能更好地理解和總結(jié)上下文，從而提高準確性。

微調(diào) (Fine-tuning)：對于需要遵循特定、復雜格式或邏輯的場景，可以考慮對生成模型進行微調(diào)。但這是最后的手段，成本較高。

進階建設(shè)

落地還缺失了什么？

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

場景擴展

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

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

那么在Agent搭建上我們要關(guān)注什么？

意圖識別

意圖識別是非常重要的，大模型只有理解了用戶需要的是什么，才能更好的回答，借助agent的思考規(guī)劃能力，能夠?qū)⒙涞鼗卮鸩杉{率大大提升。

方法一：基于關(guān)鍵詞與規(guī)則

預先定義一套關(guān)鍵詞或正則表達式規(guī)則。將每個規(guī)則與一個特定的意圖（或工具）綁定。當用戶輸入時，用這些規(guī)則去匹配。匹配成功，則觸發(fā)對應的意圖。

方法二：傳統(tǒng)NLU分類模型

為每個意圖，收集并標注大量的用戶語料。使用這些標注好的數(shù)據(jù)，訓練一個文本分類模型，當用戶輸入時，用訓練好的模型來預測其最可能的意圖類別。

方法三：基于LLM的零/少樣本分類

設(shè)計一個Prompt，將用戶輸入和所有意圖的描述一起發(fā)給LLM，讓LLM來判斷用戶輸入最符合哪個意圖。無需訓練數(shù)據(jù)，迭代極快：增加一個新意圖，只需要在Prompt的工具列表中增加一項描述即可，極大地提升了靈活性。

工具實現(xiàn)與封裝

首先要準備好有哪些是需要在智能體中調(diào)用的工具，比如數(shù)據(jù)庫查詢能力、天氣日期查詢等。主要有兩種方法，F(xiàn)unction call和MCP，如何選擇？

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

Function call

這個方式就像是給工具設(shè)計一個精確的API接口

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

MCP

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

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

提示詞撰寫

產(chǎn)品經(jīng)理和用戶撰寫的提示詞最大的不同，就是有沒有“目標”。作為產(chǎn)品，寫出來的提示詞一定是能夠解決問題、可定位、可優(yōu)化的，所以我們的提示詞一定要遵循一定的框架，再配合高階用法實現(xiàn)目標，可參考如下方法：

提示詞的基本框架-RTF

RTF框架是一種非常實用、普適性極強的Prompt結(jié)構(gòu)，包含Role（角色）、Task（任務(wù)）、Format（格式）。一個好的Prompt，特別是用于復雜任務(wù)的Prompt，一般都包含這三個要素。

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

這是一個基礎(chǔ)框架，要想更好的實現(xiàn)目的，也要配合其他的方法比如CoT，可以顯著提升提示詞效果。

思維鏈法（CoT）

強迫LLM將一個復雜問題分解為多個更簡單的子問題，并逐步解決。這個過程本身有助于模型更深入地思考，調(diào)動更多的計算資源來處理每一步，從而減少直接跳到錯誤結(jié)論的概率。這種方法我們在很多地方都能見到，比如manus、deep research、模型推理框架。

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

上下文控制法

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

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

Few-Shots

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

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

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

總結(jié)

知識庫應用非常廣泛，往往是企業(yè)融入AI的第一個項目，有了知識庫作為基礎(chǔ)，能夠不斷的在這個基礎(chǔ)之上設(shè)計各種不同的agent，實現(xiàn)從chat到act的轉(zhuǎn)變。希望這篇文章對大家在知識庫項目上的理解有所助力。