先交代一下背景。最近團隊在做一個企業(yè)內部的 AI 知識助手從最初技術驗證用的 Demo到后來真正部署到生產(chǎn)環(huán)境供業(yè)務部門使用中間遇到了不少架構選型和部署上的問題。整個過程走完以后最大的感受是Demo 只需要證明“能跑”生產(chǎn)要考慮的則是“能穩(wěn)定、安全、可維護地一直跑”。這兩者之間有時候隔著的不只是代碼量的差距而是整個架構思維和工程規(guī)范的落差。這篇文章會以這次實戰(zhàn)為主線完整復盤我們在企業(yè) AI 架構選擇與部署過程中的關鍵決策、踩坑記錄和最終落地形態(tài)。內容包括架構選型對比、Demo 階段設計、生產(chǎn)環(huán)境改造、部署實施步驟、常見問題排查以及工程化建議。適合正在做企業(yè)級 AI 應用落地的后端開發(fā)、架構師、運維同學參考如果你現(xiàn)在還停留在跑通 Demo 的階段也可以提前了解后面會踩到哪些坑。1. 需求場景與核心問題先明確一下我們要做的業(yè)務企業(yè)內部的 AI 知識助手。核心能力是通過自然語言提問讓系統(tǒng)從企業(yè)內部文檔庫、知識庫中檢索相關內容再由大語言模型生成回答。聽起來不復雜但實際落地時問題主要集中在幾個方面數(shù)據(jù)安全企業(yè)內部文檔不能隨意發(fā)給外部大模型 API數(shù)據(jù)必須留在內部。知識時效性模型訓練數(shù)據(jù)是過去的企業(yè)知識庫是持續(xù)更新的需要做檢索增強。部署成本生產(chǎn)環(huán)境 GPU 資源有限不可能每個業(yè)務都單獨跑一套大模型。穩(wěn)定性生產(chǎn)環(huán)境不能因為并發(fā)請求、模型推理慢、外部依賴抖動而影響業(yè)務?？捎^測性與運維Demo 階段不需要看日志、指標生產(chǎn)環(huán)境必須能監(jiān)控、告警、排查鏈路。整個項目從需求確認到最終上線大概經(jīng)歷了三個階段第一階段用開源模型 快速腳本搭建 Demo驗證“基于企業(yè)知識庫做問答”這件事是否可行。第二階段梳理生產(chǎn)環(huán)境約束確定 AI 架構選型。第三階段完成生產(chǎn)部署、優(yōu)化、上線與排障。接下來按照這個時間線逐個復盤每一階段的關鍵決策。2. Demo 階段的快速驗證很多 AI 項目都是從 Demo 開始的我們也不例外。市面上大模型部署方案很多但在 Demo 階段不需要過度糾結重點是快速驗證兩條鏈路模型推理鏈路本地部署的大模型能否按預期生成穩(wěn)定的回答。知識檢索鏈路企業(yè)文檔經(jīng)過切分、向量化之后能否檢索出相關內容。2.1 技術選型當時我們對比了幾類方案最終選擇的是以開源模型 本地向量庫為主模型推理使用 Ollama 做本地模型部署加載開源大模型。向量化使用文本嵌入模型對知識庫文檔做向量化。向量存儲與檢索使用輕量級向量數(shù)據(jù)庫存儲向量做相似度檢索。應用框架初期直接使用 Python 腳本串聯(lián)“檢索 生成”流程。選擇這些技術的原因很簡單它們能最快打通從文檔到問答的完整鏈路而且不需要申請外部 API 權限數(shù)據(jù)也不需要出內網(wǎng)。2.2 Demo 的完整流程Demo 的整體流程如下把企業(yè)文檔Word、PDF、Markdown批量讀取為純文本。按一定規(guī)則切分文檔為文本塊。對每個文本塊調用嵌入模型生成向量。將向量和原文存入向量數(shù)據(jù)庫。用戶提問時將問題向量化。在向量數(shù)據(jù)庫中檢索相似度最高的文本塊。將文本塊作為上下文連同用戶問題一起拼接到 Prompt 中。調用本地大模型生成最終回答。核心代碼邏輯如下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請基于以下知識庫內容回答用戶問題。 如果知識庫內容不足以回答請明確說明。 知識庫內容 {context} 用戶問題 {user_question} response llm.invoke(prompt) print(response)這段代碼在 Demo 階段完全沒有問題它把“文檔進來 - 知識檢索 - 答案生成”的閉環(huán)跑通了。但如果你把它直接放到生產(chǎn)環(huán)境會遇到一系列問題。2.3 Demo 階段的明顯短板跑通 Demo 之后我們梳理了它不適合直接上生產(chǎn)的幾個原因Demo 階段做法生產(chǎn)存在的問題單機運行 Python 腳本無法提供穩(wěn)定服務無法水平擴展每次啟動重新加載文檔文檔更新、向量增量入庫都沒有管理直接調用本地模型服務無鑒權、無限流、無并發(fā)控制日志打印在控制臺無法追蹤問題無法定位是哪一段鏈路失敗單點部署模型服務或應用服務宕機業(yè)務直接中斷參數(shù)寫在代碼里不同環(huán)境無法隔離配置更別提灰度發(fā)布所以進入生產(chǎn)階段之前我們重新梳理了架構選型。3. 生產(chǎn)環(huán)境 AI 架構選型3.1 自建大模型服務還是調用外部 API第一個要決策的問題是模型能力從哪里來。調用外部大模型 API 的優(yōu)點是開發(fā)效率高、模型能力強、不需要自己維護 GPU 服務但對很多企業(yè)來說數(shù)據(jù)出境、隱私合規(guī)、數(shù)據(jù)安全是不可接受的硬約束。尤其知識庫內容涉及企業(yè)內部資料直接發(fā)給外部 API 在合規(guī)層面風險很大。自建大模型服務的優(yōu)點是數(shù)據(jù)完全在內部掌握可控性強缺點是需要 GPU 資源、需要運維模型服務、模型能力相對商業(yè) API 會弱一些。我們最終選擇了自建這條路線同時為了降低部署和運維成本使用了 Ollama 作為模型推理服務。選擇 Ollama 而不是直接用 vLLM、TensorRT-LLM 這類推理框架原因是在我們的場景下并發(fā)量不是極端高Ollama 的部署簡單、模型管理方便、API 兼容 OpenAI 格式后續(xù)替換模型也比較容易。如果你們的生產(chǎn)環(huán)境并發(fā)量很高或者對推理延遲有嚴格的要求建議調研 vLLM 等專用推理框架如果團隊運維能力有限Ollama 或同類輕量方案也可以作為起點但要注意壓測。3.2 整體架構分層生產(chǎn)環(huán)境架構我們在 Demo 的單機腳本上做了分層設計整體架構如下用戶 → 統(tǒng)一 API 網(wǎng)關 → AI 應用服務 → 檢索服務 → 向量數(shù)據(jù)庫 ↓ 大模型推理服務各層職責如下API 網(wǎng)關負責統(tǒng)一的入口、鑒權、限流、請求日志。AI 應用服務負責編排“檢索 生成”流程接收請求、調用下游服務、組織返回。檢索服務對知識庫內容做向量化、切分、檢索數(shù)據(jù)更新也由這一層管理。向量數(shù)據(jù)庫存儲文檔向量提供相似度檢索能力。大模型推理服務部署開源大模型對外提供 OpenAI 兼容的推理接口。應用服務我們選擇了 Java Spring Boot 體系主要考慮到團隊技術棧和后續(xù)維護成本檢索服務和向量化部分保留了 Python因為生態(tài)最成熟方便調試?？缯Z言之間通過 HTTP 接口通信。如果你不想維護兩套語言體系也可以全部使用 Java 生態(tài)比如 Spring AI 中已經(jīng)封裝了 ChatModel、EmbeddingModel、VectorStore 等抽象可以直接對接 Ollama、Chroma 等組件。兩種方案沒有絕對優(yōu)劣核心是團隊能不能長期維護。3.3 模型部署方式選擇本地模型部署是這次架構選型的另一個重點。我們對比了三種方案方案優(yōu)勢劣勢適用場景Ollama安裝簡單模型管理方便API 兼容 OpenAI高并發(fā)性能一般中小并發(fā)、快速交付vLLM高吞吐高并發(fā)支持連續(xù)批處理部署復雜度高顯存要求高高并發(fā)場景調用外部 API模型能力強免運維數(shù)據(jù)出網(wǎng)合規(guī)風險非敏感數(shù)據(jù)場景最終選型為 Ollama 部署模型原因是我們的并發(fā)規(guī)?？煽厍蚁Ｍ诒ＷC數(shù)據(jù)安全的前提下縮短交付周期。這里補充一個重要經(jīng)驗不要一上來就追求最大規(guī)模的模型。先明確業(yè)務能接受的回答質量底線和推理延遲上限再選擇模型大小。我們實際測試過 7B、14B、32B 級別的模型最終選了 14B 級別因為 7B 在專業(yè)知識問答上準確率不夠32B 對 GPU 資源要求高延遲也大。生產(chǎn)環(huán)境要在質量、成本、延遲之間找平衡。3.4 向量數(shù)據(jù)庫選型向量數(shù)據(jù)庫也做了對比。Chroma開發(fā)體驗好適合本地跑 Demo但生產(chǎn)環(huán)境的分布式和高可用能力較弱。Milvus / 開源版功能強支持分布式但部署和運維成本較高。其他方案如果團隊已重度使用 Elasticsearch也可以用 ES 的向量檢索能力減少引入新組件。我們考慮到當前知識庫數(shù)據(jù)量還在可控范圍內先用的是輕量方案后續(xù)數(shù)據(jù)量增長再遷移至專業(yè)向量數(shù)據(jù)庫。這里的重點是向量數(shù)據(jù)庫的選型要和知識庫的數(shù)據(jù)量、更新頻率、檢索性能要求綁定不要盲目引入重組件。4. 生產(chǎn)環(huán)境部署實施4.1 整體服務拆分生產(chǎn)環(huán)境最終拆成了以下幾類服務ai-gateway # 統(tǒng)一入口鑒權、限流、路由 ai-app-server # AI 應用編排服務Java Spring Boot ai-retrieval-server # 檢索服務Python FastAPI ai-knowledge-api # 知識庫管理接口文檔上傳、切片、向量化 vector-db # 向量數(shù)據(jù)庫 ollama-server # 大模型推理服務服務之間通過內網(wǎng) HTTP 通信不直接暴露端口到公網(wǎng)。4.2 模型推理服務部署Ollama 在 Linux 服務器上安裝之后默認監(jiān)聽 11434 端口。生產(chǎn)環(huán)境我們建議通過 systemd 管理并設置環(huán)境變量來控制模型加載方式。安裝命令curl -fsSL https://ollama.com/install.sh | sh啟動服務systemctl start ollama systemctl enable ollama拉取模型ollama pull qwen2.5:14b生產(chǎn)環(huán)境建議通過 systemd 環(huán)境變量配置 Ollama 的并發(fā)參數(shù)默認并發(fā)不一定適合你的場景[Service] EnvironmentOLLAMA_NUM_PARALLEL2 EnvironmentOLLAMA_MAX_LOADED_MODELS1 EnvironmentOLLAMA_KEEP_ALIVE5m關于這幾個參數(shù)再解釋一下OLLAMA_NUM_PARALLEL表示同一個模型同時處理多少個請求。值設太高如果顯存不夠推理會變慢甚至出錯設太低時并發(fā)上來后會排隊。OLLAMA_MAX_LOADED_MODELS同時常駐顯存的模型數(shù)量。如果只有一個模型設置為 1 即可避免多個模型切換導致顯存反復加載。OLLAMA_KEEP_ALIVE模型在顯存中保持加載的時間。太短會導致頻繁冷加載響應變慢太長會持續(xù)占顯存。按實際調用頻率調整。修改環(huán)境變量后需要重啟服務systemctl daemon-reload systemctl restart ollama4.3 應用服務 Spring Boot 接入大模型Java 應用服務我們使用 Spring Boot 3 Spring AI 來編排調用流程。以接入 Ollama 為例spring: ai: ollama: base-url: http://ollama-server:11434 chat: model: qwen2.5:14b options: temperature: 0.3Java 代碼中調用模型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 請基于以下知識庫內容回答用戶問題。 如果知識庫內容不足以回答請明確說明。 知識庫內容 %s 用戶問題 %s .formatted(context, userQuestion); return chatClient.call(new Prompt(new UserMessage(promptContent))) .getResult() .getOutput() .getContent(); } }如果你無法確定所使用的 Spring AI 版本是否包含上述 API請先參考對應版本官方文檔確認接口名。Spring AI 迭代速度較快不同版本之間 API 差異較大尤其是ChatClient的包路徑和調用方式在新版本中有過調整。4.4 檢索服務部署檢索服務我們使用 FastAPI 封裝了一組接口包含文檔向量化和相似度檢索。服務內部仍然使用 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 ]啟動服務時使用 Gunicorn Uvicorn 多進程方式避免單進程處理不了并發(fā)請求。gunicorn main:app -w 2 -k uvicorn.workers.UvicornWorker -b 0.0.0.0:8000這里需要根據(jù)服務器 CPU 核數(shù)和請求量調整-w參數(shù)。進程數(shù)通常設為 CPU 核數(shù)的 1 到 2 倍即可不是越大越好。4.5 Docker Compose 一鍵編排為了讓整個環(huán)境可以快速復制部署我們用 Docker Compose 把應用服務、檢索服務、向量數(shù)據(jù)庫編排到一起。Ollama 是否容器化可以根據(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è)務鏡像。容器啟動后docker compose up -d進入 Ollama 容器拉取模型docker exec -it ollama-server ollama pull qwen2.5:14b docker exec -it ollama-server ollama pull bge-m34.6 知識庫初始化首次落地時我們編寫了一個初始化腳本把歷史文檔批量導入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共導入文檔塊: {len(docs)})在企業(yè)真實場景中文檔格式不只 Markdown還有 PDF、Word 等需要根據(jù)實際情況開發(fā)對應的文檔解析器。切分的 chunk_size 也需要根據(jù)文檔類型調整不要所有文檔都用同一套參數(shù)。5. 生產(chǎn)環(huán)境優(yōu)化關鍵點5.1 Prompt 與上下文管理Demo 階段的 Prompt 比較簡單生產(chǎn)環(huán)境則要更嚴格地控制 Prompt。以下是我們線上使用的版本結構系統(tǒng)角色你是企業(yè)內部知識助手回答必須基于提供的知識庫內容。 約束條件 1. 如果知識庫內容不包含答案請如實說明“未在知識庫中找到相關內容”不要編造。 2. 回答保持簡潔、準確。 3. 禁止輸出與問題無關的內容。 知識庫內容 {context} 用戶問題 {question}上下文控制上需要注意兩個問題。第一檢索到的文本塊不要無腦拼接超出模型上下文窗口會導致請求失敗或回答質量下降。需要對檢索結果做截斷或過濾。第二如果企業(yè)文檔中存在相互矛盾的內容Prompt 中應要求模型指出矛盾而不是強行給出統(tǒng)一答案。這在多版本制度文檔場景中很常見。5.2 緩存設計相同或相似的問題如果每次都重新走一遍檢索 推理成本和延遲都很高。我們引入了一層結果緩存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); } }這里有一個關鍵點如何判斷兩個問題是否相同。我們采用了“先向量化再計算相似度”的語義緩存而不是簡單的字符串匹配。當新問題與緩存中的問題相似度超過 0.95 時直接返回緩存結果。緩存的核心目的是降本效果非常明顯。5.3 限流與降級生產(chǎn)環(huán)境必須考慮惡意請求和突發(fā)流量。我們在 API 網(wǎng)關層做了限流基于令牌桶算法實現(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降級策略方面當大模型推理服務的響應時間超過閾值時應用服務應快速失敗而不是讓請求長時間掛起。同時要設計好兜底文案不能直接把模型內部異常拋給用戶。5.4 可觀測性建設Demo 階段不需要監(jiān)控生產(chǎn)環(huán)境必須有完整的觀測體系日志應用日志統(tǒng)一 JSON 格式輸出包含 traceId。指標請求量、P95/P99 延遲、模型推理耗時、檢索耗時、錯誤率。鏈路追蹤跨服務調用需要 traceId 貫穿網(wǎng)關到檢索到模型推理。在 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 顯存不足導致模型加載失敗問題現(xiàn)象常見原因解決思路Ollama 報錯no space left on device或模型加載失敗顯存不足模型參數(shù)過大換用更小模型或降低并發(fā)參數(shù)推理時 OOM并發(fā)線程數(shù)過高調低OLLAMA_NUM_PARALLEL模型加載很慢KEEP_ALIVE設置太短調大OLLAMA_KEEP_ALIVE這里最直接的排查命令nvidia-smi確認 GPU 顯存占用率。如果模型本身大小接近顯存上限說明該模型不適合當前環(huán)境。6.2 檢索結果相關性差問題現(xiàn)象常見原因解決思路回答完全沒用到知識庫內容Prompt 中知識庫內容未正確傳入檢查檢索服務返回的數(shù)據(jù)是否為空檢索到的文本與問題無關chunk_size 過大或過小調整切分參數(shù)專業(yè)術語檢索不到embedding 模型對領域詞匯理解不足更換效果更好的 embedding 模型多個文檔內容沖突未做內容質量過濾從知識庫源頭清洗文檔實際調優(yōu)時可以從單條樣本開始逐步檢查檢索結果。如果檢索出來的文本塊本身就不相關再優(yōu)化 Prompt 也沒用。6.3 服務間調用超時問題現(xiàn)象常見原因解決思路應用服務請求檢索服務超時檢索服務單進程處理不過來增加 Gunicorn worker 數(shù)請求 Ollama 超時模型推理排隊調大OLLAMA_NUM_PARALLEL或并發(fā)過高時限流接口整體響應慢檢索 推理串行耗時太長對相似問題做緩存排查時先把一次完整請求拆成多段計時定位耗時集中在哪個環(huán)節(jié)再針對性處理。6.4 文檔更新后檢索結果沒變化問題現(xiàn)象常見原因解決思路新文檔上傳后問答結果沒有變化向量庫沒有增量更新實現(xiàn)增量入庫邏輯刪除了舊文檔回答仍引用舊內容舊向量未被刪除入庫時保存文檔 ID更新時先刪后插向量庫持久化目錄被重新創(chuàng)建容器重啟后掛載路徑配置錯誤檢查 volume 掛載如果向量庫和原始文檔之間沒有建立 ID 映射生產(chǎn)環(huán)境做增量更新會非常痛苦。建議文件名或文檔 ID 作為元數(shù)據(jù)寫入向量庫。7. 從 Demo 到生產(chǎn)的關鍵差異復盤最后想把這次從 Demo 到生產(chǎn)的完整過程做一個橫向總結這部分也是我認為最值得反復看的。維度Demo 階段生產(chǎn)環(huán)境目標驗證可行性穩(wěn)定支撐業(yè)務數(shù)據(jù)安全不關注必須合規(guī)數(shù)據(jù)不出內網(wǎng)架構單腳本網(wǎng)關 應用服務 檢索服務 推理服務并發(fā)無必須壓測限流模型本地或 API 都行根據(jù)質量、成本、延遲選型知識庫一次性導入增量更新ID 映射清洗可觀測性控制臺打印日志、指標、鏈路追蹤容錯無降級、兜底、快速失敗部署本地運行容器化環(huán)境隔離配置管理安全無鑒權網(wǎng)關鑒權、內網(wǎng)隔離、最小權限關于“AI 架構選擇”我的核心觀點是不要為了追求新技術而引入復雜組件也不要因為團隊熟悉某套技術棧就盲目套用。架構選型的本質是在約束條件下做取舍。對于大多數(shù)企業(yè)內部 AI 應用優(yōu)先考慮數(shù)據(jù)安全、可維護性和成本可控其次才是模型能力的極致表現(xiàn)。模型大小選擇上建議按這個步驟來先收集一批企業(yè)真實知識問答作為評測樣本。用不同規(guī)模的模型分別跑一遍。從回答準確率、延遲、顯存占用三個維度打分。選一個綜合分最高的方案而不是直接上最大模型。部署方式上如果團隊運維能力有限Docker Compose 已經(jīng)能覆蓋中小規(guī)模場景如果后續(xù)并發(fā)增長明顯再逐步遷移到 Kubernetes 并把大模型推理層獨立出來使用 vLLM 等高性能推理框架。8. 一些可以復用的工程建議結合這次實戰(zhàn)整理一份我們團隊后續(xù)在 AI 項目中固定使用的工程化清單。如果你即將把一個 AI Demo 推向生產(chǎn)建議逐條對應檢查。第一配置管理從第一天就要做。不同環(huán)境開發(fā)、測試、生產(chǎn)的模型地址、數(shù)據(jù)庫地址、密鑰都不一樣。不要把配置寫死在代碼里。使用 Spring 的application-{profile}.yml或配置中心都可以關鍵是環(huán)境隔離要明確。第二所有依賴外部服務的調用都必須有超時和重試策略。這里的“外部服務”包括 Ollama、向量數(shù)據(jù)庫、檢索服務。任何一個下游服務慢都可能拖垮整個應用。第三知識庫數(shù)據(jù)要進行版本管理。Demo 階段可以隨便導入文檔生產(chǎn)環(huán)境一旦知識庫內容更新出錯會影響所有用戶。這里建議至少做到文檔入庫前有審核流程、入庫時記錄版本號、必要時支持回滾。第四模型服務和業(yè)務服務要分開部署。把模型推理和業(yè)務邏輯放在同一臺機器同一個進程里只適合驗證階段。模型推理依賴 GPU 資源而業(yè)務服務可能隨時擴容縮容混部會影響穩(wěn)定性。第五壓測一定要做而且要在接近真實的數(shù)據(jù)集上做。我們當時用 200 道真實業(yè)務問題做并發(fā)壓測時發(fā)現(xiàn)了檢索服務在并發(fā) 10 以上就開始超時的問題。如果壓測數(shù)據(jù)只用簡單問答很多問題測不出來。第六正式上線前準備一份應急預案。如果大模型服務掛了怎么辦如果知識庫向量庫損壞怎么辦如果某個文檔的內容是錯誤信息被大量用戶檢索到怎么辦每一條都要有明確的響應動作。9. 下一步可以繼續(xù)深入的方向如果這篇文章的讀者也希望在企業(yè) AI 方向持續(xù)深入我覺得可以從以下幾個方面繼續(xù)學習大模型推理框架深入了解 vLLM、TensorRT-LLM 的原理和使用方式適合高并發(fā)場景。檢索增強生成RAG包括查詢改寫、重排序Rerank、混合檢索關鍵詞 向量等進階方向。Agent 架構如果你希望 AI 應用不只是“問答機器人”還要具備工具調用、多步任務規(guī)劃能力可以研究 Agent 架構設計。AI 應用的可觀測性標準比如如何評估生成內容的質量如何追蹤模型幻覺事件這些在生產(chǎn)環(huán)境一定會遇到。多模態(tài)如果后續(xù)文檔中包含圖片、掃描件需要多模態(tài)模型參與解析和生成。本文記錄的就是一次相對完整的企業(yè) AI 落地過程。不同團隊的技術棧、資源規(guī)模、業(yè)務約束都不一樣具體方案輸出了差異但思考問題的框架——從 Demo 到生產(chǎn)的差距在哪里、每一步?jīng)Q策的取舍依據(jù)是什么——是共通的。希望這篇復盤能幫正在做類似項目的你少踩一些坑。