很多同行都在做生成式人工智能Generative AI服務(wù)但真正能跑通、能上線、能給業(yè)務(wù)帶來增量的其實(shí)不多。這篇文章我想把生成式人工智能服務(wù)從技術(shù)選型、數(shù)據(jù)準(zhǔn)備到落地調(diào)優(yōu)的關(guān)鍵要點(diǎn)拆開講一遍同時附上一份中英雙語術(shù)語對照方便你在實(shí)際項(xiàng)目里直接查、直接抄。不管你是剛接觸大模型Large Language ModelLLM的開發(fā)者還是需要給團(tuán)隊(duì)做技術(shù)判斷的負(fù)責(zé)人這篇內(nèi)容都能給你一條明確的落地路徑。我會重點(diǎn)講清楚每個步驟背后的“為什么”而不是只給一堆操作命令。1. 生成式AI服務(wù)的技術(shù)底座與選型思路1.1 先搞懂生成式AI服務(wù)的核心能力邊界生成式人工智能服務(wù)本質(zhì)上是利用深度生成模型根據(jù)用戶的輸入指令Prompt自動生成文本、代碼、圖像、音視頻等內(nèi)容。跟傳統(tǒng)的判別式AI不同生成式模型輸出的不是分類標(biāo)簽而是一段全新的、有概率性的內(nèi)容。所以你在設(shè)計服務(wù)架構(gòu)時第一件事就是接受一個現(xiàn)實(shí)模型的輸出不是確定的。同樣一個問題十次請求大概率有十次措辭差異甚至偶爾會出現(xiàn)事實(shí)性錯誤。這不是Bug而是生成式模型的工作方式?jīng)Q定的。所有后續(xù)的緩存設(shè)計、用戶提示Prompt設(shè)計、輸出校驗(yàn)都是圍繞這個“不確定性”展開的。技術(shù)底座通常包含這幾類組件基座模型Base Model負(fù)責(zé)理解和生成的核心引擎例如對話模型、文生圖模型。推理引擎Inference Engine把模型跑起來并對外提供接口的中間層常見的有vLLM、TGI、SGLang等。向量數(shù)據(jù)庫Vector Database用于存放和檢索知識庫中的向量化內(nèi)容支撐檢索增強(qiáng)生成RAG。應(yīng)用框架Application Framework把模型、數(shù)據(jù)、工具編排起來常見的包括LangChain、LlamaIndex等。1.2 基座模型選型通用模型與垂直模型的權(quán)衡選型是一切的起點(diǎn)也是最容易踩坑的地方。很多團(tuán)隊(duì)一上來就追求“參數(shù)最大”的模型結(jié)果發(fā)現(xiàn)部署成本高到無法承受響應(yīng)速度又不達(dá)標(biāo)業(yè)務(wù)根本跑不起來。我的建議是按“任務(wù)復(fù)雜度×調(diào)用頻率×數(shù)據(jù)敏感性”三個維度來選簡單任務(wù)關(guān)鍵詞提取、文案潤色、標(biāo)題生成參數(shù)量在7B到14B之間的小模型完全夠用可以本地化部署。中等任務(wù)復(fù)雜對話、結(jié)構(gòu)化信息抽取建議使用70B級別的開源模型或者調(diào)用成熟的API接口。高難度任務(wù)長文檔分析、復(fù)雜推理、代碼生成才需要考慮更大規(guī)模的模型或頂尖閉源模型。數(shù)據(jù)敏感性也要重點(diǎn)考慮。如果服務(wù)涉及企業(yè)內(nèi)部數(shù)據(jù)、用戶隱私數(shù)據(jù)本地化部署往往是唯一選項(xiàng)如果只是公開內(nèi)容生成調(diào)用API的成本優(yōu)勢就非常明顯。我實(shí)測過很多次中小團(tuán)隊(duì)最容易犯的錯誤是拿最聰明的模型去做最瑣碎的活。模型越大單次調(diào)用成本越高響應(yīng)延遲也越大。用“殺雞用牛刀”的方式做服務(wù)成本賬單會教你做人。2. 服務(wù)落地中的核心實(shí)操要點(diǎn)2.1 數(shù)據(jù)準(zhǔn)備與知識庫建設(shè)決定服務(wù)質(zhì)量的上限生成式AI服務(wù)的質(zhì)量一半靠模型一半靠數(shù)據(jù)。尤其是做知識庫問答類服務(wù)數(shù)據(jù)不進(jìn)庫模型就只能是“嘴硬的空架子”什么問題都敢編。知識庫建設(shè)的核心流程分四步數(shù)據(jù)清洗把原始文檔中的頁眉頁腳、亂碼、重復(fù)段落、無意義符號全部去掉。這一步看似簡單但直接影響切分效果。文本切分Chunking按語義邊界把長文檔切成固定大小的文本塊常見策略是按段落、標(biāo)題、固定字符數(shù)切分。切得太大會稀釋檢索精度切得太小會丟失上下文。向量化Embedding用嵌入模型把每個文本塊轉(zhuǎn)成向量存進(jìn)向量數(shù)據(jù)庫。嵌入模型的選擇很關(guān)鍵中文場景下可以考慮bge系列、m3e系列等針對中文優(yōu)化的模型。索引構(gòu)建給向量庫建好索引設(shè)置合適的相似度檢索算法比如余弦相似度、內(nèi)積等。有一點(diǎn)很多人沒注意到切分策略要跟著下游任務(wù)走。如果你的業(yè)務(wù)是“文檔問答”最好按文檔原有的標(biāo)題和段落層級切分而不是純按固定字符數(shù)硬切否則檢索出來的片段經(jīng)常是半句話模型想答好也難。2.2 Prompt工程花小錢辦大事的關(guān)鍵Prompt是用戶與模型交互的接口也是性價比最高的調(diào)優(yōu)手段。一個結(jié)構(gòu)良好的Prompt能直接提升輸出質(zhì)量而且不需要額外訓(xùn)練模型。我常用的Prompt結(jié)構(gòu)包含四個要素角色設(shè)定Role告訴模型“你是一個資深的技術(shù)文檔工程師”。任務(wù)描述Task明確說明需要完成什么任務(wù)要輸出什么格式。約束條件Constraint寫明不許怎么做比如“不要編造數(shù)據(jù)”“不要超過200字”。輸入內(nèi)容Input把需要處理的原始內(nèi)容放進(jìn)來。實(shí)操中我建議把“約束條件”寫在Prompt的后半部分靠近生成位置。因?yàn)槟Ｐ蛯﹄x當(dāng)前位置越近的文本關(guān)注度越高關(guān)鍵約束放后面被遵循的幾率更大。另外如果你在用RAG方案Prompt里一定要帶上“檢索到的參考資料”并且明確告訴模型“優(yōu)先參考給定資料資料中找不到答案時直接說明不知道”。這個簡單技巧能把幻覺率降下一大截。2.3 微調(diào)的必要性與分寸把握很多團(tuán)隊(duì)動不動就想微調(diào)模型但我得潑盆冷水微調(diào)不是萬能的而且成本不低。大多數(shù)業(yè)務(wù)場景先做好Prompt和RAG就足以解決80%的問題。什么時候才真的需要微調(diào)模型輸出風(fēng)格與業(yè)務(wù)要求嚴(yán)重不符比如要求“嚴(yán)謹(jǐn)?shù)暮贤瑮l款”模型老是“口語化發(fā)揮”。需要模型穩(wěn)定按特定格式輸出結(jié)構(gòu)化數(shù)據(jù)而Prompt怎么調(diào)都不穩(wěn)定。希望模型學(xué)會業(yè)務(wù)內(nèi)的專業(yè)術(shù)語和專有名詞比如企業(yè)內(nèi)部產(chǎn)品代號、醫(yī)療術(shù)語等。微調(diào)方案上我推薦優(yōu)先嘗試LoRALow-Rank Adaptation這類參數(shù)高效微調(diào)方法。它只訓(xùn)練一小部分參數(shù)顯存需求低、訓(xùn)練速度快效果在很多場景下已經(jīng)接近全參微調(diào)。等LoRA驗(yàn)證有效再考慮是否值得做更大的投入。2.4 服務(wù)端架構(gòu)與并發(fā)設(shè)計生成式AI服務(wù)和傳統(tǒng)API服務(wù)最大的區(qū)別在于推理請求的耗時特別長而且顯存占用高。如果你用傳統(tǒng)“一個請求一個線程”的思路來做很容易被并發(fā)打爆。幾個我踩過坑之后的經(jīng)驗(yàn)用異步推理框架vLLM等框架自帶Continuous Batching連續(xù)批處理技術(shù)能把多個請求拼在一個批次里推理大幅提高吞吐。設(shè)置合理的超時和排隊(duì)機(jī)制給用戶端一個“排隊(duì)中”的反饋比讓用戶干等要好得多。做緩存層把常見的重復(fù)請求做語義級緩存命中后直接返回歷史結(jié)果能省一大筆推理成本。比如“產(chǎn)品功能介紹”這類問題答案基本穩(wěn)定緩存命中率很高。3. 實(shí)操案例從零搭建一個企業(yè)內(nèi)部知識問答助手這一部分我拿一個實(shí)際做過的項(xiàng)目來還原完整流程需求是給企業(yè)內(nèi)部搭建一個基于產(chǎn)品文檔的問答助手讓員工通過自然語言提問就能查到制度、操作手冊和技術(shù)規(guī)范。3.1 第一步需求拆解與方案定型需求方給的原話是“弄個機(jī)器人把咱們的文檔都喂進(jìn)去員工想問啥就問啥?！边@句話聽著簡單但如果不拆清楚就動手后面必返工。我把它拆成四個可執(zhí)行指標(biāo)知識范圍涵蓋三個產(chǎn)品線的操作手冊、FAQ、故障處理文檔約1200篇。問答形式支持中文自然語言提問答案需要標(biāo)注引用來源。響應(yīng)要求首字響應(yīng)時間小于3秒單次問答完整耗時小于15秒。部署環(huán)境內(nèi)網(wǎng)部署不允許調(diào)用外部API。因?yàn)椴辉试S外部API方案直接定為本地部署開源模型 私有向量數(shù)據(jù)庫 RAG。3.2 第二步數(shù)據(jù)清洗和知識庫構(gòu)建原始文檔有一大半是PDF直接從里面抽文本出來格式亂、有亂碼還有重復(fù)內(nèi)容。為了洗干凈這批數(shù)據(jù)我分了三道工序來做。第一道轉(zhuǎn)換與解壓。用PDF解析工具把每一頁轉(zhuǎn)成純文本同時記錄頁碼信息。過程中發(fā)現(xiàn)很多掃描版PDF文本根本抽不出來只能先用OCR光學(xué)字符識別過一遍再進(jìn)入后續(xù)流程。第二道清洗與去重。寫了一個清洗腳本把空行、不可見字符、頁眉頁腳水印全部去掉。按文本相似度做了一遍全局去重結(jié)果發(fā)現(xiàn)有大概百分之十幾的文檔內(nèi)容重復(fù)出現(xiàn)在不同文件里這些不處理檢索時會造成嚴(yán)重的重復(fù)干擾。第三道結(jié)構(gòu)與切分。這1200篇文檔里手冊類文檔有清晰的章節(jié)結(jié)構(gòu)不適合固定字符切分。我先把每篇文檔的目錄結(jié)構(gòu)解析出來然后按“標(biāo)題層級段落”先生成候選片段再對超過500字的片段做二次切分。切分完之后全部向量化存入向量數(shù)據(jù)庫。3.3 第三步模型部署與向量化選型模型最終選了Qwen系列的開源權(quán)重版本7B級別。選它的原因很簡單中文效果足夠、社區(qū)活躍、量化和部署資料非常全。部署時直接用vLLM做推理服務(wù)開一個HTTP接口給上層應(yīng)用調(diào)用。模型加載時做了一次4-bit量化用GPTQ方案把顯存占用從原始全精度的約14GB壓到了5GB左右這樣一臺顯卡比較舊的服務(wù)器也能穩(wěn)定跑。向量化模型選了bge-base-zh-v1.5。這里有個很多人容易忽略的細(xì)節(jié)向量化模型要和檢索場景匹配。bge系列默認(rèn)適合短文本檢索而我切出來的文檔片段平均有300到500個字符所以我在向量化時對長文本也做了歸一化處理并且把查詢文本和文檔文本用不同的前綴區(qū)分開。這樣改完后檢索準(zhǔn)確率明顯上升。3.4 第四步Prompt設(shè)計與問答鏈路聯(lián)調(diào)問答鏈路的邏輯是用戶提問 → 查詢改寫 → 向量檢索 → 拼裝Prompt → 模型生成 → 輸出返回。查詢改寫是容易被忽略但很有用的一步。員工提問常常是口語化的比如“那個報銷流程咋走來著”直接用這句話去檢索向量庫效果通常不好。我在檢索前先讓模型把口語問題改寫成一個更規(guī)范、更適合檢索的查詢語句然后用改寫后的語句去做向量檢索命中率提升很明顯。拼裝Prompt時我固定用下面這個模板你是一名企業(yè)內(nèi)部知識庫問答助手。請嚴(yán)格依據(jù)提供的參考資料回答用戶問題。 參考資料 檢索到的文檔片段 用戶問題 用戶原始問題 回答要求 1. 答案必須來自參考資料不得自行編造。 2. 如果參考資料中找不到答案請明確回答“資料庫中暫未找到相關(guān)信息”。 3. 請盡量使用口語化、簡潔的表達(dá)。 4. 在回答末尾標(biāo)注引用來源的文檔名稱和頁碼。整個鏈路調(diào)通后我拿100個業(yè)務(wù)真實(shí)問題做了一輪評測把回答結(jié)果分成了“準(zhǔn)確”“部分準(zhǔn)確”“錯誤”三檔。初版“準(zhǔn)確”率大約在68%后來通過調(diào)整檢索TopK參數(shù)、優(yōu)化切分粒度、細(xì)化Prompt約束跑到了85%以上。3.5 第五步效果評測與持續(xù)優(yōu)化評測是把關(guān)質(zhì)量的核心手段不能只靠人肉看幾條就完事。我搭了一個簡易評測腳本對每個問題同時記錄三樣?xùn)|西檢索命中的文檔片段、模型生成的答案、人工標(biāo)注的準(zhǔn)確率。評測之后發(fā)現(xiàn)錯誤回答主要集中在這兩類情況問題涉及多份文檔交叉內(nèi)容比如“新員工的報銷額度和差旅標(biāo)準(zhǔn)”單看命中的某一個片段答不全。問題包含了文檔里沒有的具體數(shù)值模型開始自行推斷。針對第一類我把檢索的TopK從原來的3調(diào)到6并且把多片段在Prompt里的排列順序按相關(guān)度重新排序再讓模型先綜合分析所有參考資料再作答針對第二類我在Prompt里加了一條硬性約束“涉及數(shù)字和日期時必須引用原文檔原文否則即視為未找到”。這兩處改動上線后“準(zhǔn)確”率漲了約8個百分點(diǎn)。所以說原來滿腦子想著“給模型做微調(diào)”的項(xiàng)目最后靠結(jié)構(gòu)化的知識庫和Prompt優(yōu)化就已經(jīng)達(dá)到了業(yè)務(wù)驗(yàn)收標(biāo)準(zhǔn)微調(diào)自然就不需要了。先把檢索和提示做扎實(shí)比一上來就動模型訓(xùn)練要劃算得多。4. 常見問題與排查技巧實(shí)錄4.1 模型回答出現(xiàn)幻覺怎么辦幻覺Hallucination是生成式AI服務(wù)最討厭的問題模型一本正經(jīng)地編出不存在的事實(shí)。我的排查順序是先看檢索質(zhì)量。打開日志看看模型拿到的那幾份參考資料和用戶問題是否真正相關(guān)。如果檢索到的資料本身就是無關(guān)的模型只能瞎編。再檢查Prompt約束。有沒有明確寫“不準(zhǔn)編造”有沒有要求“找不到就承認(rèn)找不到”很多時候加上這句話幻覺率就能降一半。最后看模型大小。7B級別的小模型在復(fù)雜任務(wù)上的幻覺率明顯高于大模型如果業(yè)務(wù)場景對真實(shí)性要求極高可能需要換更大的模型或者對輸出內(nèi)容增加二次校驗(yàn)。4.2 響應(yīng)速度慢到用戶崩潰速度問題的原因往往不在模型本身而是在鏈路設(shè)計上。排查要點(diǎn)文本切分是否太大如果單個片段長達(dá)上千字符模型一次推理要處理的Token數(shù)就很多響應(yīng)自然慢。檢索時是否一次撈太多文檔TopK設(shè)為10以上時Prompt會被塞得很長響應(yīng)時間成倍上升。部署時是否開了流式輸出改成流式輸出Streaming Output用戶看到的是逐字出來的結(jié)果主觀等待感會大幅降低。服務(wù)器顯存是否觸發(fā)了頻繁換入換出如果顯存不夠模型權(quán)重在CPU和GPU之間來回搬會慢到懷疑人生。4.3 向量檢索命中率低答案東拉西扯這個問題的根源通常是“問法”和“文檔寫法”差異太大。員工的問法口語化文檔里的表達(dá)卻是嚴(yán)謹(jǐn)書面語兩邊的語義空間隔著一條河。我常用的對策是查詢改寫加同義詞擴(kuò)展。讓模型把口語問題改寫成文檔風(fēng)格的關(guān)鍵詞組合再對改寫結(jié)果做一次同義詞擴(kuò)充比如“報銷”同時擴(kuò)充為“費(fèi)用報銷”“報銷流程”“報銷申請”。擴(kuò)充后一次性發(fā)起多條檢索請求把結(jié)果合并去重再返回給大模型。4.4 并發(fā)一高服務(wù)直接崩這種情況十有八九是推理框架沒選對或者壓根沒用批處理。我在早期項(xiàng)目里直接用PyTorch原生接口部署模型一個請求占一份顯存并發(fā)一過5就崩。后來換成vLLM并開啟Continuous Batching同樣一張卡并發(fā)到了20也穩(wěn)如老狗。如果你的部署環(huán)境受限至少也要在應(yīng)用層加個請求隊(duì)列控制并發(fā)數(shù)量給后端減壓。5. 中英雙語術(shù)語對照速查表考慮到很多團(tuán)隊(duì)要寫方案、發(fā)郵件、跟跨部門協(xié)作我把生成式AI服務(wù)里的高頻核心術(shù)語整理成了一份中英對照方便你直接引用和查閱。中文術(shù)語英文術(shù)語簡要說明生成式人工智能Generative AI能夠生成新內(nèi)容的人工智能技術(shù)總稱大語言模型Large Language Model (LLM)以海量文本訓(xùn)練的語言生成模型基座模型Base Model未經(jīng)任務(wù)定制化訓(xùn)練的原始模型推理引擎Inference Engine負(fù)責(zé)運(yùn)行模型并輸出結(jié)果的系統(tǒng)組件提示詞Prompt用戶輸入給模型的指令文本提示工程Prompt Engineering設(shè)計和優(yōu)化提示詞以提升輸出質(zhì)量檢索增強(qiáng)生成Retrieval-Augmented Generation (RAG)先檢索知識庫再指導(dǎo)模型生成的方案向量化Embedding將文本轉(zhuǎn)換成的稠密向量表示向量數(shù)據(jù)庫Vector Database存儲和檢索高維向量的數(shù)據(jù)庫系統(tǒng)語義緩存Semantic Caching按語義相似度命中并復(fù)用歷史結(jié)果微調(diào)Fine-tuning用業(yè)務(wù)數(shù)據(jù)繼續(xù)訓(xùn)練模型以適應(yīng)特定任務(wù)低秩適配Low-Rank Adaptation (LoRA)一種高效輕量的模型微調(diào)方法量化Quantization降低模型參數(shù)精度以節(jié)省顯存和加速推理幻覺Hallucination模型生成與事實(shí)不符內(nèi)容的現(xiàn)象流式輸出Streaming Output逐字逐句輸出結(jié)果降低用戶等待感文本切分Chunking將長文檔拆成適合檢索的片段連續(xù)批處理Continuous Batching動態(tài)拼批多個請求共同推理的技術(shù)上下文窗口Context Window模型單次能夠處理的文本長度范圍多模態(tài)模型Multimodal Model同時支持文本、圖像、音視頻等輸入輸出的模型人工反饋強(qiáng)化學(xué)習(xí)Reinforcement Learning from Human Feedback (RLHF)基于人工反饋優(yōu)化模型行為的方法這張表里的大部分術(shù)語在實(shí)際項(xiàng)目文檔里都會頻繁出現(xiàn)。建議你把它們存下來下次寫方案或者做評審時直接套用。根據(jù)我個人做過的這些項(xiàng)目我最大的體會是生成式AI服務(wù)能不能成技術(shù)選型只占一小部分更關(guān)鍵的是把數(shù)據(jù)、Prompt、檢索和評測這四個環(huán)節(jié)的細(xì)節(jié)做扎實(shí)。很多人拿著大模型跑出一段好結(jié)果就急著上線忽略了知識庫質(zhì)量和評測閉環(huán)結(jié)果一到真實(shí)場景就翻車。如果手里有準(zhǔn)備啟動的生成式AI服務(wù)項(xiàng)目建議你從今天就開始干兩件事第一把現(xiàn)有文檔梳理干凈哪怕只有幾十篇先把高質(zhì)量的知識庫建起來第二用一個小模型把問答鏈路完整跑通再考慮擴(kuò)展。這個方向后續(xù)還能繼續(xù)擴(kuò)展出多輪對話、主動追問、跨文檔對比分析等能力但地基一定是從簡單方案開始的。