最近和汽車行業(yè)的朋友交流時總繞不開一個問題國產(chǎn)大模型迭代這么快是不是又要讓車企和供應(yīng)商更“卷”我的觀點(diǎn)其實(shí)很明確大模型即使發(fā)展再快也不應(yīng)該被簡單當(dāng)作“壓成本、拼話術(shù)、堆演示”的內(nèi)卷工具。真正的價值是把過去依賴?yán)蠋煾到?jīng)驗(yàn)、需要反復(fù)翻手冊、跨系統(tǒng)查詢才能完成的業(yè)務(wù)改造成“人機(jī)協(xié)同”的新工作流。這篇文章不聊宏大敘事而是從工程視角出發(fā)用一套可復(fù)現(xiàn)的汽車售后知識助手示例把國產(chǎn)大模型接入業(yè)務(wù)系統(tǒng)的完整鏈路拆開模型選型、RAG 檢索增強(qiáng)、Function Calling 工具調(diào)用、API 服務(wù)封裝、生產(chǎn)部署建議。目標(biāo)是讓讀者既能理解概念也能拿到代碼跑通一個最小可用案例并知道如何避開常見工程坑。1. 為什么國產(chǎn)大模型的終點(diǎn)不是“內(nèi)卷工具”1.1 技術(shù)繁榮帶來的機(jī)會與誤區(qū)國產(chǎn)大模型確實(shí)處在快速迭代階段。Qwen 系列開源模型、DeepSeek、智譜、百川等都有很強(qiáng)的通用對話和推理能力同時各個云廠商也提供了兼容 OpenAI 格式的 API。這種局面讓企業(yè)可以用很低的上手成本做 AI 應(yīng)用開發(fā)。但機(jī)會越多誤區(qū)也越明顯。很多團(tuán)隊拿到大模型后第一反應(yīng)是“用它寫周報、寫話術(shù)、做客服自動回復(fù)”然后把響應(yīng)速度、上下文長度、參數(shù)規(guī)模當(dāng)作競爭指標(biāo)。這些動作也許能帶來短期的新鮮感但很難沉淀成真正的業(yè)務(wù)壁壘。尤其在汽車產(chǎn)業(yè)里一個錯誤回答可能會導(dǎo)致維修動作出錯一次無依據(jù)的“自動診斷”可能帶來售后責(zé)任風(fēng)險。所以大模型落地不能只看“能不能生成”還要看“依據(jù)是什么、誰來做最終確認(rèn)”。1.2 更值得落地的方向是長尾場景汽車產(chǎn)業(yè)真正值得投入的方向是信息找人、經(jīng)驗(yàn)復(fù)制的長尾場景。比如新車上市后售后技師遇到一個沒見過的故障碼過去需要翻維修手冊、查內(nèi)部知識庫、在工單系統(tǒng)里翻歷史案例運(yùn)氣不好還要打電話問總部專家。如果系統(tǒng)能把維修手冊、技術(shù)通報、歷史工單統(tǒng)一接入大模型通過檢索增強(qiáng)生成和 AI Agent 把信息快速匯總給技師再由技師判斷執(zhí)行這個效率提升是非常直觀的。這種場景不是“替代人”而是“輔助人”。它不追求讓 AI 獨(dú)立做出維修決定而是縮短人獲取正確信息的時間減少重復(fù)勞動。這也是本文示例要選“售后知識助手”的原因業(yè)務(wù)邊界清晰、知識庫相對封閉、價值容易量化。1.3 案例目標(biāo)本文要實(shí)現(xiàn)的示例是一個汽車售后問答 API。它包含三個能力根據(jù)維修手冊片段回答保養(yǎng)和故障排查問題。當(dāng)用戶詢問故障碼時通過 Function Calling 調(diào)用本地故障碼查詢函數(shù)。回答必須引用檢索到的資料資料不足時明確提示“轉(zhuǎn)人工處理”不允許編造。這樣一個案例麻雀雖小卻已經(jīng)覆蓋了大模型應(yīng)用開發(fā)、AI 工程實(shí)踐和模型部署的大部分關(guān)鍵知識點(diǎn)。2. 汽車產(chǎn)業(yè) AI 應(yīng)用的核心技術(shù)拆解2.1 RAG 為什么是業(yè)務(wù)落地的第一站RAGRetrieval-Augmented Generation檢索增強(qiáng)生成是目前大模型進(jìn)入企業(yè)業(yè)務(wù)系統(tǒng)最穩(wěn)妥的路徑。原因是企業(yè)真正有價值的知識往往不在通用大模型的訓(xùn)練數(shù)據(jù)里而是散落在維修手冊、設(shè)計文檔、歷史工單、實(shí)驗(yàn)報告中。如果不做 RAG直接讓大模型憑訓(xùn)練知識回答很容易出現(xiàn)“一本正經(jīng)地胡說八道”。做了 RAG 之后系統(tǒng)會先從知識庫里檢索出和用戶問題最相關(guān)的片段再把片段拼到 Prompt 中讓大模型基于這些片段回答。這里要理解一個關(guān)鍵點(diǎn)RAG 并不是把整個知識庫發(fā)給模型而是“先檢索、后生成”。檢索質(zhì)量直接決定了回答質(zhì)量。很多人以為 Prompt 寫得越長效果越好其實(shí)當(dāng)相關(guān)片段被淹沒在大量噪聲中時模型反而更容易答偏。2.2 AI Agent 與 Function Calling 的作用光有 RAG 還不夠。有些業(yè)務(wù)問題無法通過知識庫檢索解決而是需要調(diào)用已有系統(tǒng)。比如用戶問“幫我查一下 P0073 故障碼”這個故障碼的解釋可能存在售后系統(tǒng)中而不是維修手冊里。這時候就需要讓大模型具備“工具調(diào)用”能力。在 OpenAI 兼容接口中這個能力通常叫 Function Calling 或 Tool Calling。大模型負(fù)責(zé)理解用戶意圖把問題轉(zhuǎn)換成結(jié)構(gòu)化的函數(shù)參數(shù)然后由業(yè)務(wù)系統(tǒng)去執(zhí)行真實(shí)查詢最后再把查詢結(jié)果交給大模型組織成自然語言回復(fù)。在 AI Agent 架構(gòu)里這只是一個很小的循環(huán)模型決定調(diào)用什么工具系統(tǒng)執(zhí)行工具模型拿到工具結(jié)果后繼續(xù)回答。真實(shí)項(xiàng)目中 Agent 可能會包含多輪工具調(diào)用、狀態(tài)記憶、人工審批節(jié)點(diǎn)但底層機(jī)制是一樣的。2.3 為什么仍然需要人機(jī)協(xié)同無論是 RAG 還是 Function Calling本質(zhì)都是“降低人獲取信息的成本”而不是“替代人的責(zé)任”。汽車維修涉及安全、保修、責(zé)任認(rèn)定完全由模型自動輸出處理建議并直接執(zhí)行風(fēng)險非常高。因此工程上要設(shè)計人工審核節(jié)點(diǎn)。模型可以生成維修建議、整理工單摘要、推薦檢查步驟但最終是否執(zhí)行、是否下單、是否通知客戶必須由有資質(zhì)的人員確認(rèn)。這也是為什么我說大模型不應(yīng)該成為“內(nèi)卷工具”如果把它用于壓減人工審核環(huán)節(jié)短期看省了人力長期看可能把風(fēng)險成倍放大。3. 環(huán)境準(zhǔn)備與模型選型3.1 運(yùn)行環(huán)境本文示例代碼使用 Python 編寫這樣能最直觀地展示 embedding、檢索、Function Calling 的完整鏈路。你本地需要準(zhǔn)備Python 3.10 或更高版本。一個可用的國產(chǎn)大模型 API Key推薦阿里云百煉 DashScope或者 DeepSeek 開放平臺。一個支持 OpenAI 兼容協(xié)議的 SDK本文使用openaiPython SDK。FastAPI 與 Uvicorn 用于暴露 HTTP 接口。如果你更習(xí)慣 Java 技術(shù)棧后文也會給出 Spring AI 接入國產(chǎn)大模型的配置參考但完整示例以 Python 為主。版本方面不同框架迭代很快不建議照抄過舊或過新的版本號。建議安裝以下庫的最新穩(wěn)定版pip install openai fastapi uvicorn[standard] python-dotenv numpy如果你的網(wǎng)絡(luò)環(huán)境下載緩慢可以臨時切換為鏡像源但要注意鏡像源的同步時間。3.2 模型服務(wù)選擇國產(chǎn)大模型 API 普遍提供兩個關(guān)鍵能力文本生成和文本向量化。本文在示例中選擇 DashScope 的 OpenAI 兼容模式對話模型qwen-plus適合日常問答與工具調(diào)用。向量模型text-embedding-v3用于把維修手冊切分后的片段向量化。如果你使用 DeepSeek通常只需要修改LLM_BASE_URL為 DeepSeek 的接口地址并把CHAT_MODEL換成 DeepSeek 的模型名。但要注意不同平臺的向量模型能力不一樣如果你的平臺沒有提供 embedding 接口可以繼續(xù)使用 DashScope 或其他兼容平臺做向量化也可以在后續(xù)工程化階段替換為本地部署的 BGE 系列模型。下面是.env環(huán)境變量文件的示例LLM_API_KEYsk-你的密鑰 LLM_BASE_URLhttps://dashscope.aliyuncs.com/compatible-mode/v1 CHAT_MODELqwen-plus EMBEDDING_MODELtext-embedding-v3需要注意密鑰不要提交到 Git 倉庫。生產(chǎn)環(huán)境建議使用密鑰管理服務(wù)或 CI/CD 的 Secret 變量。3.3 項(xiàng)目結(jié)構(gòu)創(chuàng)建一個干凈的實(shí)驗(yàn)?zāi)夸浲暾Y(jié)構(gòu)如下car_rag_demo/ ├── .env ├── requirements.txt ├── manual.txt └── app.py其中manual.txt是模擬的維修手冊app.py是完整的 FastAPI 應(yīng)用和 RAG 邏輯。下面我們一步步實(shí)現(xiàn)。4. 完整實(shí)戰(zhàn)基于國產(chǎn)大模型構(gòu)建汽車售后知識助手4.1 需求分析與流程設(shè)計這個知識助手需要服務(wù)兩類問題。第一類是“知識查詢”例如“空調(diào)不制冷應(yīng)該先檢查什么”。系統(tǒng)先從維修手冊知識庫中檢索相關(guān)段落再把段落發(fā)送給大模型讓模型基于資料回答。第二類是“工具查詢”例如“幫我查一下 P0073 故障碼”。系統(tǒng)需要識別用戶意圖調(diào)用query_fault_code函數(shù)然后再把查詢結(jié)果整理成回答。完整業(yè)務(wù)流程可以拆成四步用戶輸入問題。系統(tǒng)對問題做向量化并在本地索引中檢索 top_k 條相關(guān)知識片段。把知識片段、工具定義、用戶問題一起發(fā)送給大模型。如果大模型返回工具調(diào)用指令則執(zhí)行本地函數(shù)并把結(jié)果回傳給大模型否則直接返回回答。之所以先檢索再發(fā)送是為了控制 Token 消耗也為了讓模型聚焦于與當(dāng)前問題最相關(guān)的信息。4.2 準(zhǔn)備維修手冊數(shù)據(jù)我們先準(zhǔn)備模擬的維修手冊數(shù)據(jù)。為了演示簡單這里只放兩份文檔。# 車內(nèi)空調(diào)無法制冷排查手冊 適用車型示例車型 X5 EV 故障現(xiàn)象出風(fēng)口風(fēng)量正常但制冷效果差。 排查步驟 1. 檢查空調(diào)壓縮機(jī)是否啟動。 2. 檢查制冷劑壓力靜態(tài)壓力低時補(bǔ)充制冷劑。 3. 檢查冷凝器表面是否堵塞。 4. 使用診斷儀讀取空調(diào)控制模塊故障碼。 # 制動異響排查手冊 適用車型示例車型 X5 EV 故障現(xiàn)象低速輕踩制動時有尖銳異響。 排查步驟 1. 檢查剎車片厚度。 2. 檢查剎車盤表面是否有溝槽。 3. 檢查制動卡鉗回位是否正常。 4. 若剎車片磨損到極限需要更換剎車片。實(shí)際項(xiàng)目中這些內(nèi)容應(yīng)該來自企業(yè)文檔系統(tǒng)、售后知識庫或技術(shù)通報。數(shù)據(jù)導(dǎo)入前最好做清洗去除重復(fù)章節(jié)、把掃描 PDF 轉(zhuǎn)成文本、統(tǒng)一術(shù)語表述。如果知識庫文件特別多需要先做任務(wù)拆分例如按車型、按系統(tǒng)、按故障類型建立獨(dú)立索引。4.3 編寫向量檢索模塊下面開始寫核心代碼。新建app.py先把依賴加載進(jìn)去import json import os from pathlib import Path import numpy as np from dotenv import load_dotenv from fastapi import FastAPI from openai import OpenAI from pydantic import BaseModel load_dotenv() API_KEY os.getenv(LLM_API_KEY) BASE_URL os.getenv(LLM_BASE_URL, https://dashscope.aliyuncs.com/compatible-mode/v1) CHAT_MODEL os.getenv(CHAT_MODEL, qwen-plus) EMBEDDING_MODEL os.getenv(EMBEDDING_MODEL, text-embedding-v3) if not API_KEY: raise RuntimeError(請在 .env 文件中配置 LLM_API_KEY) client OpenAI(api_keyAPI_KEY, base_urlBASE_URL) app FastAPI(title汽車售后知識助手)接下來定義知識庫類。這個類負(fù)責(zé)讀取文檔、切分文本、調(diào)用向量模型構(gòu)建索引并提供相似度檢索方法。class KnowledgeBase: def __init__(self, doc_path: str, chunk_size: int 300, overlap: int 30): self.doc_path Path(doc_path) self.chunk_size chunk_size self.overlap overlap self.chunks [] self.vectors np.array([]) def load_and_split(self): raw_text self.doc_path.read_text(encodingutf-8) sections [s.strip() for s in raw_text.split(\n\n) if s.strip()] chunks [] for section in sections: if len(section) self.chunk_size: chunks.append(section) else: start 0 while start len(section): end start self.chunk_size chunks.append(section[start:end]) start end - self.overlap self.chunks chunks def build_index(self): if not self.chunks: raise RuntimeError(請先調(diào)用 load_and_split) vectors [] batch_size 10 for i in range(0, len(self.chunks), batch_size): batch self.chunks[i:i batch_size] resp client.embeddings.create( modelEMBEDDING_MODEL, inputbatch ) vectors.extend([item.embedding for item in resp.data]) self.vectors np.array(vectors, dtypefloat32) def search(self, query: str, top_k: int 2): if self.vectors.size 0: raise RuntimeError(請先調(diào)用 build_index) resp client.embeddings.create( modelEMBEDDING_MODEL, input[query] ) query_vec np.array(resp.data[0].embedding, dtypefloat32) def _cosine(a, b): return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b) 1e-8)) scores [_cosine(query_vec, vec) for vec in self.vectors] top_idx np.argsort(scores)[-top_k:][::-1] return [{text: self.chunks[i], score: scores[i]} for i in top_idx]這里需要解釋幾個細(xì)節(jié)。第一文檔按段落切分而不是按空格切分這樣能保留語義完整性。chunk_size表示最大字符數(shù)overlap是相鄰片段的重疊長度。重疊字符可以避免一個完整句子被切斷后丟失上下文。第二向量化時把多個文本片段組成 batch 發(fā)送可以減少網(wǎng)絡(luò)請求次數(shù)提升索引構(gòu)建速度。這里 batch 大小取 10真實(shí)項(xiàng)目中要根據(jù) embedding 服務(wù)限制調(diào)整通?？梢栽?16 到 64 之間。第三相似度計算使用余弦相似度。對 embedding 向量先做歸一化在工業(yè)實(shí)現(xiàn)中可以直接用內(nèi)積代替余弦相似度速度會更快。但為了可讀性這里保留完整計算過程。4.4 實(shí)現(xiàn)故障碼工具調(diào)用接著定義模擬的故障碼數(shù)據(jù)庫和查詢函數(shù)。真實(shí)項(xiàng)目中這個函數(shù)會去調(diào)用 DMS 售后系統(tǒng)、診斷儀數(shù)據(jù)平臺或配件目錄服務(wù)。FAULT_CODE_DB { P0073: { name: 環(huán)境溫度傳感器電路高, advice: 檢查環(huán)境溫度傳感器及線束連接必要時更換傳感器。, }, C0501: { name: 空調(diào)壓縮機(jī)控制電路故障, advice: 檢查壓縮機(jī)繼電器、保險絲與線束重新上電后再次讀取故障碼。, }, } def query_fault_code(fault_code: str) - str: fault_code fault_code.strip().upper() if fault_code not in FAULT_CODE_DB: return f暫未收錄故障碼 {fault_code}請轉(zhuǎn)人工查詢。 item FAULT_CODE_DB[fault_code] return f故障碼{fault_code}含義{item[name]}建議{item[advice]}接下來定義 Function Calling 需要的工具描述。這個描述會被發(fā)送給大模型大模型根據(jù)用戶問題決定是否調(diào)用TOOLS [ { type: function, function: { name: query_fault_code, description: 查詢車輛故障碼的含義與維修建議, parameters: { type: object, properties: { fault_code: { type: string, description: 整車故障碼例如 P0073 } }, required: [fault_code] } } } ]工具描述必須足夠清晰尤其是description和參數(shù)描述。很多模型不觸發(fā) Function Calling并不是模型不行而是函數(shù)名和參數(shù)含義寫得模糊。例如“含義與維修建議”比“查詢”更能幫助模型判斷什么時候調(diào)用。4.5 編寫對話處理邏輯接下來實(shí)現(xiàn)核心對話邏輯。這一段負(fù)責(zé)拼接 Prompt、調(diào)用大模型、處理 Function Calling 中間結(jié)果。def ask(question: str): docs kb.search(question, top_k2) context \n\n.join( f[來源{i 1}]\n{d[text]} for i, d in enumerate(docs) ) messages [ { role: system, content: ( 你是一名汽車售后技術(shù)支持助手。 請優(yōu)先根據(jù)維修手冊資料回答不要編造資料中沒有的信息。 如果問題涉及故障碼請調(diào)用 query_fault_code 獲取結(jié)果。 如果資料不足請明確回復(fù)資料未覆蓋請轉(zhuǎn)人工處理。 f\n\n 維修手冊檢索結(jié)果 \n{context} ) }, { role: user, content: question } ] response client.chat.completions.create( modelCHAT_MODEL, messagesmessages, toolsTOOLS, temperature0.2, ) message response.choices[0].message if message.tool_calls: messages.append({ role: assistant, content: message.content, tool_calls: [ { id: tool_call.id, type: function, function: { name: tool_call.function.name, arguments: tool_call.function.arguments, }, } for tool_call in message.tool_calls ], }) for tool_call in message.tool_calls: tool_name tool_call.function.name args json.loads(tool_call.function.arguments or {}) if tool_name query_fault_code: tool_result query_fault_code(args.get(fault_code, )) else: tool_result f未知工具{tool_name} messages.append({ role: tool, tool_call_id: tool_call.id, content: tool_result, }) response client.chat.completions.create( modelCHAT_MODEL, messagesmessages, temperature0.2, ) message response.choices[0].message return { answer: message.content, references: [d[text] for d in docs], meta: { chat_model: CHAT_MODEL, embedding_model: EMBEDDING_MODEL, top_k: len(docs), }, }這段代碼有幾個容易出錯的地方。第一如果有 Tool Call必須先把 assistant 的角色消息追加到 messages再追加 tool 消息。否則 API 會報錯因?yàn)?tool 消息必須對應(yīng)一個已經(jīng)存在的 assistant Tool Call。第二tool_call.function.arguments是 JSON 字符串需要先解析成字典。解析失敗時要做好異常處理實(shí)測中偶爾會出現(xiàn)參數(shù)格式不規(guī)范的情況。第三第二輪調(diào)用時不需要再帶tools也可以。但為了保險建議繼續(xù)攜帶tools這樣模型如果還需要查其他故障碼依然可以繼續(xù)調(diào)用。在實(shí)際項(xiàng)目里應(yīng)該用循環(huán)限制最多調(diào)用 2 到 3 次避免 Agent 陷入死循環(huán)。4.6 封裝 FastAPI 接口最后加上兩個 Pydantic 模型和 HTTP 路由。class ChatRequestBody(BaseModel): question: str class ChatResponseBody(BaseModel): answer: str references: list[str] [] meta: dict {} app.post(/chat, response_modelChatResponseBody) def chat(req: ChatRequestBody): if not req.question.strip(): return ChatResponseBody(answer問題不能為空) result ask(req.question) return ChatResponseBody( answerresult[answer], referencesresult[references], metaresult[meta], ) kb KnowledgeBase(manual.txt) kb.load_and_split() kb.build_index()這里把索引初始化放在了模塊加載階段簡單直接適合演示。但在生產(chǎn)環(huán)境中最好把知識庫索引放在獨(dú)立服務(wù)中例如 FAISS、Milvus 或 PgVector并通過監(jiān)聽文檔更新事件觸發(fā)重新索引。4.7 運(yùn)行與驗(yàn)證在項(xiàng)目目錄下創(chuàng)建.env文件然后啟動服務(wù)uvicorn app:app --reload --host 0.0.0.0 --port 8000啟動成功后可以先測試知識問答curl -X POST http://127.0.0.1:8000/chat \ -H Content-Type: application/json \ -d {question: 空調(diào)不制冷應(yīng)該先檢查什么}預(yù)期回答會引用檢索到的手冊片段內(nèi)容大致是先檢查空調(diào)壓縮機(jī)是否啟動再檢查制冷劑壓力等。接著測試故障碼查詢curl -X POST http://127.0.0.1:8000/chat \ -H Content-Type: application/json \ -d {question: 幫我查一下 P0073 故障碼}如果 Function Calling 鏈路正常模型會先調(diào)用query_fault_code(P0073)然后根據(jù)返回結(jié)果生成一段自然語言回答。返回的references字段里可能沒有與故障碼相關(guān)的知識片段這是正常的因?yàn)楣收洗a數(shù)據(jù)來自工具調(diào)用而不是維修手冊。5. 從 Demo 到可上線模型部署與工程化建議5.1 從 API 調(diào)用到私有化部署Demo 階段使用云廠商大模型 API 很合適方便快速驗(yàn)證效果。但很多車企對數(shù)據(jù)安全要求較高不愿意把維修手冊、車輛 VIN、故障數(shù)據(jù)發(fā)送到外部 API這時候就需要私有化部署開源模型。以 Qwen2.5 系列開源模型為例常見的推理部署方案是 vLLM。它支持高并發(fā)推理并提供 OpenAI 兼容的/v1/chat/completions接口。假設(shè)你有一臺帶 GPU 的 Linux 服務(wù)器可以先安裝 vLLM然后執(zhí)行vllm serve Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --served-model-name qwen2.5-7b-instruct啟動后調(diào)用方只需要修改LLM_BASE_URL為http://your-server:8000/v1CHAT_MODEL改為qwen2.5-7b-instruct代碼無需大改即可切換。這也是早期選擇“OpenAI 兼容協(xié)議”的好處。embedding 模型同樣可以本地化部署。比如部署本地 BGE-M3 服務(wù)再將EMBEDDING_MODEL和調(diào)用地址指到本地服務(wù)從而實(shí)現(xiàn)全鏈路數(shù)據(jù)不出內(nèi)網(wǎng)。5.2 Java Spring AI 接入方式參考如果團(tuán)隊技術(shù)棧是 Java 后端可以考慮使用 Spring AI。它是一個將 AI 模型能力抽象成 Spring Boot Starter 的框架可以讓我們用比較熟悉的配置方式接入 OpenAI 兼容接口。下面給出參考配置spring.ai.openai.api-key${DASHSCOPE_API_KEY} spring.ai.openai.base-urlhttps://dashscope.aliyuncs.com/compatible-mode/v1 spring.ai.openai.chat.options.modelqwen-plus注意Spring AI 版本迭代比較快不同版本的配置前綴和ChatClientAPI 可能存在差異。建議以當(dāng)前使用的 Spring AI 官方文檔為準(zhǔn)。代碼層面可以封裝一個 ControllerRestController public class ChatController { private final ChatClient chatClient; public ChatController(ChatClient.Builder builder) { this.chatClient builder.build(); } GetMapping(/chat) public String chat(RequestParam String question) { return chatClient.prompt() .user(question) .call() .content(); } }這個例子只覆蓋最基本的對話功能。要在 Java 服務(wù)里實(shí)現(xiàn) RAG 和 Function Calling還需要把向量化、向量檢索、工具函數(shù)等邏輯整合進(jìn)去。工程上建議先通過 Python 快速驗(yàn)證效果再在 Java 側(cè)做正式重構(gòu)不要一上來就在 Java 里堆代碼。5.3 評測、監(jiān)控與降級上線前最容易被忽略的是評測。沒有評測集就沒有辦法回答“這次換 Prompt 后效果是變好還是變壞”。可以整理 100 到 500 條真實(shí)售后問題分成幾類可以在維修手冊中找到答案的問題。需要調(diào)用故障碼工具的問題。知識庫覆蓋不到、應(yīng)該拒絕回答的問題。需要多輪上下文才能回答的問題。然后對每個問題預(yù)先寫好標(biāo)準(zhǔn)答案和關(guān)鍵檢查點(diǎn)形成回歸評測集。每次修改 Prompt、調(diào)整檢索參數(shù)、更換模型后都跑一遍評測集。重點(diǎn)看三個指標(biāo)答案準(zhǔn)確率、引用覆蓋率、拒答準(zhǔn)確率。答案準(zhǔn)確率衡量回答內(nèi)容是否與標(biāo)準(zhǔn)答案一致引用覆蓋率衡量模型是否正確使用了檢索到的資料拒答準(zhǔn)確率衡量模型能否在資料不足時主動說“不知道”。生產(chǎn)鏈路還必須加監(jiān)控和降級。如果大模型 API 超時或者向量數(shù)據(jù)庫不可用接口不應(yīng)該直接報錯而應(yīng)該降級為“搜索模式”只返回檢索到的知識片段或者提示用戶稍后重試。每次請求的模型、Prompt 版本、知識庫版本、Token 消耗、響應(yīng)延遲、人工修改結(jié)果都應(yīng)該記錄到日志或數(shù)據(jù)庫中否則后續(xù)很難排查線上問題。6. 常見問題與排查思路問題現(xiàn)象常見原因解決思路調(diào)用 API 返回 401API Key 錯誤或沒有對應(yīng)模型權(quán)限檢查.env中的密鑰、服務(wù)所在區(qū)域、模型是否開通返回內(nèi)容與知識庫無關(guān)RAG 檢索結(jié)果不相關(guān)或 Prompt 約束不足提高 top_k檢查文檔切分質(zhì)量降低溫度參數(shù)模型回答編造資料外內(nèi)容Prompt 沒有明確拒絕或知識庫檢索為空在 System Prompt 中要求“資料未覆蓋必須轉(zhuǎn)人工”并設(shè)置兜底邏輯Function Calling 不觸發(fā)工具描述不清晰或模型不支持該格式精簡函數(shù)描述增加示例參數(shù)嘗試換更強(qiáng)模型報錯 tool 消息沒有對應(yīng) assistant未把 assistant Tool Call 記錄追加到 messages在追加 tool 消息前先追加包含 tool_calls 的 assistant 消息embedding 模型不能調(diào)用當(dāng)前平臺沒有提供向量模型改用 DashScope text-embedding-v3或本地部署 BGE 系列模型知識庫更新后回答仍是舊內(nèi)容索引沒有重建建立文檔變更監(jiān)聽觸發(fā)重新切分、重新 embedding 并更新索引檢索結(jié)果返回空文檔切分后為空或 embedding 維度不一致檢查知識庫文件編碼建議統(tǒng)一為 UTF-8Spring AI 配置不生效版本不同導(dǎo)致配置前綴變化檢查依賴版本以官方文檔對應(yīng)章節(jié)為準(zhǔn)接口響應(yīng)太慢向量檢索全量掃描或模型推理耗時長生產(chǎn)環(huán)境使用向量數(shù)據(jù)庫對模型推理做緩存和超時控制這里的核心思路是先區(qū)分問題出在檢索鏈路、模型鏈路還是系統(tǒng)鏈路。檢索鏈路問題看召回內(nèi)容模型鏈路問題看 Prompt 和模型參數(shù)系統(tǒng)鏈路問題看日志、超時和熔斷配置。7. 最佳實(shí)踐讓 AI 成為“助手”而非“內(nèi)卷工具”7.1 以業(yè)務(wù)指標(biāo)作為驗(yàn)收標(biāo)準(zhǔn)在汽車產(chǎn)業(yè)做大模型應(yīng)用不應(yīng)該用“上線了多少 AI 功能”來驗(yàn)收而應(yīng)該用“每張工單平均查詢時間下降了多少”“首次修復(fù)率是否提升”“技師培訓(xùn)周期是否縮短”來衡量。如果某個 AI 功能上線后只是讓系統(tǒng)多了一個聊天框但業(yè)務(wù)人員根本不用那它本質(zhì)上就是內(nèi)卷。反過來如果系統(tǒng)能讓新技師在遇到陌生故障時少花一半時間找到維修資料這個 AI 應(yīng)用就有明確價值。所以在做任何一個方向之前先問一個問題這個功能讓誰的工作更簡單了7.2 權(quán)限、安全與數(shù)據(jù)合規(guī)汽車行業(yè)涉及的數(shù)據(jù)敏感度高車型配置、維修記錄、客戶信息、供應(yīng)鏈信息都不能隨意輸入外部大模型。建議遵循最小權(quán)限原則普通賬號只能查詢與自己工作相關(guān)的知識庫。涉及客戶隱私數(shù)據(jù)的字段在進(jìn)入大模型之前先脫敏。系統(tǒng)日志中不記錄完整 Prompt 和完整回復(fù)只記錄關(guān)鍵統(tǒng)計信息。私有化部署時做好模型服務(wù)的網(wǎng)絡(luò)隔離和賬號審計。外部 API 調(diào)用前由安全團(tuán)隊審核數(shù)據(jù)流向。如果未來要讓 AI 自動寫維修工單或自動下單必須增加人工審批節(jié)點(diǎn)。AI 可以起草內(nèi)容但“確認(rèn)”這個動作必須由人完成。7.3 長期維護(hù)與 Prompt 版本管理很多團(tuán)隊把 Prompt 當(dāng)成“寫一次就永久有效”的配置這是錯誤想法。業(yè)務(wù)知識在變、模型版本在變、用戶提問方式在變Prompt 和知識庫都需要持續(xù)維護(hù)。工程上可以這樣管理每一個 Prompt 都有一個版本號例如aftersale_qa_v23。每次修改 Prompt 都要在評測集上跑一遍記錄效果變化。知識庫文檔更新時記錄來源、更新時間、負(fù)責(zé)人。線上調(diào)用時在日志中記錄 Prompt 版本方便問題回溯。大模型 API 升級模型版本前先在預(yù)發(fā)環(huán)境跑評測集再決定是否切換。這聽起來像傳統(tǒng)軟件的版本管理但確實(shí)是大模型應(yīng)用穩(wěn)定運(yùn)行的關(guān)鍵。不要相信“Prompt 看起來差不多所以不用測試”很多線上效果下降都是因?yàn)闄z索到的知識片段變了而不是模型變笨了。7.4 落地節(jié)奏建議如果今天要啟動一個汽車產(chǎn)業(yè)大模型項(xiàng)目我建議按這樣的節(jié)奏推進(jìn)第一步選一個明確的小場景例如“售后故障碼查詢輔助”不要一上來就做全公司知識中臺。第二步用本文示例快速跑通完整鏈路確認(rèn) API、模型、向量檢索都可行。第三步整理 50 條真實(shí)問題設(shè)計簡單的評測集記錄當(dāng)前效果基線。第四步逐步接入真實(shí)知識庫和業(yè)務(wù)系統(tǒng)每接入一個數(shù)據(jù)源就重新跑評測。第五步設(shè)計人工審核和反饋收集機(jī)制讓一線人員可以在頁面上標(biāo)記“回答有用”或“回答錯誤”。當(dāng)積累了一定量的真實(shí)反饋后你會發(fā)現(xiàn)系統(tǒng)改進(jìn)方向不再是“換更大的模型”而是“把知識庫組織得更好把工具調(diào)用設(shè)計得更穩(wěn)把人機(jī)協(xié)作流程打磨得更順”。這才是國產(chǎn)大模型在汽車產(chǎn)業(yè)里更有意義的路徑不是造一個內(nèi)卷工具而是造一個能放大一線工程師、技師和客服人員能力的助手。如果你正在做類似的大模型應(yīng)用開發(fā)希望這篇文章能幫你少走彎路。代碼只是一個起點(diǎn)真正有價值的是你對業(yè)務(wù)場景的理解、對評測體系的堅持以及對“人機(jī)協(xié)同邊界”的清醒認(rèn)識。