：企業(yè)AI知識助手的架構(gòu)選型與部署實戰(zhàn))
先交代一下背景。最近團(tuán)隊在做一個企業(yè)內(nèi)部的 AI 知識助手從最初技術(shù)驗證用的 Demo到后來真正部署到生產(chǎn)環(huán)境供業(yè)務(wù)部門使用中間遇到了不少架構(gòu)選型和部署上的問題。整個過程走完以后最大的感受是Demo 只需要證明“能跑”生產(chǎn)要考慮的則是“能穩(wěn)定、安全、可維護(hù)地一直跑”。這兩者之間有時候隔著的不只是代碼量的差距而是整個架構(gòu)思維和工程規(guī)范的落差。這篇文章會以這次實戰(zhàn)為主線完整復(fù)盤我們在企業(yè) AI 架構(gòu)選擇與部署過程中的關(guān)鍵決策、踩坑記錄和最終落地形態(tài)。內(nèi)容包括架構(gòu)選型對比、Demo 階段設(shè)計、生產(chǎn)環(huán)境改造、部署實施步驟、常見問題排查以及工程化建議。適合正在做企業(yè)級 AI 應(yīng)用落地的后端開發(fā)、架構(gòu)師、運維同學(xué)參考如果你現(xiàn)在還停留在跑通 Demo 的階段也可以提前了解后面會踩到哪些坑。1. 需求場景與核心問題先明確一下我們要做的業(yè)務(wù)企業(yè)內(nèi)部的 AI 知識助手。核心能力是通過自然語言提問讓系統(tǒng)從企業(yè)內(nèi)部文檔庫、知識庫中檢索相關(guān)內(nèi)容再由大語言模型生成回答。聽起來不復(fù)雜但實際落地時問題主要集中在幾個方面數(shù)據(jù)安全企業(yè)內(nèi)部文檔不能隨意發(fā)給外部大模型 API數(shù)據(jù)必須留在內(nèi)部。知識時效性模型訓(xùn)練數(shù)據(jù)是過去的企業(yè)知識庫是持續(xù)更新的需要做檢索增強(qiáng)。部署成本生產(chǎn)環(huán)境 GPU 資源有限不可能每個業(yè)務(wù)都單獨跑一套大模型。穩(wěn)定性生產(chǎn)環(huán)境不能因為并發(fā)請求、模型推理慢、外部依賴抖動而影響業(yè)務(wù)。可觀測性與運維Demo 階段不需要看日志、指標(biāo)生產(chǎn)環(huán)境必須能監(jiān)控、告警、排查鏈路。整個項目從需求確認(rèn)到最終上線大概經(jīng)歷了三個階段第一階段用開源模型 快速腳本搭建 Demo驗證“基于企業(yè)知識庫做問答”這件事是否可行。第二階段梳理生產(chǎn)環(huán)境約束確定 AI 架構(gòu)選型。第三階段完成生產(chǎn)部署、優(yōu)化、上線與排障。接下來按照這個時間線逐個復(fù)盤每一階段的關(guān)鍵決策。2. Demo 階段的快速驗證很多 AI 項目都是從 Demo 開始的我們也不例外。市面上大模型部署方案很多但在 Demo 階段不需要過度糾結(jié)重點是快速驗證兩條鏈路模型推理鏈路本地部署的大模型能否按預(yù)期生成穩(wěn)定的回答。知識檢索鏈路企業(yè)文檔經(jīng)過切分、向量化之后能否檢索出相關(guān)內(nèi)容。2.1 技術(shù)選型當(dāng)時我們對比了幾類方案最終選擇的是以開源模型 本地向量庫為主模型推理使用 Ollama 做本地模型部署加載開源大模型。向量化使用文本嵌入模型對知識庫文檔做向量化。向量存儲與檢索使用輕量級向量數(shù)據(jù)庫存儲向量做相似度檢索。應(yīng)用框架初期直接使用 Python 腳本串聯(lián)“檢索 生成”流程。選擇這些技術(shù)的原因很簡單它們能最快打通從文檔到問答的完整鏈路而且不需要申請外部 API 權(quán)限數(shù)據(jù)也不需要出內(nèi)網(wǎng)。2.2 Demo 的完整流程Demo 的整體流程如下把企業(yè)文檔Word、PDF、Markdown批量讀取為純文本。按一定規(guī)則切分文檔為文本塊。對每個文本塊調(diào)用嵌入模型生成向量。將向量和原文存入向量數(shù)據(jù)庫。用戶提問時將問題向量化。在向量數(shù)據(jù)庫中檢索相似度最高的文本塊。將文本塊作為上下文連同用戶問題一起拼接到 Prompt 中。調(diào)用本地大模型生成最終回答。核心代碼邏輯如下from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma from langchain_community.llms import Ollama from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 初始化 embedding 與 LLM embeddings OllamaEmbeddings(modelbge-m3) llm Ollama(modelqwen2.5:14b, temperature0.3) # 2. 切分文檔 text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50 ) chunks text_splitter.split_text(original_text) # 3. 存儲向量 vectorstore Chroma.from_texts( textschunks, embeddingembeddings, persist_directory./chroma_db ) # 4. 檢索 retriever vectorstore.as_retriever(search_kwargs{k: 5}) docs retriever.get_relevant_documents(user_question) context \n\n.join([doc.page_content for doc in docs]) # 5. 拼接 Prompt 并生成回答 prompt f請基于以下知識庫內(nèi)容回答用戶問題。 如果知識庫內(nèi)容不足以回答請明確說明。 知識庫內(nèi)容 {context} 用戶問題 {user_question} response llm.invoke(prompt) print(response)這段代碼在 Demo 階段完全沒有問題它把“文檔進(jìn)來 - 知識檢索 - 答案生成”的閉環(huán)跑通了。但如果你把它直接放到生產(chǎn)環(huán)境會遇到一系列問題。2.3 Demo 階段的明顯短板跑通 Demo 之后我們梳理了它不適合直接上生產(chǎn)的幾個原因Demo 階段做法生產(chǎn)存在的問題單機(jī)運行 Python 腳本無法提供穩(wěn)定服務(wù)無法水平擴(kuò)展每次啟動重新加載文檔文檔更新、向量增量入庫都沒有管理直接調(diào)用本地模型服務(wù)無鑒權(quán)、無限流、無并發(fā)控制日志打印在控制臺無法追蹤問題無法定位是哪一段鏈路失敗單點部署模型服務(wù)或應(yīng)用服務(wù)宕機(jī)業(yè)務(wù)直接中斷參數(shù)寫在代碼里不同環(huán)境無法隔離配置更別提灰度發(fā)布所以進(jìn)入生產(chǎn)階段之前我們重新梳理了架構(gòu)選型。3. 生產(chǎn)環(huán)境 AI 架構(gòu)選型3.1 自建大模型服務(wù)還是調(diào)用外部 API第一個要決策的問題是模型能力從哪里來。調(diào)用外部大模型 API 的優(yōu)點是開發(fā)效率高、模型能力強(qiáng)、不需要自己維護(hù) GPU 服務(wù)但對很多企業(yè)來說數(shù)據(jù)出境、隱私合規(guī)、數(shù)據(jù)安全是不可接受的硬約束。尤其知識庫內(nèi)容涉及企業(yè)內(nèi)部資料直接發(fā)給外部 API 在合規(guī)層面風(fēng)險很大。自建大模型服務(wù)的優(yōu)點是數(shù)據(jù)完全在內(nèi)部掌握可控性強(qiáng)缺點是需要 GPU 資源、需要運維模型服務(wù)、模型能力相對商業(yè) API 會弱一些。我們最終選擇了自建這條路線同時為了降低部署和運維成本使用了 Ollama 作為模型推理服務(wù)。選擇 Ollama 而不是直接用 vLLM、TensorRT-LLM 這類推理框架原因是在我們的場景下并發(fā)量不是極端高Ollama 的部署簡單、模型管理方便、API 兼容 OpenAI 格式后續(xù)替換模型也比較容易。如果你們的生產(chǎn)環(huán)境并發(fā)量很高或者對推理延遲有嚴(yán)格的要求建議調(diào)研 vLLM 等專用推理框架如果團(tuán)隊運維能力有限Ollama 或同類輕量方案也可以作為起點但要注意壓測。3.2 整體架構(gòu)分層生產(chǎn)環(huán)境架構(gòu)我們在 Demo 的單機(jī)腳本上做了分層設(shè)計整體架構(gòu)如下用戶 → 統(tǒng)一 API 網(wǎng)關(guān) → AI 應(yīng)用服務(wù) → 檢索服務(wù) → 向量數(shù)據(jù)庫 ↓ 大模型推理服務(wù)各層職責(zé)如下API 網(wǎng)關(guān)負(fù)責(zé)統(tǒng)一的入口、鑒權(quán)、限流、請求日志。AI 應(yīng)用服務(wù)負(fù)責(zé)編排“檢索 生成”流程接收請求、調(diào)用下游服務(wù)、組織返回。檢索服務(wù)對知識庫內(nèi)容做向量化、切分、檢索數(shù)據(jù)更新也由這一層管理。向量數(shù)據(jù)庫存儲文檔向量提供相似度檢索能力。大模型推理服務(wù)部署開源大模型對外提供 OpenAI 兼容的推理接口。應(yīng)用服務(wù)我們選擇了 Java Spring Boot 體系主要考慮到團(tuán)隊技術(shù)棧和后續(xù)維護(hù)成本檢索服務(wù)和向量化部分保留了 Python因為生態(tài)最成熟方便調(diào)試?？缯Z言之間通過 HTTP 接口通信。如果你不想維護(hù)兩套語言體系也可以全部使用 Java 生態(tài)比如 Spring AI 中已經(jīng)封裝了 ChatModel、EmbeddingModel、VectorStore 等抽象可以直接對接 Ollama、Chroma 等組件。兩種方案沒有絕對優(yōu)劣核心是團(tuán)隊能不能長期維護(hù)。3.3 模型部署方式選擇本地模型部署是這次架構(gòu)選型的另一個重點。我們對比了三種方案方案優(yōu)勢劣勢適用場景Ollama安裝簡單模型管理方便API 兼容 OpenAI高并發(fā)性能一般中小并發(fā)、快速交付vLLM高吞吐高并發(fā)支持連續(xù)批處理部署復(fù)雜度高顯存要求高高并發(fā)場景調(diào)用外部 API模型能力強(qiáng)免運維數(shù)據(jù)出網(wǎng)合規(guī)風(fēng)險非敏感數(shù)據(jù)場景最終選型為 Ollama 部署模型原因是我們的并發(fā)規(guī)?？煽厍蚁Ｍ诒ＷC數(shù)據(jù)安全的前提下縮短交付周期。這里補(bǔ)充一個重要經(jīng)驗不要一上來就追求最大規(guī)模的模型。先明確業(yè)務(wù)能接受的回答質(zhì)量底線和推理延遲上限再選擇模型大小。我們實際測試過 7B、14B、32B 級別的模型最終選了 14B 級別因為 7B 在專業(yè)知識問答上準(zhǔn)確率不夠32B 對 GPU 資源要求高延遲也大。生產(chǎn)環(huán)境要在質(zhì)量、成本、延遲之間找平衡。3.4 向量數(shù)據(jù)庫選型向量數(shù)據(jù)庫也做了對比。Chroma開發(fā)體驗好適合本地跑 Demo但生產(chǎn)環(huán)境的分布式和高可用能力較弱。Milvus / 開源版功能強(qiáng)支持分布式但部署和運維成本較高。其他方案如果團(tuán)隊已重度使用 Elasticsearch也可以用 ES 的向量檢索能力減少引入新組件。我們考慮到當(dāng)前知識庫數(shù)據(jù)量還在可控范圍內(nèi)先用的是輕量方案后續(xù)數(shù)據(jù)量增長再遷移至專業(yè)向量數(shù)據(jù)庫。這里的重點是向量數(shù)據(jù)庫的選型要和知識庫的數(shù)據(jù)量、更新頻率、檢索性能要求綁定不要盲目引入重組件。4. 生產(chǎn)環(huán)境部署實施4.1 整體服務(wù)拆分生產(chǎn)環(huán)境最終拆成了以下幾類服務(wù)ai-gateway # 統(tǒng)一入口鑒權(quán)、限流、路由 ai-app-server # AI 應(yīng)用編排服務(wù)Java Spring Boot ai-retrieval-server # 檢索服務(wù)Python FastAPI ai-knowledge-api # 知識庫管理接口文檔上傳、切片、向量化 vector-db # 向量數(shù)據(jù)庫 ollama-server # 大模型推理服務(wù)服務(wù)之間通過內(nèi)網(wǎng) HTTP 通信不直接暴露端口到公網(wǎng)。4.2 模型推理服務(wù)部署Ollama 在 Linux 服務(wù)器上安裝之后默認(rèn)監(jiān)聽 11434 端口。生產(chǎn)環(huán)境我們建議通過 systemd 管理并設(shè)置環(huán)境變量來控制模型加載方式。安裝命令curl -fsSL https://ollama.com/install.sh | sh啟動服務(wù)systemctl start ollama systemctl enable ollama拉取模型ollama pull qwen2.5:14b生產(chǎn)環(huán)境建議通過 systemd 環(huán)境變量配置 Ollama 的并發(fā)參數(shù)默認(rèn)并發(fā)不一定適合你的場景[Service] EnvironmentOLLAMA_NUM_PARALLEL2 EnvironmentOLLAMA_MAX_LOADED_MODELS1 EnvironmentOLLAMA_KEEP_ALIVE5m關(guān)于這幾個參數(shù)再解釋一下OLLAMA_NUM_PARALLEL表示同一個模型同時處理多少個請求。值設(shè)太高如果顯存不夠推理會變慢甚至出錯設(shè)太低時并發(fā)上來后會排隊。OLLAMA_MAX_LOADED_MODELS同時常駐顯存的模型數(shù)量。如果只有一個模型設(shè)置為 1 即可避免多個模型切換導(dǎo)致顯存反復(fù)加載。OLLAMA_KEEP_ALIVE模型在顯存中保持加載的時間。太短會導(dǎo)致頻繁冷加載響應(yīng)變慢太長會持續(xù)占顯存。按實際調(diào)用頻率調(diào)整。修改環(huán)境變量后需要重啟服務(wù)systemctl daemon-reload systemctl restart ollama4.3 應(yīng)用服務(wù) Spring Boot 接入大模型Java 應(yīng)用服務(wù)我們使用 Spring Boot 3 Spring AI 來編排調(diào)用流程。以接入 Ollama 為例spring: ai: ollama: base-url: http://ollama-server:11434 chat: model: qwen2.5:14b options: temperature: 0.3Java 代碼中調(diào)用模型import org.springframework.ai.chat.ChatClient; import org.springframework.ai.chat.messages.UserMessage; import org.springframework.ai.chat.prompt.Prompt; import org.springframework.stereotype.Service; Service public class AiChatService { private final ChatClient chatClient; public AiChatService(ChatClient chatClient) { this.chatClient chatClient; } public String chat(String userQuestion, String context) { String promptContent 請基于以下知識庫內(nèi)容回答用戶問題。 如果知識庫內(nèi)容不足以回答請明確說明。 知識庫內(nèi)容 %s 用戶問題 %s .formatted(context, userQuestion); return chatClient.call(new Prompt(new UserMessage(promptContent))) .getResult() .getOutput() .getContent(); } }如果你無法確定所使用的 Spring AI 版本是否包含上述 API請先參考對應(yīng)版本官方文檔確認(rèn)接口名。Spring AI 迭代速度較快不同版本之間 API 差異較大尤其是ChatClient的包路徑和調(diào)用方式在新版本中有過調(diào)整。4.4 檢索服務(wù)部署檢索服務(wù)我們使用 FastAPI 封裝了一組接口包含文檔向量化和相似度檢索。服務(wù)內(nèi)部仍然使用 Ollama 的 embedding 模型做向量化。from fastapi import FastAPI from pydantic import BaseModel from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma app FastAPI() embeddings OllamaEmbeddings(modelbge-m3) vectorstore Chroma( persist_directory/data/vector_store, embedding_functionembeddings ) class SearchRequest(BaseModel): question: str k: int 5 class SearchResult(BaseModel): content: str score: float app.post(/search, response_modellist[SearchResult]) def search(request: SearchRequest): docs vectorstore.similarity_search_with_score( request.question, krequest.k ) return [ SearchResult(contentdoc.page_content, scorescore) for doc, score in docs ]啟動服務(wù)時使用 Gunicorn Uvicorn 多進(jìn)程方式避免單進(jìn)程處理不了并發(fā)請求。gunicorn main:app -w 2 -k uvicorn.workers.UvicornWorker -b 0.0.0.0:8000這里需要根據(jù)服務(wù)器 CPU 核數(shù)和請求量調(diào)整-w參數(shù)。進(jìn)程數(shù)通常設(shè)為 CPU 核數(shù)的 1 到 2 倍即可不是越大越好。4.5 Docker Compose 一鍵編排為了讓整個環(huán)境可以快速復(fù)制部署我們用 Docker Compose 把應(yīng)用服務(wù)、檢索服務(wù)、向量數(shù)據(jù)庫編排到一起。Ollama 是否容器化可以根據(jù)實際情況而定如果宿主機(jī)顯存資源有限也可以直接在宿主機(jī)安裝宿主環(huán)境的管理更直接一些。一個參考的docker-compose.yml如下version: 3.8 services: ai-app-server: image: registry.internal.example.com/ai-app-server:1.0.0 ports: - 8080:8080 environment: SPRING_AI_OLLAMA_BASE_URL: http://ollama-server:11434 RETRIEVAL_SERVICE_URL: http://ai-retrieval-server:8000 depends_on: - ai-retrieval-server ai-retrieval-server: image: registry.internal.example.com/ai-retrieval-server:1.0.0 volumes: - /data/vector_store:/data/vector_store environment: OLLAMA_BASE_URL: http://ollama-server:11434 depends_on: - ollama-server ollama-server: image: ollama/ollama:latest ports: - 11434:11434 volumes: - /data/ollama:/root/.ollama environment: OLLAMA_NUM_PARALLEL: 2 OLLAMA_KEEP_ALIVE: 5m注意鏡像地址需要替換成你們自己的私有鏡像倉庫地址我這里只是一個示例。生產(chǎn)環(huán)境不建議從公網(wǎng) Docker Hub 直接拉取業(yè)務(wù)鏡像。容器啟動后docker compose up -d進(jìn)入 Ollama 容器拉取模型docker exec -it ollama-server ollama pull qwen2.5:14b docker exec -it ollama-server ollama pull bge-m34.6 知識庫初始化首次落地時我們編寫了一個初始化腳本把歷史文檔批量導(dǎo)入python scripts/init_knowledge_base.py \ --source-dir /data/docs \ --vector-dir /data/vector_store \ --chunk-size 500 \ --chunk-overlap 50腳本核心邏輯import os import glob from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.document_loaders import TextLoader from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma def load_and_split(source_dir: str, chunk_size: int, chunk_overlap: int): text_splitter RecursiveCharacterTextSplitter( chunk_sizechunk_size, chunk_overlapchunk_overlap ) docs [] for file_path in glob.glob(os.path.join(source_dir, **/*.md), recursiveTrue): loader TextLoader(file_path, encodingutf-8) docs.extend(loader.load_and_split(text_splitter)) return docs def build_vector_store(docs, vector_dir: str, model: str): embeddings OllamaEmbeddings(modelmodel) vectorstore Chroma.from_documents( documentsdocs, embeddingembeddings, persist_directoryvector_dir ) return vectorstore if __name__ __main__: docs load_and_split(/data/docs, 500, 50) build_vector_store(docs, /data/vector_store, bge-m3) print(f共導(dǎo)入文檔塊: {len(docs)})在企業(yè)真實場景中文檔格式不只 Markdown還有 PDF、Word 等需要根據(jù)實際情況開發(fā)對應(yīng)的文檔解析器。切分的 chunk_size 也需要根據(jù)文檔類型調(diào)整不要所有文檔都用同一套參數(shù)。5. 生產(chǎn)環(huán)境優(yōu)化關(guān)鍵點5.1 Prompt 與上下文管理Demo 階段的 Prompt 比較簡單生產(chǎn)環(huán)境則要更嚴(yán)格地控制 Prompt。以下是我們線上使用的版本結(jié)構(gòu)系統(tǒng)角色你是企業(yè)內(nèi)部知識助手回答必須基于提供的知識庫內(nèi)容。 約束條件 1. 如果知識庫內(nèi)容不包含答案請如實說明“未在知識庫中找到相關(guān)內(nèi)容”不要編造。 2. 回答保持簡潔、準(zhǔn)確。 3. 禁止輸出與問題無關(guān)的內(nèi)容。 知識庫內(nèi)容 {context} 用戶問題 {question}上下文控制上需要注意兩個問題。第一檢索到的文本塊不要無腦拼接超出模型上下文窗口會導(dǎo)致請求失敗或回答質(zhì)量下降。需要對檢索結(jié)果做截斷或過濾。第二如果企業(yè)文檔中存在相互矛盾的內(nèi)容Prompt 中應(yīng)要求模型指出矛盾而不是強(qiáng)行給出統(tǒng)一答案。這在多版本制度文檔場景中很常見。5.2 緩存設(shè)計相同或相似的問題如果每次都重新走一遍檢索 推理成本和延遲都很高。我們引入了一層結(jié)果緩存Service public class AnswerCacheService { private final CacheString, String answerCache Caffeine.newBuilder() .maximumSize(10000) .expireAfterWrite(Duration.ofHours(1)) .build(); public String getIfPresent(String question) { return answerCache.getIfPresent(question); } public void put(String question, String answer) { answerCache.put(question, answer); } }這里有一個關(guān)鍵點如何判斷兩個問題是否相同。我們采用了“先向量化再計算相似度”的語義緩存而不是簡單的字符串匹配。當(dāng)新問題與緩存中的問題相似度超過 0.95 時直接返回緩存結(jié)果。緩存的核心目的是降本效果非常明顯。5.3 限流與降級生產(chǎn)環(huán)境必須考慮惡意請求和突發(fā)流量。我們在 API 網(wǎng)關(guān)層做了限流基于令牌桶算法實現(xiàn)。spring: cloud: gateway: routes: - id: ai-app uri: http://ai-app-server:8080 predicates: - Path/api/ai/** filters: - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 10 redis-rate-limiter.burstCapacity: 20降級策略方面當(dāng)大模型推理服務(wù)的響應(yīng)時間超過閾值時應(yīng)用服務(wù)應(yīng)快速失敗而不是讓請求長時間掛起。同時要設(shè)計好兜底文案不能直接把模型內(nèi)部異常拋給用戶。5.4 可觀測性建設(shè)Demo 階段不需要監(jiān)控生產(chǎn)環(huán)境必須有完整的觀測體系日志應(yīng)用日志統(tǒng)一 JSON 格式輸出包含 traceId。指標(biāo)請求量、P95/P99 延遲、模型推理耗時、檢索耗時、錯誤率。鏈路追蹤跨服務(wù)調(diào)用需要 traceId 貫穿網(wǎng)關(guān)到檢索到模型推理。在 Spring Boot 中我們通過過濾器為每個請求生成 traceIdimport jakarta.servlet.Filter; import jakarta.servlet.FilterChain; import jakarta.servlet.ServletRequest; import jakarta.servlet.ServletResponse; import jakarta.servlet.http.HttpServletRequest; import org.slf4j.MDC; import org.springframework.stereotype.Component; import java.util.UUID; Component public class TraceIdFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) { try { String traceId UUID.randomUUID().toString().replace(-, ); MDC.put(traceId, traceId); chain.doFilter(request, response); } catch (Exception e) { throw new RuntimeException(e); } finally { MDC.remove(traceId); } } }日志配置中加入 traceId 字段pattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - [%X{traceId}] - %msg%n/pattern沒有可觀測性生產(chǎn)環(huán)境排查問題就像盲人摸象這個環(huán)節(jié)不能省。6. 常見問題與排查思路這次部署過程中我們積累了不少排障經(jīng)驗下面按問題類型整理。6.1 顯存不足導(dǎo)致模型加載失敗問題現(xiàn)象常見原因解決思路Ollama 報錯no space left on device或模型加載失敗顯存不足模型參數(shù)過大換用更小模型或降低并發(fā)參數(shù)推理時 OOM并發(fā)線程數(shù)過高調(diào)低OLLAMA_NUM_PARALLEL模型加載很慢KEEP_ALIVE設(shè)置太短調(diào)大OLLAMA_KEEP_ALIVE這里最直接的排查命令nvidia-smi確認(rèn) GPU 顯存占用率。如果模型本身大小接近顯存上限說明該模型不適合當(dāng)前環(huán)境。6.2 檢索結(jié)果相關(guān)性差問題現(xiàn)象常見原因解決思路回答完全沒用到知識庫內(nèi)容Prompt 中知識庫內(nèi)容未正確傳入檢查檢索服務(wù)返回的數(shù)據(jù)是否為空檢索到的文本與問題無關(guān)chunk_size 過大或過小調(diào)整切分參數(shù)專業(yè)術(shù)語檢索不到embedding 模型對領(lǐng)域詞匯理解不足更換效果更好的 embedding 模型多個文檔內(nèi)容沖突未做內(nèi)容質(zhì)量過濾從知識庫源頭清洗文檔實際調(diào)優(yōu)時可以從單條樣本開始逐步檢查檢索結(jié)果。如果檢索出來的文本塊本身就不相關(guān)再優(yōu)化 Prompt 也沒用。6.3 服務(wù)間調(diào)用超時問題現(xiàn)象常見原因解決思路應(yīng)用服務(wù)請求檢索服務(wù)超時檢索服務(wù)單進(jìn)程處理不過來增加 Gunicorn worker 數(shù)請求 Ollama 超時模型推理排隊調(diào)大OLLAMA_NUM_PARALLEL或并發(fā)過高時限流接口整體響應(yīng)慢檢索 推理串行耗時太長對相似問題做緩存排查時先把一次完整請求拆成多段計時定位耗時集中在哪個環(huán)節(jié)再針對性處理。6.4 文檔更新后檢索結(jié)果沒變化問題現(xiàn)象常見原因解決思路新文檔上傳后問答結(jié)果沒有變化向量庫沒有增量更新實現(xiàn)增量入庫邏輯刪除了舊文檔回答仍引用舊內(nèi)容舊向量未被刪除入庫時保存文檔 ID更新時先刪后插向量庫持久化目錄被重新創(chuàng)建容器重啟后掛載路徑配置錯誤檢查 volume 掛載如果向量庫和原始文檔之間沒有建立 ID 映射生產(chǎn)環(huán)境做增量更新會非常痛苦。建議文件名或文檔 ID 作為元數(shù)據(jù)寫入向量庫。7. 從 Demo 到生產(chǎn)的關(guān)鍵差異復(fù)盤最后想把這次從 Demo 到生產(chǎn)的完整過程做一個橫向總結(jié)這部分也是我認(rèn)為最值得反復(fù)看的。維度Demo 階段生產(chǎn)環(huán)境目標(biāo)驗證可行性穩(wěn)定支撐業(yè)務(wù)數(shù)據(jù)安全不關(guān)注必須合規(guī)數(shù)據(jù)不出內(nèi)網(wǎng)架構(gòu)單腳本網(wǎng)關(guān) 應(yīng)用服務(wù) 檢索服務(wù) 推理服務(wù)并發(fā)無必須壓測限流模型本地或 API 都行根據(jù)質(zhì)量、成本、延遲選型知識庫一次性導(dǎo)入增量更新ID 映射清洗可觀測性控制臺打印日志、指標(biāo)、鏈路追蹤容錯無降級、兜底、快速失敗部署本地運行容器化環(huán)境隔離配置管理安全無鑒權(quán)網(wǎng)關(guān)鑒權(quán)、內(nèi)網(wǎng)隔離、最小權(quán)限關(guān)于“AI 架構(gòu)選擇”我的核心觀點是不要為了追求新技術(shù)而引入復(fù)雜組件也不要因為團(tuán)隊熟悉某套技術(shù)棧就盲目套用。架構(gòu)選型的本質(zhì)是在約束條件下做取舍。對于大多數(shù)企業(yè)內(nèi)部 AI 應(yīng)用優(yōu)先考慮數(shù)據(jù)安全、可維護(hù)性和成本可控其次才是模型能力的極致表現(xiàn)。模型大小選擇上建議按這個步驟來先收集一批企業(yè)真實知識問答作為評測樣本。用不同規(guī)模的模型分別跑一遍。從回答準(zhǔn)確率、延遲、顯存占用三個維度打分。選一個綜合分最高的方案而不是直接上最大模型。部署方式上如果團(tuán)隊運維能力有限D(zhuǎn)ocker Compose 已經(jīng)能覆蓋中小規(guī)模場景如果后續(xù)并發(fā)增長明顯再逐步遷移到 Kubernetes 并把大模型推理層獨立出來使用 vLLM 等高性能推理框架。8. 一些可以復(fù)用的工程建議結(jié)合這次實戰(zhàn)整理一份我們團(tuán)隊后續(xù)在 AI 項目中固定使用的工程化清單。如果你即將把一個 AI Demo 推向生產(chǎn)建議逐條對應(yīng)檢查。第一配置管理從第一天就要做。不同環(huán)境開發(fā)、測試、生產(chǎn)的模型地址、數(shù)據(jù)庫地址、密鑰都不一樣。不要把配置寫死在代碼里。使用 Spring 的application-{profile}.yml或配置中心都可以關(guān)鍵是環(huán)境隔離要明確。第二所有依賴外部服務(wù)的調(diào)用都必須有超時和重試策略。這里的“外部服務(wù)”包括 Ollama、向量數(shù)據(jù)庫、檢索服務(wù)。任何一個下游服務(wù)慢都可能拖垮整個應(yīng)用。第三知識庫數(shù)據(jù)要進(jìn)行版本管理。Demo 階段可以隨便導(dǎo)入文檔生產(chǎn)環(huán)境一旦知識庫內(nèi)容更新出錯會影響所有用戶。這里建議至少做到文檔入庫前有審核流程、入庫時記錄版本號、必要時支持回滾。第四模型服務(wù)和業(yè)務(wù)服務(wù)要分開部署。把模型推理和業(yè)務(wù)邏輯放在同一臺機(jī)器同一個進(jìn)程里只適合驗證階段。模型推理依賴 GPU 資源而業(yè)務(wù)服務(wù)可能隨時擴(kuò)容縮容混部會影響穩(wěn)定性。第五壓測一定要做而且要在接近真實的數(shù)據(jù)集上做。我們當(dāng)時用 200 道真實業(yè)務(wù)問題做并發(fā)壓測時發(fā)現(xiàn)了檢索服務(wù)在并發(fā) 10 以上就開始超時的問題。如果壓測數(shù)據(jù)只用簡單問答很多問題測不出來。第六正式上線前準(zhǔn)備一份應(yīng)急預(yù)案。如果大模型服務(wù)掛了怎么辦如果知識庫向量庫損壞怎么辦如果某個文檔的內(nèi)容是錯誤信息被大量用戶檢索到怎么辦每一條都要有明確的響應(yīng)動作。9. 下一步可以繼續(xù)深入的方向如果這篇文章的讀者也希望在企業(yè) AI 方向持續(xù)深入我覺得可以從以下幾個方面繼續(xù)學(xué)習(xí)大模型推理框架深入了解 vLLM、TensorRT-LLM 的原理和使用方式適合高并發(fā)場景。檢索增強(qiáng)生成RAG包括查詢改寫、重排序Rerank、混合檢索關(guān)鍵詞 向量等進(jìn)階方向。Agent 架構(gòu)如果你希望 AI 應(yīng)用不只是“問答機(jī)器人”還要具備工具調(diào)用、多步任務(wù)規(guī)劃能力可以研究 Agent 架構(gòu)設(shè)計。AI 應(yīng)用的可觀測性標(biāo)準(zhǔn)比如如何評估生成內(nèi)容的質(zhì)量如何追蹤模型幻覺事件這些在生產(chǎn)環(huán)境一定會遇到。多模態(tài)如果后續(xù)文檔中包含圖片、掃描件需要多模態(tài)模型參與解析和生成。本文記錄的就是一次相對完整的企業(yè) AI 落地過程。不同團(tuán)隊的技術(shù)棧、資源規(guī)模、業(yè)務(wù)約束都不一樣具體方案輸出了差異但思考問題的框架——從 Demo 到生產(chǎn)的差距在哪里、每一步?jīng)Q策的取舍依據(jù)是什么——是共通的。希望這篇復(fù)盤能幫正在做類似項目的你少踩一些坑。 從Demo到生產(chǎn)：企業(yè)AI知識助手的架構(gòu)選型與部署實戰(zhàn)
先交代一下背景。最近團(tuán)隊在做一個企業(yè)內(nèi)部的 AI 知識助手從最初技術(shù)驗證用的 Demo到后來真正部署到生產(chǎn)環(huán)境供業(yè)務(wù)部門使用中間遇到了不少架構(gòu)選型和部署上的問題。整個過程走完以后最大的感受是Demo 只需要證明“能跑”生產(chǎn)要考慮的則是“能穩(wěn)定、安全、可維護(hù)地一直跑”。這兩者之間有時候隔著的不只是代碼量的差距而是整個架構(gòu)思維和工程規(guī)范的落差。這篇文章會以這次實戰(zhàn)為主線完整復(fù)盤我們在企業(yè) AI 架構(gòu)選擇與部署過程中的關(guān)鍵決策、踩坑記錄和最終落地形態(tài)。內(nèi)容包括架構(gòu)選型對比、Demo 階段設(shè)計、生產(chǎn)環(huán)境改造、部署實施步驟、常見問題排查以及工程化建議。適合正在做企業(yè)級 AI 應(yīng)用落地的后端開發(fā)、架構(gòu)師、運維同學(xué)參考如果你現(xiàn)在還停留在跑通 Demo 的階段也可以提前了解后面會踩到哪些坑。1. 需求場景與核心問題先明確一下我們要做的業(yè)務(wù)企業(yè)內(nèi)部的 AI 知識助手。核心能力是通過自然語言提問讓系統(tǒng)從企業(yè)內(nèi)部文檔庫、知識庫中檢索相關(guān)內(nèi)容再由大語言模型生成回答。聽起來不復(fù)雜但實際落地時問題主要集中在幾個方面數(shù)據(jù)安全企業(yè)內(nèi)部文檔不能隨意發(fā)給外部大模型 API數(shù)據(jù)必須留在內(nèi)部。知識時效性模型訓(xùn)練數(shù)據(jù)是過去的企業(yè)知識庫是持續(xù)更新的需要做檢索增強(qiáng)。部署成本生產(chǎn)環(huán)境 GPU 資源有限不可能每個業(yè)務(wù)都單獨跑一套大模型。穩(wěn)定性生產(chǎn)環(huán)境不能因為并發(fā)請求、模型推理慢、外部依賴抖動而影響業(yè)務(wù)。可觀測性與運維Demo 階段不需要看日志、指標(biāo)生產(chǎn)環(huán)境必須能監(jiān)控、告警、排查鏈路。整個項目從需求確認(rèn)到最終上線大概經(jīng)歷了三個階段第一階段用開源模型 快速腳本搭建 Demo驗證“基于企業(yè)知識庫做問答”這件事是否可行。第二階段梳理生產(chǎn)環(huán)境約束確定 AI 架構(gòu)選型。第三階段完成生產(chǎn)部署、優(yōu)化、上線與排障。接下來按照這個時間線逐個復(fù)盤每一階段的關(guān)鍵決策。2. Demo 階段的快速驗證很多 AI 項目都是從 Demo 開始的我們也不例外。市面上大模型部署方案很多但在 Demo 階段不需要過度糾結(jié)重點是快速驗證兩條鏈路模型推理鏈路本地部署的大模型能否按預(yù)期生成穩(wěn)定的回答。知識檢索鏈路企業(yè)文檔經(jīng)過切分、向量化之后能否檢索出相關(guān)內(nèi)容。2.1 技術(shù)選型當(dāng)時我們對比了幾類方案最終選擇的是以開源模型 本地向量庫為主模型推理使用 Ollama 做本地模型部署加載開源大模型。向量化使用文本嵌入模型對知識庫文檔做向量化。向量存儲與檢索使用輕量級向量數(shù)據(jù)庫存儲向量做相似度檢索。應(yīng)用框架初期直接使用 Python 腳本串聯(lián)“檢索 生成”流程。選擇這些技術(shù)的原因很簡單它們能最快打通從文檔到問答的完整鏈路而且不需要申請外部 API 權(quán)限數(shù)據(jù)也不需要出內(nèi)網(wǎng)。2.2 Demo 的完整流程Demo 的整體流程如下把企業(yè)文檔Word、PDF、Markdown批量讀取為純文本。按一定規(guī)則切分文檔為文本塊。對每個文本塊調(diào)用嵌入模型生成向量。將向量和原文存入向量數(shù)據(jù)庫。用戶提問時將問題向量化。在向量數(shù)據(jù)庫中檢索相似度最高的文本塊。將文本塊作為上下文連同用戶問題一起拼接到 Prompt 中。調(diào)用本地大模型生成最終回答。核心代碼邏輯如下from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma from langchain_community.llms import Ollama from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 初始化 embedding 與 LLM embeddings OllamaEmbeddings(modelbge-m3) llm Ollama(modelqwen2.5:14b, temperature0.3) # 2. 切分文檔 text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50 ) chunks text_splitter.split_text(original_text) # 3. 存儲向量 vectorstore Chroma.from_texts( textschunks, embeddingembeddings, persist_directory./chroma_db ) # 4. 檢索 retriever vectorstore.as_retriever(search_kwargs{k: 5}) docs retriever.get_relevant_documents(user_question) context \n\n.join([doc.page_content for doc in docs]) # 5. 拼接 Prompt 并生成回答 prompt f請基于以下知識庫內(nèi)容回答用戶問題。 如果知識庫內(nèi)容不足以回答請明確說明。 知識庫內(nèi)容 {context} 用戶問題 {user_question} response llm.invoke(prompt) print(response)這段代碼在 Demo 階段完全沒有問題它把“文檔進(jìn)來 - 知識檢索 - 答案生成”的閉環(huán)跑通了。但如果你把它直接放到生產(chǎn)環(huán)境會遇到一系列問題。2.3 Demo 階段的明顯短板跑通 Demo 之后我們梳理了它不適合直接上生產(chǎn)的幾個原因Demo 階段做法生產(chǎn)存在的問題單機(jī)運行 Python 腳本無法提供穩(wěn)定服務(wù)無法水平擴(kuò)展每次啟動重新加載文檔文檔更新、向量增量入庫都沒有管理直接調(diào)用本地模型服務(wù)無鑒權(quán)、無限流、無并發(fā)控制日志打印在控制臺無法追蹤問題無法定位是哪一段鏈路失敗單點部署模型服務(wù)或應(yīng)用服務(wù)宕機(jī)業(yè)務(wù)直接中斷參數(shù)寫在代碼里不同環(huán)境無法隔離配置更別提灰度發(fā)布所以進(jìn)入生產(chǎn)階段之前我們重新梳理了架構(gòu)選型。3. 生產(chǎn)環(huán)境 AI 架構(gòu)選型3.1 自建大模型服務(wù)還是調(diào)用外部 API第一個要決策的問題是模型能力從哪里來。調(diào)用外部大模型 API 的優(yōu)點是開發(fā)效率高、模型能力強(qiáng)、不需要自己維護(hù) GPU 服務(wù)但對很多企業(yè)來說數(shù)據(jù)出境、隱私合規(guī)、數(shù)據(jù)安全是不可接受的硬約束。尤其知識庫內(nèi)容涉及企業(yè)內(nèi)部資料直接發(fā)給外部 API 在合規(guī)層面風(fēng)險很大。自建大模型服務(wù)的優(yōu)點是數(shù)據(jù)完全在內(nèi)部掌握可控性強(qiáng)缺點是需要 GPU 資源、需要運維模型服務(wù)、模型能力相對商業(yè) API 會弱一些。我們最終選擇了自建這條路線同時為了降低部署和運維成本使用了 Ollama 作為模型推理服務(wù)。選擇 Ollama 而不是直接用 vLLM、TensorRT-LLM 這類推理框架原因是在我們的場景下并發(fā)量不是極端高Ollama 的部署簡單、模型管理方便、API 兼容 OpenAI 格式后續(xù)替換模型也比較容易。如果你們的生產(chǎn)環(huán)境并發(fā)量很高或者對推理延遲有嚴(yán)格的要求建議調(diào)研 vLLM 等專用推理框架如果團(tuán)隊運維能力有限Ollama 或同類輕量方案也可以作為起點但要注意壓測。3.2 整體架構(gòu)分層生產(chǎn)環(huán)境架構(gòu)我們在 Demo 的單機(jī)腳本上做了分層設(shè)計整體架構(gòu)如下用戶 → 統(tǒng)一 API 網(wǎng)關(guān) → AI 應(yīng)用服務(wù) → 檢索服務(wù) → 向量數(shù)據(jù)庫 ↓ 大模型推理服務(wù)各層職責(zé)如下API 網(wǎng)關(guān)負(fù)責(zé)統(tǒng)一的入口、鑒權(quán)、限流、請求日志。AI 應(yīng)用服務(wù)負(fù)責(zé)編排“檢索 生成”流程接收請求、調(diào)用下游服務(wù)、組織返回。檢索服務(wù)對知識庫內(nèi)容做向量化、切分、檢索數(shù)據(jù)更新也由這一層管理。向量數(shù)據(jù)庫存儲文檔向量提供相似度檢索能力。大模型推理服務(wù)部署開源大模型對外提供 OpenAI 兼容的推理接口。應(yīng)用服務(wù)我們選擇了 Java Spring Boot 體系主要考慮到團(tuán)隊技術(shù)棧和后續(xù)維護(hù)成本檢索服務(wù)和向量化部分保留了 Python因為生態(tài)最成熟方便調(diào)試?？缯Z言之間通過 HTTP 接口通信。如果你不想維護(hù)兩套語言體系也可以全部使用 Java 生態(tài)比如 Spring AI 中已經(jīng)封裝了 ChatModel、EmbeddingModel、VectorStore 等抽象可以直接對接 Ollama、Chroma 等組件。兩種方案沒有絕對優(yōu)劣核心是團(tuán)隊能不能長期維護(hù)。3.3 模型部署方式選擇本地模型部署是這次架構(gòu)選型的另一個重點。我們對比了三種方案方案優(yōu)勢劣勢適用場景Ollama安裝簡單模型管理方便API 兼容 OpenAI高并發(fā)性能一般中小并發(fā)、快速交付vLLM高吞吐高并發(fā)支持連續(xù)批處理部署復(fù)雜度高顯存要求高高并發(fā)場景調(diào)用外部 API模型能力強(qiáng)免運維數(shù)據(jù)出網(wǎng)合規(guī)風(fēng)險非敏感數(shù)據(jù)場景最終選型為 Ollama 部署模型原因是我們的并發(fā)規(guī)?？煽厍蚁Ｍ诒ＷC數(shù)據(jù)安全的前提下縮短交付周期。這里補(bǔ)充一個重要經(jīng)驗不要一上來就追求最大規(guī)模的模型。先明確業(yè)務(wù)能接受的回答質(zhì)量底線和推理延遲上限再選擇模型大小。我們實際測試過 7B、14B、32B 級別的模型最終選了 14B 級別因為 7B 在專業(yè)知識問答上準(zhǔn)確率不夠32B 對 GPU 資源要求高延遲也大。生產(chǎn)環(huán)境要在質(zhì)量、成本、延遲之間找平衡。3.4 向量數(shù)據(jù)庫選型向量數(shù)據(jù)庫也做了對比。Chroma開發(fā)體驗好適合本地跑 Demo但生產(chǎn)環(huán)境的分布式和高可用能力較弱。Milvus / 開源版功能強(qiáng)支持分布式但部署和運維成本較高。其他方案如果團(tuán)隊已重度使用 Elasticsearch也可以用 ES 的向量檢索能力減少引入新組件。我們考慮到當(dāng)前知識庫數(shù)據(jù)量還在可控范圍內(nèi)先用的是輕量方案后續(xù)數(shù)據(jù)量增長再遷移至專業(yè)向量數(shù)據(jù)庫。這里的重點是向量數(shù)據(jù)庫的選型要和知識庫的數(shù)據(jù)量、更新頻率、檢索性能要求綁定不要盲目引入重組件。4. 生產(chǎn)環(huán)境部署實施4.1 整體服務(wù)拆分生產(chǎn)環(huán)境最終拆成了以下幾類服務(wù)ai-gateway # 統(tǒng)一入口鑒權(quán)、限流、路由 ai-app-server # AI 應(yīng)用編排服務(wù)Java Spring Boot ai-retrieval-server # 檢索服務(wù)Python FastAPI ai-knowledge-api # 知識庫管理接口文檔上傳、切片、向量化 vector-db # 向量數(shù)據(jù)庫 ollama-server # 大模型推理服務(wù)服務(wù)之間通過內(nèi)網(wǎng) HTTP 通信不直接暴露端口到公網(wǎng)。4.2 模型推理服務(wù)部署Ollama 在 Linux 服務(wù)器上安裝之后默認(rèn)監(jiān)聽 11434 端口。生產(chǎn)環(huán)境我們建議通過 systemd 管理并設(shè)置環(huán)境變量來控制模型加載方式。安裝命令curl -fsSL https://ollama.com/install.sh | sh啟動服務(wù)systemctl start ollama systemctl enable ollama拉取模型ollama pull qwen2.5:14b生產(chǎn)環(huán)境建議通過 systemd 環(huán)境變量配置 Ollama 的并發(fā)參數(shù)默認(rèn)并發(fā)不一定適合你的場景[Service] EnvironmentOLLAMA_NUM_PARALLEL2 EnvironmentOLLAMA_MAX_LOADED_MODELS1 EnvironmentOLLAMA_KEEP_ALIVE5m關(guān)于這幾個參數(shù)再解釋一下OLLAMA_NUM_PARALLEL表示同一個模型同時處理多少個請求。值設(shè)太高如果顯存不夠推理會變慢甚至出錯設(shè)太低時并發(fā)上來后會排隊。OLLAMA_MAX_LOADED_MODELS同時常駐顯存的模型數(shù)量。如果只有一個模型設(shè)置為 1 即可避免多個模型切換導(dǎo)致顯存反復(fù)加載。OLLAMA_KEEP_ALIVE模型在顯存中保持加載的時間。太短會導(dǎo)致頻繁冷加載響應(yīng)變慢太長會持續(xù)占顯存。按實際調(diào)用頻率調(diào)整。修改環(huán)境變量后需要重啟服務(wù)systemctl daemon-reload systemctl restart ollama4.3 應(yīng)用服務(wù) Spring Boot 接入大模型Java 應(yīng)用服務(wù)我們使用 Spring Boot 3 Spring AI 來編排調(diào)用流程。以接入 Ollama 為例spring: ai: ollama: base-url: http://ollama-server:11434 chat: model: qwen2.5:14b options: temperature: 0.3Java 代碼中調(diào)用模型import org.springframework.ai.chat.ChatClient; import org.springframework.ai.chat.messages.UserMessage; import org.springframework.ai.chat.prompt.Prompt; import org.springframework.stereotype.Service; Service public class AiChatService { private final ChatClient chatClient; public AiChatService(ChatClient chatClient) { this.chatClient chatClient; } public String chat(String userQuestion, String context) { String promptContent 請基于以下知識庫內(nèi)容回答用戶問題。 如果知識庫內(nèi)容不足以回答請明確說明。 知識庫內(nèi)容 %s 用戶問題 %s .formatted(context, userQuestion); return chatClient.call(new Prompt(new UserMessage(promptContent))) .getResult() .getOutput() .getContent(); } }如果你無法確定所使用的 Spring AI 版本是否包含上述 API請先參考對應(yīng)版本官方文檔確認(rèn)接口名。Spring AI 迭代速度較快不同版本之間 API 差異較大尤其是ChatClient的包路徑和調(diào)用方式在新版本中有過調(diào)整。4.4 檢索服務(wù)部署檢索服務(wù)我們使用 FastAPI 封裝了一組接口包含文檔向量化和相似度檢索。服務(wù)內(nèi)部仍然使用 Ollama 的 embedding 模型做向量化。from fastapi import FastAPI from pydantic import BaseModel from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma app FastAPI() embeddings OllamaEmbeddings(modelbge-m3) vectorstore Chroma( persist_directory/data/vector_store, embedding_functionembeddings ) class SearchRequest(BaseModel): question: str k: int 5 class SearchResult(BaseModel): content: str score: float app.post(/search, response_modellist[SearchResult]) def search(request: SearchRequest): docs vectorstore.similarity_search_with_score( request.question, krequest.k ) return [ SearchResult(contentdoc.page_content, scorescore) for doc, score in docs ]啟動服務(wù)時使用 Gunicorn Uvicorn 多進(jìn)程方式避免單進(jìn)程處理不了并發(fā)請求。gunicorn main:app -w 2 -k uvicorn.workers.UvicornWorker -b 0.0.0.0:8000這里需要根據(jù)服務(wù)器 CPU 核數(shù)和請求量調(diào)整-w參數(shù)。進(jìn)程數(shù)通常設(shè)為 CPU 核數(shù)的 1 到 2 倍即可不是越大越好。4.5 Docker Compose 一鍵編排為了讓整個環(huán)境可以快速復(fù)制部署我們用 Docker Compose 把應(yīng)用服務(wù)、檢索服務(wù)、向量數(shù)據(jù)庫編排到一起。Ollama 是否容器化可以根據(jù)實際情況而定如果宿主機(jī)顯存資源有限也可以直接在宿主機(jī)安裝宿主環(huán)境的管理更直接一些。一個參考的docker-compose.yml如下version: 3.8 services: ai-app-server: image: registry.internal.example.com/ai-app-server:1.0.0 ports: - 8080:8080 environment: SPRING_AI_OLLAMA_BASE_URL: http://ollama-server:11434 RETRIEVAL_SERVICE_URL: http://ai-retrieval-server:8000 depends_on: - ai-retrieval-server ai-retrieval-server: image: registry.internal.example.com/ai-retrieval-server:1.0.0 volumes: - /data/vector_store:/data/vector_store environment: OLLAMA_BASE_URL: http://ollama-server:11434 depends_on: - ollama-server ollama-server: image: ollama/ollama:latest ports: - 11434:11434 volumes: - /data/ollama:/root/.ollama environment: OLLAMA_NUM_PARALLEL: 2 OLLAMA_KEEP_ALIVE: 5m注意鏡像地址需要替換成你們自己的私有鏡像倉庫地址我這里只是一個示例。生產(chǎn)環(huán)境不建議從公網(wǎng) Docker Hub 直接拉取業(yè)務(wù)鏡像。容器啟動后docker compose up -d進(jìn)入 Ollama 容器拉取模型docker exec -it ollama-server ollama pull qwen2.5:14b docker exec -it ollama-server ollama pull bge-m34.6 知識庫初始化首次落地時我們編寫了一個初始化腳本把歷史文檔批量導(dǎo)入python scripts/init_knowledge_base.py \ --source-dir /data/docs \ --vector-dir /data/vector_store \ --chunk-size 500 \ --chunk-overlap 50腳本核心邏輯import os import glob from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.document_loaders import TextLoader from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma def load_and_split(source_dir: str, chunk_size: int, chunk_overlap: int): text_splitter RecursiveCharacterTextSplitter( chunk_sizechunk_size, chunk_overlapchunk_overlap ) docs [] for file_path in glob.glob(os.path.join(source_dir, **/*.md), recursiveTrue): loader TextLoader(file_path, encodingutf-8) docs.extend(loader.load_and_split(text_splitter)) return docs def build_vector_store(docs, vector_dir: str, model: str): embeddings OllamaEmbeddings(modelmodel) vectorstore Chroma.from_documents( documentsdocs, embeddingembeddings, persist_directoryvector_dir ) return vectorstore if __name__ __main__: docs load_and_split(/data/docs, 500, 50) build_vector_store(docs, /data/vector_store, bge-m3) print(f共導(dǎo)入文檔塊: {len(docs)})在企業(yè)真實場景中文檔格式不只 Markdown還有 PDF、Word 等需要根據(jù)實際情況開發(fā)對應(yīng)的文檔解析器。切分的 chunk_size 也需要根據(jù)文檔類型調(diào)整不要所有文檔都用同一套參數(shù)。5. 生產(chǎn)環(huán)境優(yōu)化關(guān)鍵點5.1 Prompt 與上下文管理Demo 階段的 Prompt 比較簡單生產(chǎn)環(huán)境則要更嚴(yán)格地控制 Prompt。以下是我們線上使用的版本結(jié)構(gòu)系統(tǒng)角色你是企業(yè)內(nèi)部知識助手回答必須基于提供的知識庫內(nèi)容。 約束條件 1. 如果知識庫內(nèi)容不包含答案請如實說明“未在知識庫中找到相關(guān)內(nèi)容”不要編造。 2. 回答保持簡潔、準(zhǔn)確。 3. 禁止輸出與問題無關(guān)的內(nèi)容。 知識庫內(nèi)容 {context} 用戶問題 {question}上下文控制上需要注意兩個問題。第一檢索到的文本塊不要無腦拼接超出模型上下文窗口會導(dǎo)致請求失敗或回答質(zhì)量下降。需要對檢索結(jié)果做截斷或過濾。第二如果企業(yè)文檔中存在相互矛盾的內(nèi)容Prompt 中應(yīng)要求模型指出矛盾而不是強(qiáng)行給出統(tǒng)一答案。這在多版本制度文檔場景中很常見。5.2 緩存設(shè)計相同或相似的問題如果每次都重新走一遍檢索 推理成本和延遲都很高。我們引入了一層結(jié)果緩存Service public class AnswerCacheService { private final CacheString, String answerCache Caffeine.newBuilder() .maximumSize(10000) .expireAfterWrite(Duration.ofHours(1)) .build(); public String getIfPresent(String question) { return answerCache.getIfPresent(question); } public void put(String question, String answer) { answerCache.put(question, answer); } }這里有一個關(guān)鍵點如何判斷兩個問題是否相同。我們采用了“先向量化再計算相似度”的語義緩存而不是簡單的字符串匹配。當(dāng)新問題與緩存中的問題相似度超過 0.95 時直接返回緩存結(jié)果。緩存的核心目的是降本效果非常明顯。5.3 限流與降級生產(chǎn)環(huán)境必須考慮惡意請求和突發(fā)流量。我們在 API 網(wǎng)關(guān)層做了限流基于令牌桶算法實現(xiàn)。spring: cloud: gateway: routes: - id: ai-app uri: http://ai-app-server:8080 predicates: - Path/api/ai/** filters: - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 10 redis-rate-limiter.burstCapacity: 20降級策略方面當(dāng)大模型推理服務(wù)的響應(yīng)時間超過閾值時應(yīng)用服務(wù)應(yīng)快速失敗而不是讓請求長時間掛起。同時要設(shè)計好兜底文案不能直接把模型內(nèi)部異常拋給用戶。5.4 可觀測性建設(shè)Demo 階段不需要監(jiān)控生產(chǎn)環(huán)境必須有完整的觀測體系日志應(yīng)用日志統(tǒng)一 JSON 格式輸出包含 traceId。指標(biāo)請求量、P95/P99 延遲、模型推理耗時、檢索耗時、錯誤率。鏈路追蹤跨服務(wù)調(diào)用需要 traceId 貫穿網(wǎng)關(guān)到檢索到模型推理。在 Spring Boot 中我們通過過濾器為每個請求生成 traceIdimport jakarta.servlet.Filter; import jakarta.servlet.FilterChain; import jakarta.servlet.ServletRequest; import jakarta.servlet.ServletResponse; import jakarta.servlet.http.HttpServletRequest; import org.slf4j.MDC; import org.springframework.stereotype.Component; import java.util.UUID; Component public class TraceIdFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) { try { String traceId UUID.randomUUID().toString().replace(-, ); MDC.put(traceId, traceId); chain.doFilter(request, response); } catch (Exception e) { throw new RuntimeException(e); } finally { MDC.remove(traceId); } } }日志配置中加入 traceId 字段pattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - [%X{traceId}] - %msg%n/pattern沒有可觀測性生產(chǎn)環(huán)境排查問題就像盲人摸象這個環(huán)節(jié)不能省。6. 常見問題與排查思路這次部署過程中我們積累了不少排障經(jīng)驗下面按問題類型整理。6.1 顯存不足導(dǎo)致模型加載失敗問題現(xiàn)象常見原因解決思路Ollama 報錯no space left on device或模型加載失敗顯存不足模型參數(shù)過大換用更小模型或降低并發(fā)參數(shù)推理時 OOM并發(fā)線程數(shù)過高調(diào)低OLLAMA_NUM_PARALLEL模型加載很慢KEEP_ALIVE設(shè)置太短調(diào)大OLLAMA_KEEP_ALIVE這里最直接的排查命令nvidia-smi確認(rèn) GPU 顯存占用率。如果模型本身大小接近顯存上限說明該模型不適合當(dāng)前環(huán)境。6.2 檢索結(jié)果相關(guān)性差問題現(xiàn)象常見原因解決思路回答完全沒用到知識庫內(nèi)容Prompt 中知識庫內(nèi)容未正確傳入檢查檢索服務(wù)返回的數(shù)據(jù)是否為空檢索到的文本與問題無關(guān)chunk_size 過大或過小調(diào)整切分參數(shù)專業(yè)術(shù)語檢索不到embedding 模型對領(lǐng)域詞匯理解不足更換效果更好的 embedding 模型多個文檔內(nèi)容沖突未做內(nèi)容質(zhì)量過濾從知識庫源頭清洗文檔實際調(diào)優(yōu)時可以從單條樣本開始逐步檢查檢索結(jié)果。如果檢索出來的文本塊本身就不相關(guān)再優(yōu)化 Prompt 也沒用。6.3 服務(wù)間調(diào)用超時問題現(xiàn)象常見原因解決思路應(yīng)用服務(wù)請求檢索服務(wù)超時檢索服務(wù)單進(jìn)程處理不過來增加 Gunicorn worker 數(shù)請求 Ollama 超時模型推理排隊調(diào)大OLLAMA_NUM_PARALLEL或并發(fā)過高時限流接口整體響應(yīng)慢檢索 推理串行耗時太長對相似問題做緩存排查時先把一次完整請求拆成多段計時定位耗時集中在哪個環(huán)節(jié)再針對性處理。6.4 文檔更新后檢索結(jié)果沒變化問題現(xiàn)象常見原因解決思路新文檔上傳后問答結(jié)果沒有變化向量庫沒有增量更新實現(xiàn)增量入庫邏輯刪除了舊文檔回答仍引用舊內(nèi)容舊向量未被刪除入庫時保存文檔 ID更新時先刪后插向量庫持久化目錄被重新創(chuàng)建容器重啟后掛載路徑配置錯誤檢查 volume 掛載如果向量庫和原始文檔之間沒有建立 ID 映射生產(chǎn)環(huán)境做增量更新會非常痛苦。建議文件名或文檔 ID 作為元數(shù)據(jù)寫入向量庫。7. 從 Demo 到生產(chǎn)的關(guān)鍵差異復(fù)盤最后想把這次從 Demo 到生產(chǎn)的完整過程做一個橫向總結(jié)這部分也是我認(rèn)為最值得反復(fù)看的。維度Demo 階段生產(chǎn)環(huán)境目標(biāo)驗證可行性穩(wěn)定支撐業(yè)務(wù)數(shù)據(jù)安全不關(guān)注必須合規(guī)數(shù)據(jù)不出內(nèi)網(wǎng)架構(gòu)單腳本網(wǎng)關(guān) 應(yīng)用服務(wù) 檢索服務(wù) 推理服務(wù)并發(fā)無必須壓測限流模型本地或 API 都行根據(jù)質(zhì)量、成本、延遲選型知識庫一次性導(dǎo)入增量更新ID 映射清洗可觀測性控制臺打印日志、指標(biāo)、鏈路追蹤容錯無降級、兜底、快速失敗部署本地運行容器化環(huán)境隔離配置管理安全無鑒權(quán)網(wǎng)關(guān)鑒權(quán)、內(nèi)網(wǎng)隔離、最小權(quán)限關(guān)于“AI 架構(gòu)選擇”我的核心觀點是不要為了追求新技術(shù)而引入復(fù)雜組件也不要因為團(tuán)隊熟悉某套技術(shù)棧就盲目套用。架構(gòu)選型的本質(zhì)是在約束條件下做取舍。對于大多數(shù)企業(yè)內(nèi)部 AI 應(yīng)用優(yōu)先考慮數(shù)據(jù)安全、可維護(hù)性和成本可控其次才是模型能力的極致表現(xiàn)。模型大小選擇上建議按這個步驟來先收集一批企業(yè)真實知識問答作為評測樣本。用不同規(guī)模的模型分別跑一遍。從回答準(zhǔn)確率、延遲、顯存占用三個維度打分。選一個綜合分最高的方案而不是直接上最大模型。部署方式上如果團(tuán)隊運維能力有限D(zhuǎn)ocker Compose 已經(jīng)能覆蓋中小規(guī)模場景如果后續(xù)并發(fā)增長明顯再逐步遷移到 Kubernetes 并把大模型推理層獨立出來使用 vLLM 等高性能推理框架。8. 一些可以復(fù)用的工程建議結(jié)合這次實戰(zhàn)整理一份我們團(tuán)隊后續(xù)在 AI 項目中固定使用的工程化清單。如果你即將把一個 AI Demo 推向生產(chǎn)建議逐條對應(yīng)檢查。第一配置管理從第一天就要做。不同環(huán)境開發(fā)、測試、生產(chǎn)的模型地址、數(shù)據(jù)庫地址、密鑰都不一樣。不要把配置寫死在代碼里。使用 Spring 的application-{profile}.yml或配置中心都可以關(guān)鍵是環(huán)境隔離要明確。第二所有依賴外部服務(wù)的調(diào)用都必須有超時和重試策略。這里的“外部服務(wù)”包括 Ollama、向量數(shù)據(jù)庫、檢索服務(wù)。任何一個下游服務(wù)慢都可能拖垮整個應(yīng)用。第三知識庫數(shù)據(jù)要進(jìn)行版本管理。Demo 階段可以隨便導(dǎo)入文檔生產(chǎn)環(huán)境一旦知識庫內(nèi)容更新出錯會影響所有用戶。這里建議至少做到文檔入庫前有審核流程、入庫時記錄版本號、必要時支持回滾。第四模型服務(wù)和業(yè)務(wù)服務(wù)要分開部署。把模型推理和業(yè)務(wù)邏輯放在同一臺機(jī)器同一個進(jìn)程里只適合驗證階段。模型推理依賴 GPU 資源而業(yè)務(wù)服務(wù)可能隨時擴(kuò)容縮容混部會影響穩(wěn)定性。第五壓測一定要做而且要在接近真實的數(shù)據(jù)集上做。我們當(dāng)時用 200 道真實業(yè)務(wù)問題做并發(fā)壓測時發(fā)現(xiàn)了檢索服務(wù)在并發(fā) 10 以上就開始超時的問題。如果壓測數(shù)據(jù)只用簡單問答很多問題測不出來。第六正式上線前準(zhǔn)備一份應(yīng)急預(yù)案。如果大模型服務(wù)掛了怎么辦如果知識庫向量庫損壞怎么辦如果某個文檔的內(nèi)容是錯誤信息被大量用戶檢索到怎么辦每一條都要有明確的響應(yīng)動作。9. 下一步可以繼續(xù)深入的方向如果這篇文章的讀者也希望在企業(yè) AI 方向持續(xù)深入我覺得可以從以下幾個方面繼續(xù)學(xué)習(xí)大模型推理框架深入了解 vLLM、TensorRT-LLM 的原理和使用方式適合高并發(fā)場景。檢索增強(qiáng)生成RAG包括查詢改寫、重排序Rerank、混合檢索關(guān)鍵詞 向量等進(jìn)階方向。Agent 架構(gòu)如果你希望 AI 應(yīng)用不只是“問答機(jī)器人”還要具備工具調(diào)用、多步任務(wù)規(guī)劃能力可以研究 Agent 架構(gòu)設(shè)計。AI 應(yīng)用的可觀測性標(biāo)準(zhǔn)比如如何評估生成內(nèi)容的質(zhì)量如何追蹤模型幻覺事件這些在生產(chǎn)環(huán)境一定會遇到。多模態(tài)如果后續(xù)文檔中包含圖片、掃描件需要多模態(tài)模型參與解析和生成。本文記錄的就是一次相對完整的企業(yè) AI 落地過程。不同團(tuán)隊的技術(shù)棧、資源規(guī)模、業(yè)務(wù)約束都不一樣具體方案輸出了差異但思考問題的框架——從 Demo 到生產(chǎn)的差距在哪里、每一步?jīng)Q策的取舍依據(jù)是什么——是共通的。希望這篇復(fù)盤能幫正在做類似項目的你少踩一些坑。