1. 項目概述從“低代碼”到“智能體”的實踐跨越最近幾年無論是企業(yè)內(nèi)部的流程自動化還是面向用戶的智能服務(wù)對“能理解、會執(zhí)行”的智能體Agent需求越來越旺盛。但傳統(tǒng)的Agent開發(fā)往往需要開發(fā)者具備深厚的機器學(xué)習、自然語言處理功底從意圖識別、對話管理到工具調(diào)用每一步都是硬骨頭門檻高、周期長。這讓我想起了早些年企業(yè)應(yīng)用開發(fā)從“純手寫代碼”到“低代碼/無代碼平臺”的演進——核心目標都是降低技術(shù)門檻讓業(yè)務(wù)專家也能快速構(gòu)建應(yīng)用?！邦惖痛a平臺的Agent開發(fā)實踐”這個項目正是想探索這樣一條路徑我們能否借鑒低代碼平臺“拖拽組件、配置屬性、連接流程”的直觀方式來構(gòu)建一個功能實用的智能體本次分享的“文檔助手”就是這個實踐系列的第一站。它不是一個復(fù)雜的多輪對話機器人而是一個目標明確、即開即用的工具型Agent用戶上傳一份文檔比如合同、報告、產(chǎn)品手冊然后可以用自然語言提問助手能快速從文檔中找到相關(guān)信息并給出精準回答。這個場景看似簡單實則涵蓋了智能體開發(fā)的核心鏈路文檔的解析與向量化、用戶問題的語義理解、在向量數(shù)據(jù)庫中的精準檢索、以及最終基于檢索結(jié)果的答案生成。我們實踐的目標就是將這些環(huán)節(jié)模塊化、配置化讓開發(fā)者無需關(guān)心底層的模型訓(xùn)練和復(fù)雜算法只需通過清晰的界面配置知識庫、調(diào)整檢索策略、定義回答格式就能快速部署一個專屬的文檔問答機器人。接下來我將詳細拆解我們是如何設(shè)計并實現(xiàn)這個“類低代碼”化文檔助手的包括技術(shù)選型的思考、每個核心模塊的構(gòu)建細節(jié)以及在實際部署中踩過的坑和總結(jié)的經(jīng)驗。2. 整體架構(gòu)設(shè)計與核心思路拆解2.1 為什么選擇“檢索增強生成”作為技術(shù)基底在決定構(gòu)建文檔助手時我們首先面對的是技術(shù)路線的選擇。主流方案大致有三種基于規(guī)則模板的匹配、基于微調(diào)的語言模型、以及基于檢索增強生成RAG的方案。規(guī)則模板的方式靈活度太低難以應(yīng)對用戶千變?nèi)f化的提問方式而微調(diào)一個專用模型雖然效果可能更精準但需要大量的標注數(shù)據(jù)、高昂的訓(xùn)練成本以及持續(xù)的迭代維護這完全違背了我們“快速、低門檻”的初衷。因此RAG架構(gòu)幾乎成為了必然選擇。它的核心思想非常直觀當用戶提問時系統(tǒng)并不要求大語言模型LLM從自身參數(shù)中“回憶”出答案這容易導(dǎo)致幻覺或知識過時而是先從外部的知識庫即我們上傳的文檔中檢索出最相關(guān)的文本片段然后將這些片段和問題一起交給LLM讓它基于給定的上下文來組織答案。這樣一來LLM更像一個強大的信息整合與語言組織者答案的準確性和時效性完全依賴于我們提供的文檔質(zhì)量。這種架構(gòu)完美契合了文檔助手的場景——知識源明確、可控且開發(fā)重心從訓(xùn)練模型轉(zhuǎn)移到了構(gòu)建高效、準確的知識檢索系統(tǒng)。2.2 類低代碼化的核心設(shè)計哲學(xué)確定了RAG這條路我們?nèi)绾螌崿F(xiàn)“低代碼”或“類低代碼”呢我們的設(shè)計哲學(xué)是將智能體工作流中的每個關(guān)鍵環(huán)節(jié)抽象為可獨立配置的“組件”或“節(jié)點”并通過可視化的方式將它們連接起來形成完整的數(shù)據(jù)處理管道。對于文檔助手我們抽象出了以下幾個核心組件節(jié)點文檔加載與解析節(jié)點負責接收用戶上傳的各種格式文件PDF, Word, TXT, PPT等并將其轉(zhuǎn)換為純文本。文本分割節(jié)點將長文檔切割成大小適中、語義相對完整的片段Chunk。向量化嵌入節(jié)點調(diào)用嵌入模型Embedding Model將文本片段轉(zhuǎn)換為高維向量。向量存儲節(jié)點將向量和對應(yīng)的原文存儲到向量數(shù)據(jù)庫中并建立索引。檢索節(jié)點根據(jù)用戶問題將其向量化并在向量數(shù)據(jù)庫中進行相似度檢索返回Top-K個相關(guān)片段。提示詞構(gòu)建與LLM調(diào)用節(jié)點將檢索到的片段和用戶問題按照預(yù)設(shè)的提示詞模板組裝成完整的提示調(diào)用大語言模型API生成最終答案。在理想的類低代碼平臺上開發(fā)者只需要從組件庫中拖出這些節(jié)點用連線表示數(shù)據(jù)流向然后對每個節(jié)點進行屬性配置比如選擇分割策略、選擇嵌入模型、設(shè)置檢索數(shù)量K值、編寫提示詞模板而無需編寫任何膠水代碼。我們的實踐雖然初期可能還需要一些腳本但整體架構(gòu)和配置思路是完全遵循這一理念的為未來真正的可視化搭建鋪平了道路。2.3 技術(shù)棧選型背后的考量技術(shù)選型直接決定了系統(tǒng)的能力上限、開發(fā)效率和運維成本。以下是我們的核心選型及理由嵌入模型我們選擇了text-embedding-ada-002OpenAI和開源模型BGE-M3作為主要選項。選型考量是雙軌制OpenAI的API穩(wěn)定、效果公認優(yōu)秀適合快速驗證和對外服務(wù)而開源的BGE系列模型特別是BGE-M3支持多語言、長文本且可以本地部署滿足了數(shù)據(jù)隱私和成本控制的需求。在配置界面我們允許用戶根據(jù)實際情況切換。向量數(shù)據(jù)庫我們主要采用了ChromaDB。原因在于它輕量、易用可以純內(nèi)存運行也可以持久化并且與LangChain等框架集成良好非常適合原型開發(fā)和中小規(guī)模知識庫。對于企業(yè)級需要分布式、高可用的場景我們也預(yù)留了接入Milvus或Qdrant的接口。大語言模型與嵌入模型類似我們提供多模型支持。默認集成OpenAI GPT系列如gpt-3.5-turbo以保證通識理解和對話流暢性。同時也支持通過OpenAI兼容的API調(diào)用本地部署的模型如ChatGLM3、Qwen等為用戶提供靈活性。開發(fā)框架LangChain和LlamaIndex是兩個主要的備選框架。在這個項目中我們更多地借鑒了它們的核心思想但并沒有完全依賴。因為我們的目標是“低代碼化”需要更精細地控制每個環(huán)節(jié)的輸入輸出和狀態(tài)以便暴露為可配置參數(shù)。因此我們基于這些框架的底層能力如文檔加載器、文本分割器自己構(gòu)建了更簡潔、更符合配置化需求的工作流引擎。注意技術(shù)選型沒有銀彈。我們的選擇是基于“快速驗證、兼顧靈活與可控”的原則。如果你的場景對延遲極其敏感可能需要考慮更快的本地小模型如果知識庫文檔超過百萬級ChromaDB可能成為瓶頸需要評估專業(yè)的向量數(shù)據(jù)庫。3. 核心模塊實現(xiàn)與配置化細節(jié)3.1 文檔處理流水線從文件到知識片段這是知識庫構(gòu)建的起點也是最容易出錯的環(huán)節(jié)。我們將其設(shè)計為一個可配置的三步流水線。第一步文檔加載與解析我們實現(xiàn)了一個統(tǒng)一的文檔加載器根據(jù)文件后綴名自動路由到不同的解析器。PDF文件使用PyPDF2或pdfplumber。這里有個關(guān)鍵細節(jié)PyPDF2對某些復(fù)雜格式的PDF提取文字效果差而pdfplumber在提取表格和保持文字順序上更優(yōu)但速度稍慢。我們在配置中允許用戶選擇解析庫并提供了“嘗試提取頁面布局信息”的選項這對于多欄排版的學(xué)術(shù)論文至關(guān)重要。Word文檔使用python-docx庫它能很好地保留段落、標題結(jié)構(gòu)。Markdown/TXT直接讀取但會對編碼進行自動檢測和轉(zhuǎn)換。PPT使用python-pptx按幻燈片提取文本框內(nèi)容。第二步文本分割策略這是影響檢索效果的關(guān)鍵步驟。直接把整篇文檔丟進去檢索會引入大量噪聲切得太碎又會丟失上下文。我們提供了幾種可配置的分割策略固定長度重疊分割這是最常用的方法。例如設(shè)置塊大小chunk_size為500字符塊重疊chunk_overlap為50字符。重疊部分保證了語義的連續(xù)性避免一個完整的句子或概念被硬生生切斷?；诜指舴指顚τ诮Y(jié)構(gòu)清晰的文檔如Markdown可以按照“\n\n”空行、“##”二級標題等自然分隔符進行分割這樣得到的塊語義完整性更高。遞歸分割這是更智能的方法也是我們推薦的高級配置。它先嘗試用大分隔符如“\n\n”分割如果得到的塊還是太大再用小分隔符如“\n”繼續(xù)分割直到塊大小符合要求。這種方法能更好地尊重文檔的原有結(jié)構(gòu)。在配置界面用戶可以看到一個實時預(yù)覽功能上傳一份樣例文檔選擇不同的分割策略和參數(shù)下方會立即展示分割后的文本塊讓用戶直觀感受效果從而做出合適的選擇。第三步元數(shù)據(jù)附加僅僅有文本塊還不夠我們需要為每個塊附加元數(shù)據(jù)以便在檢索和回答時提供更多線索。系統(tǒng)會自動為每個塊附加以下元數(shù)據(jù)source: 文檔文件名。page(如果適用): 在PDF或Word中的頁碼。chunk_index: 該塊在文檔中的順序索引。file_type: 文檔類型。 用戶還可以在配置中定義自定義元數(shù)據(jù)字段例如“文檔所屬部門”、“生效日期”等這些信息可以在后續(xù)的檢索過濾中使用。3.2 向量化與存儲知識庫的“記憶”核心文本分割后就需要將這些文本轉(zhuǎn)換為向量一組數(shù)字并存入數(shù)據(jù)庫。嵌入模型配置我們在后臺封裝了多個嵌入模型的調(diào)用接口。配置項主要包括模型選擇下拉列表選擇text-embedding-ada-002,BGE-M3,text-embedding-3-small等。API密鑰與基地址對于OpenAI等云端模型需要填寫API密鑰對于本地部署的模型則需要填寫對應(yīng)的API基地址如http://localhost:8000/v1。批處理大小一次性發(fā)送多少文本進行向量化。太小影響效率太大可能超出模型上下文或?qū)е翧PI限流。我們根據(jù)模型特性設(shè)置了默認值如OpenAI建議512但也允許高級用戶調(diào)整。向量維度這是一個只讀展示項告訴用戶所選模型生成向量的維度如ada-002是1536維。這關(guān)系到后續(xù)向量數(shù)據(jù)庫索引的構(gòu)建。向量數(shù)據(jù)庫配置以ChromaDB為例可配置項包括持久化路徑知識庫向量數(shù)據(jù)保存在服務(wù)器的哪個目錄。默認為項目下的./chroma_db。集合名稱相當于數(shù)據(jù)庫的表名用于區(qū)分不同的知識庫項目。我們通常建議用項目名稱命名。距離函數(shù)向量相似度計算方式。最常用的是余弦相似度因為它只關(guān)注向量的方向而非大小適合文本相似度比較。我們也提供了內(nèi)積和歐氏距離選項供特定場景使用。索引參數(shù)對于大規(guī)模數(shù)據(jù)可以配置HNSW等索引算法的參數(shù)如ef_construction,M以在檢索精度和速度之間取得平衡。對于中小型知識庫數(shù)萬條以下使用默認值即可。當用戶點擊“構(gòu)建知識庫”按鈕時系統(tǒng)會依次執(zhí)行加載文檔 - 按配置分割 - 調(diào)用嵌入模型批量生成向量 - 將向量和元數(shù)據(jù)存入配置好的向量數(shù)據(jù)庫集合中。整個過程會有進度條提示。3.3 檢索與生成問答流程的組裝這是用戶提問時觸發(fā)的實時流程我們也將其模塊化。檢索節(jié)點配置檢索器類型相似度檢索最基礎(chǔ)的方式計算問題向量與知識庫所有向量的相似度返回最相似的K個片段。最大邊際相關(guān)性這是一個非常實用的高級選項。它不僅考慮片段與問題的相似度還考慮候選片段之間的多樣性。算法會優(yōu)先選擇與問題最相關(guān)的片段但同時懲罰與已選片段內(nèi)容重復(fù)的片段。這能有效避免返回一堆高度相似、信息冗余的文本塊讓答案的參考依據(jù)更全面?；谠獢?shù)據(jù)過濾允許用戶在提問前或提問時通過元數(shù)據(jù)進行篩選。例如可以配置為“只從source包含‘2024年合同’的文檔中檢索”。檢索數(shù)量即Top-K的K值。不是越大越好K太大不僅增加LLM的上下文長度和成本也可能引入不相關(guān)的噪聲。通常從5開始嘗試根據(jù)答案質(zhì)量調(diào)整。相似度閾值可以設(shè)置一個最低相似度分數(shù)低于此閾值的片段將被過濾掉不傳遞給LLM。這能有效防止在知識庫中沒有相關(guān)內(nèi)容時“硬找”一些不相關(guān)的片段導(dǎo)致答案出現(xiàn)幻覺。提示詞工程與LLM調(diào)用配置這是決定答案質(zhì)量和風格的最終環(huán)節(jié)。我們提供了一個強大的提示詞模板編輯器支持變量插值。系統(tǒng)提示詞定義助手的角色和基本行為準則。例如“你是一個專業(yè)的文檔分析助手嚴格根據(jù)提供的上下文信息回答問題。如果上下文沒有明確信息請直接說‘根據(jù)已知信息無法回答該問題’不要編造信息。”用戶提示詞模板這里定義了問題和上下文的組裝方式。一個經(jīng)典的模板如下請根據(jù)以下上下文信息回答問題。 上下文信息 {context} 問題{question} 請用中文給出清晰、準確的答案。其中{context}和{question}是系統(tǒng)變量會在運行時被替換為檢索到的文本和用戶問題。LLM參數(shù)配置模型選擇如gpt-3.5-turbo,gpt-4, 或自定義的本地模型端點。溫度控制回答的隨機性。對于文檔問答我們通常設(shè)置為較低的值如0.1以保證答案的穩(wěn)定性和事實性。最大生成長度限制答案的token數(shù)防止生成過長無關(guān)內(nèi)容。通過將這些節(jié)點和參數(shù)全部配置化一個非技術(shù)背景的業(yè)務(wù)人員完全可以通過理解每個配置項的含義我們提供了詳細的懸浮提示說明搭建出一個符合自己需求的文檔問答助手。4. 系統(tǒng)搭建與集成實踐4.1 后端服務(wù)架構(gòu)與API設(shè)計為了實現(xiàn)上述配置化功能我們需要一個穩(wěn)健的后端服務(wù)。我們采用了一種分層的微服務(wù)化思想進行設(shè)計盡管初期可能部署在單個應(yīng)用中但模塊邊界非常清晰。核心服務(wù)層知識庫管理服務(wù)提供RESTful API用于處理知識庫的創(chuàng)建、更新、刪除操作。上傳文檔、觸發(fā)向量化構(gòu)建、查看構(gòu)建狀態(tài)等請求都由該服務(wù)處理。它內(nèi)部會調(diào)用文檔處理流水線和向量化存儲模塊。問答引擎服務(wù)這是核心的查詢服務(wù)。接收用戶問題Query和指定的知識庫ID內(nèi)部執(zhí)行“檢索 - 組裝提示詞 - 調(diào)用LLM - 返回答案”的完整鏈條。為了提高響應(yīng)速度我們對嵌入模型和LLM的調(diào)用做了連接池和簡單的請求隊列管理。配置管理服務(wù)將前文提到的所有可配置項分割策略、模型參數(shù)、提示詞模板等持久化到數(shù)據(jù)庫中。每個知識庫項目都關(guān)聯(lián)一套完整的配置方案。API接口設(shè)計示例POST /api/v1/knowledge-base/創(chuàng)建知識庫接受名稱、描述等基本信息。POST /api/v1/knowledge-base/{kb_id}/files向指定知識庫上傳文件。POST /api/v1/knowledge-base/{kb_id}/build觸發(fā)知識庫向量化構(gòu)建。POST /api/v1/chat/completions問答接口。請求體包含kb_id知識庫ID、question問題、stream是否流式輸出等字段。我們特別為問答接口設(shè)計了流式輸出。當用戶提出一個復(fù)雜問題檢索和生成可能需要數(shù)秒時間流式輸出可以讓答案逐字返回極大地提升了用戶體驗感覺助手在“思考”和“打字”。技術(shù)上這依賴于對LLM API流式響應(yīng)如OpenAI的streamTrue參數(shù)的支持以及后端通過Server-Sent Events (SSE) 或 WebSocket 將數(shù)據(jù)塊實時推送給前端。4.2 前端配置界面實現(xiàn)思路類低代碼體驗的關(guān)鍵在于一個直觀的前端界面。我們使用現(xiàn)代前端框架構(gòu)建了一個單頁面應(yīng)用。項目儀表盤首頁展示所有已創(chuàng)建的文檔助手項目每個項目卡片顯示名稱、狀態(tài)、文檔數(shù)量、最后更新時間等。知識庫配置頁這是核心配置頁面采用步驟向?qū)Щ驑撕烅摰男问揭龑?dǎo)用戶完成配置。基礎(chǔ)信息設(shè)置項目名稱、描述。文檔管理文件上傳區(qū)域支持拖拽上傳列表顯示已上傳文件及其解析狀態(tài)。處理配置下拉選擇分割策略滑動條調(diào)整塊大小和重疊長度并實時預(yù)覽分割效果。模型配置分組選擇嵌入模型和LLM填寫相關(guān)API信息。提示詞配置提供兩個代碼編輯器式的文本框系統(tǒng)提示詞、用戶提示詞模板支持語法高亮和變量提示輸入{會彈出可用的變量列表如{context}。構(gòu)建與測試頁配置完成后一個明顯的“構(gòu)建知識庫”按鈕會觸發(fā)后端作業(yè)。頁面顯示實時日志流讓用戶了解構(gòu)建進度。構(gòu)建成功后頁面右側(cè)會嵌入一個簡單的聊天窗口用戶可以直接在此測試提問驗證助手效果形成“配置 - 構(gòu)建 - 測試”的閉環(huán)。4.3 實際部署與運維考量將這樣一個系統(tǒng)投入實際使用除了功能還需要考慮部署和運維的便利性。部署方式 我們提供了兩種部署方案。一體化部署使用Docker Compose將后端服務(wù)、前端靜態(tài)資源、數(shù)據(jù)庫用于存配置打包在一起。向量數(shù)據(jù)庫Chroma的數(shù)據(jù)卷掛載到本地。這種方式最適合快速原型驗證和內(nèi)部小團隊使用。一行docker-compose up -d命令即可啟動所有服務(wù)。分離式部署對于生產(chǎn)環(huán)境建議將服務(wù)拆解。前端使用Nginx托管后端API服務(wù)可以多實例部署通過負載均衡器分發(fā)向量數(shù)據(jù)庫和關(guān)系數(shù)據(jù)庫獨立部署。這提供了更好的擴展性和可靠性。資源監(jiān)控與日志我們在關(guān)鍵函數(shù)中添加了詳細的日志記錄包括文檔解析狀態(tài)、向量化耗時、檢索耗時、LLM調(diào)用耗時和Token使用量。這些日志被收集到統(tǒng)一的平臺方便排查性能瓶頸和計算成本。對于LLM API的調(diào)用我們記錄了每次問答的請求和響應(yīng)脫敏后用于后續(xù)分析回答質(zhì)量和優(yōu)化提示詞。監(jiān)控知識庫存儲空間設(shè)置預(yù)警防止向量數(shù)據(jù)無限增長。成本控制 使用云端LLM和嵌入模型API的主要成本是Token消耗。我們在系統(tǒng)中做了以下優(yōu)化緩存嵌入向量同一份文檔只要內(nèi)容未變其向量化結(jié)果就被持久化避免重復(fù)調(diào)用嵌入模型API。限制上下文長度通過合理的文本分割和檢索Top-K值嚴格控制送入LLM的上下文長度。用量統(tǒng)計面板在管理后臺為每個項目提供Token消耗的統(tǒng)計圖表幫助用戶了解成本分布。5. 常見問題、排查技巧與優(yōu)化心得在實際開發(fā)和用戶反饋中我們積累了大量“踩坑”經(jīng)驗。這里分享一些最具代表性的問題和解決方案。5.1 檢索效果不佳答非所問或找不到答案這是最常見的問題根源通常不在LLM而在檢索環(huán)節(jié)。問題現(xiàn)象助手回答的內(nèi)容與文檔無關(guān)或者直接說“找不到答案”但明明文檔里有相關(guān)信息。排查與解決檢查文本分割這是首要懷疑對象。如果塊太大會包含太多無關(guān)信息稀釋了關(guān)鍵內(nèi)容的向量表示如果塊太小可能把一個完整的概念切碎。實操心得對于技術(shù)文檔或合同按章節(jié)或標題分割效果最好對于普通文章嘗試用遞歸分割并預(yù)覽分割后的前幾個塊看是否保持了語義完整。檢查檢索策略嘗試將檢索器從“相似度檢索”切換到“MMR”。MMR能有效提升答案的綜合性。同時適當增加Top-K值比如從5調(diào)到8給LLM更多參考材料。檢查問題重寫用戶的提問方式可能很口語化或簡略與文檔中嚴謹?shù)谋硎霾黄ヅ洹Ｎ覀円肓艘粋€“查詢理解”或“問題重寫”環(huán)節(jié)。在檢索前先用LLM對原始問題進行一次輕量級的改寫或擴展。例如用戶問“怎么退款”系統(tǒng)可以將其重寫為“請說明退款政策、退款流程和退款所需時間”。這個改寫后的查詢再用于向量檢索效果會顯著提升。檢查嵌入模型不同的嵌入模型對同一文本的向量化結(jié)果差異很大。如果你主要處理中文文檔但使用了針對英文優(yōu)化的嵌入模型效果可能打折。務(wù)必選擇與文檔語言匹配的模型。5.2 答案出現(xiàn)“幻覺”或編造信息這是RAG架構(gòu)要解決的核心問題但配置不當仍會發(fā)生。問題現(xiàn)象助手給出的答案部分正確但混入了文檔中不存在的信息。排查與解決強化系統(tǒng)提示詞在系統(tǒng)提示詞中必須加入強約束。我們的最佳實踐是“你必須嚴格依據(jù)提供的上下文信息回答問題。上下文信息中沒有提及的內(nèi)容你不得自行推測或編造。如果上下文信息不足以回答問題請直接回復(fù)‘根據(jù)所提供的文檔我無法找到相關(guān)信息來回答這個問題?！眴⒂靡盟菰丛谏纱鸢笗r要求LLM同時指出答案依據(jù)來自上下文的哪些片段。技術(shù)上這可以通過在提示詞模板中要求模型以特定格式如【引用1】...輸出引用來實現(xiàn)。前端收到答案后可以高亮顯示被引用的原文。這不僅能增加答案可信度也方便用戶核對。降低LLM的“溫度”將生成答案時的temperature參數(shù)調(diào)低如設(shè)為0讓模型的輸出更加確定性和保守減少“自由發(fā)揮”。5.3 處理復(fù)雜格式文檔如掃描版PDF、含大量表格的文檔效果差問題現(xiàn)象上傳掃描版PDF或復(fù)雜排版的Word后解析出的文本亂碼、順序錯亂導(dǎo)致后續(xù)檢索完全失效。排查與解決掃描版PDF必須使用OCR技術(shù)。我們集成了pytesseract調(diào)用Tesseract引擎或效果更好的商業(yè)OCR API。流程是先用pdf2image庫將PDF每一頁轉(zhuǎn)為圖片然后對每張圖片進行OCR識別。這雖然耗時但對于純圖像PDF是唯一途徑。復(fù)雜表格通用文本提取會破壞表格結(jié)構(gòu)。我們的解決方案是使用專門的庫如camelot或tabula來提取表格數(shù)據(jù)并將其轉(zhuǎn)換為結(jié)構(gòu)化的文本表示如Markdown表格。在分割時我們將一個表格作為一個獨立的文本塊進行處理以保持其完整性。文檔結(jié)構(gòu)識別對于有目錄、多級標題的文檔在解析時嘗試識別并保留標題層級信息并將其作為元數(shù)據(jù)附加到后續(xù)的文本塊上。這樣在檢索時可以優(yōu)先考慮與問題相關(guān)度高的章節(jié)下的內(nèi)容。5.4 性能優(yōu)化知識庫構(gòu)建慢問答響應(yīng)延遲高問題現(xiàn)象上傳幾百頁文檔后構(gòu)建知識庫需要幾十分鐘或者用戶提問時需要等待很久才出答案。排查與解決構(gòu)建階段并行處理文檔解析和向量化是計算密集型IO密集型任務(wù)。我們使用線程池或異步IO對多個文檔甚至多個文本塊進行并行處理充分利用多核CPU。批處理API調(diào)用向嵌入模型API發(fā)送請求時將多個文本塊組合成一個批次發(fā)送遠比逐個發(fā)送高效。需要根據(jù)API的令牌限制調(diào)整批次大小。查詢階段向量索引優(yōu)化對于ChromaDB如果數(shù)據(jù)量變大10萬條確保使用了HNSW等高性能索引并調(diào)整索引參數(shù)。緩存對常見的、重復(fù)的用戶問題可以在應(yīng)用層設(shè)置緩存直接返回之前的答案避免重復(fù)檢索和生成。LLM調(diào)用超時與重試配置合理的網(wǎng)絡(luò)超時和失敗重試機制并對LLM提供商的速率限制做適配避免因偶發(fā)性錯誤導(dǎo)致整個請求失敗。5.5 一個容易被忽略的配置細節(jié)塊重疊Chunk Overlap的設(shè)置在配置文本分割時塊重疊長度常常被隨意設(shè)置。我們的經(jīng)驗是這個值需要根據(jù)文檔類型和分割策略動態(tài)調(diào)整。對于按固定長度分割重疊長度建議設(shè)置為塊大小的10%-20%。例如塊大小為500重疊可以設(shè)為50-100。這能有效防止一個完整的句子尤其是長句被切分到兩個塊中導(dǎo)致檢索時只命中一半丟失關(guān)鍵信息。對于按分隔符分割如果分隔符是句子結(jié)束符如句號、問號重疊可以設(shè)小或為0。如果分隔符是段落空行則建議設(shè)置一定的重疊例如重疊1-2個句子以保證段落邊界的語義連貫。測試方法上傳一份典型文檔用不同的重疊值分割然后用一個跨越兩個塊邊界的問題進行測試觀察哪種設(shè)置下檢索到的兩個塊組合起來能更好地回答問題。構(gòu)建一個穩(wěn)定高效的文檔助手就像調(diào)試一臺精密儀器每一個環(huán)節(jié)的參數(shù)都可能影響最終輸出。這個“類低代碼”平臺的目標就是把調(diào)試這些參數(shù)的過程從編寫代碼、重啟服務(wù)變成在界面上點點滑塊、下拉選擇然后立刻看到效果。這種即時反饋的體驗?zāi)軜O大地提升智能體應(yīng)用的迭代效率。在下一部分的實踐中我們將探討如何將這個“文檔助手”的能力進一步擴展例如接入外部工具計算器、搜索引擎、處理多輪對話、以及實現(xiàn)更復(fù)雜的智能體工作流。