與工程實戰(zhàn))
去年我們團隊接到一個任務(wù)把大模型真正用進(jìn)貨拉拉的營銷廣告鏈路里。當(dāng)時內(nèi)部討論時兩種聲音特別典型一種是覺得大模型無所不能干脆把整個廣告系統(tǒng)推翻重來另一種覺得大模型就是玩具上線后只會拖慢線上耗時、抬高成本。實際做完一輪之后我最大的感觸是真正有價值的不是“用了大模型”這個標(biāo)簽而是把生成、理解、審核這三類能力拆開分別放到廣告鏈路中最合適的位置上。這篇文章就記錄這次從數(shù)據(jù)、微調(diào)、部署到線上業(yè)務(wù)的落地過程分享一些可復(fù)用的經(jīng)驗也把踩過的坑原原本本寫出來。如果你在電商、本地生活、出行或者貨運平臺做營銷廣告算法或者正準(zhǔn)備把大模型接入業(yè)務(wù)系統(tǒng)這篇文章應(yīng)該能幫你少走很多彎路。1. 業(yè)務(wù)痛點與整體架構(gòu)選型1.1 貨拉拉廣告場景的難點在哪里貨拉拉的營銷廣告跟傳統(tǒng)電商廣告相比有比較明顯的自身特點。C端用戶使用場景集中在搬家、拉貨、同城運輸決策周期短、地域?qū)傩詮夿端司機側(cè)則需要持續(xù)招募、活躍留存同時要保證司機收入和平臺單量之間的平衡。整個平臺的廣告位分布在首頁信息流、搜索廣告、開屏、Push、短信營銷等多個入口投放目標(biāo)既有用戶拉新、也有老用戶促活、還有司機端招募轉(zhuǎn)化。傳統(tǒng)廣告系統(tǒng)在文本理解上的瓶頸是很明顯的。CTR/CVR模型主要依賴ID類特征、統(tǒng)計類特征和基礎(chǔ)的文本匹配特征但廣告標(biāo)題、描述、利益點、適用場景這些長文本語義信息很難被充分利用。新司機、新用戶、新廣告主都是稀疏樣本冷啟動問題嚴(yán)重文案素材同質(zhì)化嚴(yán)重寫來寫去都是“專業(yè)搬家、收費透明、快速上門”運營同學(xué)手工改寫效率也不高。更深層的問題是廣告創(chuàng)意和用戶意圖之間的匹配不能只看關(guān)鍵詞重合度還需要理解“我今天要搬鋼琴”和“提供鋼琴搬運保護(hù)”這種細(xì)顆粒度的語義關(guān)聯(lián)。大模型正好在這些痛點上有發(fā)揮空間。最直接的是生成能力可以用大模型批量生成幾十組廣告標(biāo)題、利益點、場景描述緩解素材供給不足。其次是語義理解用大模型把廣告和用戶請求映射到語義空間改善稀疏場景下的召回。還有就是控制能力廣告上線前需要做素材審核、敏感詞過濾、夸大宣傳檢測過去靠詞表規(guī)則誤殺和漏殺并存大模型可以做得更準(zhǔn)。1.2 為什么沒有選擇“全量重構(gòu)方案”內(nèi)部也有同事提出過一個看起來更“徹底”的思路既然大模型能力這么強干脆用它把召回、粗排、精排全部替換掉。這個方案我一開始就反對不是說大模型能力不行而是工程代價和風(fēng)險完全不可控。廣告系統(tǒng)對延遲極其敏感信息流和搜索場景要求整個請求鏈路在百毫秒級別返回如果每個環(huán)節(jié)都插入一次幾十毫秒甚至上百毫秒的大模型推理線上根本扛不住。另外大模型本質(zhì)上是概率模型直接做精排打分會有置信度和可解釋性問題。業(yè)務(wù)方問一句“為什么這個人看到了這條廣告”我們需要能回答出具體的特征貢獻(xiàn)。而精排模型中的LR、DNN這類模型配合SHAP或特征歸因至少能給出一個讓人信服的解釋。大模型生成的內(nèi)容則需要疊加校驗環(huán)節(jié)比如金額計算是否正確、優(yōu)惠是否真實可達(dá)、是否違反廣告法。所以最終我們走了“共生”路線原來成熟的召回和精排體系保留大模型負(fù)責(zé)給系統(tǒng)提供更好的文本語義、更豐富的創(chuàng)意素材、更準(zhǔn)的審核判斷。1.3 最終架構(gòu)生成層、理解層、控制層整個應(yīng)用架構(gòu)我習(xí)慣分成三層這樣團隊里做工程、做算法、做數(shù)據(jù)的人都有一個共同語言。生成層負(fù)責(zé)廣告創(chuàng)意生產(chǎn)、標(biāo)題改寫、利益點擴寫、Push文案生成輸入是廣告主素材和業(yè)務(wù)畫像輸出是多種風(fēng)格的候選文案。理解層負(fù)責(zé)語義向量召回、廣告文本向量化、用戶搜索意圖識別、人群標(biāo)簽自動擴展。它的產(chǎn)出不只是向量還包括結(jié)構(gòu)化的意圖標(biāo)簽和關(guān)鍵詞權(quán)重。控制層負(fù)責(zé)廣告內(nèi)容合規(guī)審核、虛假宣傳檢測、折扣準(zhǔn)確性校驗、敏感行業(yè)攔截。所有生成層和理解層的產(chǎn)出都要經(jīng)過控制層確認(rèn)后才能進(jìn)入線上。這個三層架構(gòu)的好處是邊界清晰。生成層壞了最多是素材供給變慢不影響廣告主流程理解層出問題召回效果波動但精排還能兜底控制層是唯一要求高召回率的部分寧可誤殺也不能漏過違規(guī)內(nèi)容。三層之間互不阻塞我們可以獨立迭代、獨立灰度、獨立回滾。技術(shù)底座上我們沒有選擇接外部API因為廣告數(shù)據(jù)涉及投放策略和用戶畫像數(shù)據(jù)合規(guī)上走私有化部署是更穩(wěn)妥的選擇。也對比了幾種開源底座方案最后選了7B級別的中英雙語底座一臺A10或者4090級別的單卡就能跑推理訓(xùn)練階段用4卡就可以完成微調(diào)。這套選型保證了后續(xù)不管是灰度驗證還是正式上線都不用為算力發(fā)愁。2. 數(shù)據(jù)鏈路與樣本工程決定效果的上限2.1 營銷廣告數(shù)據(jù)池里有什么可以利用的很多團隊做大模型應(yīng)用時最容易犯的錯誤是一上來就問“用什么基座模型”卻忽視訓(xùn)練數(shù)據(jù)。實際上模型效果的上限由數(shù)據(jù)決定模型結(jié)構(gòu)決定了能逼近這個上限多少。貨拉拉廣告系統(tǒng)沉淀下來的數(shù)據(jù)其實非常豐富關(guān)鍵是看怎么組織。第一類是廣告主側(cè)的素材數(shù)據(jù)包括歷史投放過的標(biāo)題、描述、圖片文案、落地頁利益點以及每個素材的曝光、點擊、轉(zhuǎn)化數(shù)據(jù)。這些數(shù)據(jù)可以直接用于監(jiān)督微調(diào)讓模型理解什么風(fēng)格在什么場景下更容易獲得正向反饋。第二類是用戶行為序列也就是用戶在廣告位的曝光、點擊、停留、咨詢、下單行為這些數(shù)據(jù)可以構(gòu)造偏序樣本判斷哪些廣告文案更符合用戶需求。第三類是審核數(shù)據(jù)包含歷史上被拒絕的違規(guī)素材、被投訴的廣告、人工審核的標(biāo)注結(jié)果這些數(shù)據(jù)是控制層模型訓(xùn)練的核心原料。有一點要特別提醒不要天真地以為CTR高的素材就一定是好素材。點擊行為受廣告位展示位置、人群定向、投放時段等多重因素影響如果直接用點擊率給樣本打標(biāo)模型學(xué)到的可能是“不同位置帶來的偏差”。我們的做法是把素材歸一到同一廣告位、同一人群桶、同一時段下再做相對比較最終用轉(zhuǎn)化率、獲客成本這些業(yè)務(wù)指標(biāo)來打輔助標(biāo)簽。2.2 三種訓(xùn)練樣本的構(gòu)造方式這次項目里我們同時訓(xùn)練了三個能力創(chuàng)意生成、語義召回、內(nèi)容審核。每個能力對應(yīng)的樣本結(jié)構(gòu)完全不同共享基座模型但使用不同的Adapter這樣可以避免一個模型把所有能力揉在一起導(dǎo)致互相干擾。創(chuàng)意生成任務(wù)的樣本是一個典型的監(jiān)督式文本生成樣本格式大概是這樣的{ instruction: 為搬家服務(wù)寫一條APP內(nèi)信息流廣告文案突出專業(yè)和價格透明不超過25個字。, context: 用戶近期搜索過鋼琴搬運近7天有搬家意向。, output: 專業(yè)鋼琴搬運全程保險費用明細(xì)提前說清 }這里的關(guān)鍵點不只是讓模型學(xué)會寫得通順還要學(xué)會利用上下文中的用戶意圖。我們會把用戶搜索詞、瀏覽行為摘要作為前綴寫進(jìn)prompt讓模型生成時具備場景感知能力。樣本數(shù)量最終控制在20萬條左右覆蓋搬家、拉貨、同城貨運、企業(yè)服務(wù)、汽車增值服務(wù)等主要業(yè)務(wù)線。語義召回任務(wù)我們做的是雙塔式的對比學(xué)習(xí)樣本但這里沒有用傳統(tǒng)雙塔而是用大模型底座做文本編碼產(chǎn)出語義向量再配合Faiss做向量檢索。訓(xùn)練樣本來自搜索日志和廣告投放日志中的“查詢詞-廣告標(biāo)題”對正樣本是有點擊或轉(zhuǎn)化的對負(fù)樣本是從曝光未點擊和隨機采樣中構(gòu)造的。對錯誤負(fù)樣本要特別小心比如“搬家費用”和“寵物托運”看起來完全不相關(guān)但如果用戶同時看了兩個廣告就不能簡單認(rèn)為是純負(fù)樣本我們會根據(jù)行為強度動態(tài)調(diào)整負(fù)樣本的難易程度。審核任務(wù)的樣本則相對直接輸入是一條待審核廣告文本輸出是一個多標(biāo)簽集合包括“是否違規(guī)”“違規(guī)類型”“風(fēng)險等級”“建議動作”。歷史審核記錄天然存在標(biāo)注偏置早期標(biāo)注標(biāo)準(zhǔn)比較松后來標(biāo)準(zhǔn)收緊所以訓(xùn)練前要統(tǒng)一標(biāo)準(zhǔn)做一次重標(biāo)注否則模型會學(xué)習(xí)到舊標(biāo)準(zhǔn)下的錯誤判斷。2.3 數(shù)據(jù)清洗的血淚經(jīng)驗第一輪微調(diào)我們翻過一個大跟頭。直接用歷史素材訓(xùn)練生成模型發(fā)現(xiàn)生成結(jié)果幾乎全都在“抄”高頻模板多樣性非常差。排查后發(fā)現(xiàn)問題出在文本重復(fù)上——歷史素材里有大量同一個模板只改了城市名的文案比如“北京專業(yè)搬家”“上海專業(yè)搬家”看起來是不同樣本但模型學(xué)到的是復(fù)讀機。解決辦法是加了一層MinHash近重復(fù)去重相似度超過閾值的只保留一條同時保證每個業(yè)務(wù)線、每種利益點類型都有足夠的覆蓋。另一個坑是數(shù)據(jù)穿越。訓(xùn)練語料里混入了投放周期比較長的素材導(dǎo)致驗證集里也包含同一條文案離線指標(biāo)虛高。我們后來嚴(yán)格按時間切分訓(xùn)練集取前60天數(shù)據(jù)驗證集取最近14天數(shù)據(jù)再用規(guī)則檢查訓(xùn)練集和驗證集的公開標(biāo)識比如素材ID是否有重疊有重疊就剔除。這看起來是基礎(chǔ)操作但真到了做樣本工程的時候很多人為了貪圖樣本量會睜一只眼閉一只眼最后上線效果還原不了離線結(jié)果反而更耽誤事。還有一個容易被忽略的問題是標(biāo)簽噪聲。廣告點擊數(shù)據(jù)里存在大量誤點擊和惡意點擊直接拿這些樣本喂給模型會讓生成模型學(xué)到“標(biāo)題黨”傾向。我們設(shè)計了一套規(guī)則點擊后停留小于2秒的樣本降權(quán)短時間內(nèi)連續(xù)多次點擊同一廣告但無后續(xù)行為的用戶樣本直接過濾。迭代過程中還做人工抽檢每批次抽500條樣本由運營團隊給新舊版本打分抽檢一致率低于85%的樣本批次不進(jìn)入訓(xùn)練。3. 模型選型與微調(diào)細(xì)節(jié)花小錢辦大事3.1 基座模型怎么選7B是甜點還是妥協(xié)模型選型上我們經(jīng)歷了比較長的技術(shù)調(diào)研。一開始團隊里有人提出直接用千億級API效果好但數(shù)據(jù)合規(guī)和成本都不太接受也有人提議私有化部署一個數(shù)百億參數(shù)的大模型結(jié)果評估下來光是GPU服務(wù)器成本就夠養(yǎng)好幾個算法工程師了。最終鎖定在7B到14B這個區(qū)間的開源底座實際跑完業(yè)務(wù)側(cè)的效果之后確定用7B中英雙語底座作為主力。為什么7B夠用因為我們的廣告文案本身長度有限單條素材通常在20到80個字之間輸入的用戶畫像信息也不復(fù)雜模型的推理任務(wù)負(fù)載并不重。7B模型的語義理解能力和文本生成質(zhì)量在廣告這種“短文本、強結(jié)構(gòu)化”的領(lǐng)域中跟14B甚至更大模型的差距并沒有想象中那么大。我們把同一套驗證集跑完對比在ROUGE-L、語義相似度和人工好評率三個指標(biāo)上7B只比14B低不到3個百分點但推理時延降低了一半多顯存占用也從接近40GB降到不到20GB。對廣告系統(tǒng)來說延遲就是錢這個妥協(xié)是值得的。當(dāng)然7B也有明顯的短板主要體現(xiàn)在復(fù)雜指令跟隨和長文本推理上。比如讓它根據(jù)用戶歷史行為序列做深度歸因或者生成包含多條件優(yōu)惠計算的文案它偶爾會丟條件或算錯金額。這種情況我們不硬扛而是把任務(wù)拆解條件校驗交給規(guī)則系統(tǒng)優(yōu)惠金額計算用模板填充大模型只負(fù)責(zé)生成“人話”部分。3.2 微調(diào)方式對比為什么選LoRA而不是全量微調(diào)基座模型確定后微調(diào)方式是我們討論最久的技術(shù)細(xì)節(jié)。三種主流方案我們都做了小規(guī)模實驗全量微調(diào)、LoRA、QLoRA。全量微調(diào)的效果上限最高但訓(xùn)練成本驚人。7B模型全量微調(diào)在A100-80G上即使用了ZeRO優(yōu)化也需要至少4卡才能跑得比較舒服一個epoch就要兩三個小時而且每次實驗調(diào)參都要重來迭代效率太低。QLoRA的顯存占用確實最低4-bit量化后甚至可以在單張4090上跑但訓(xùn)練速度偏慢且量化帶來的信息損失在廣告審核這類精細(xì)任務(wù)上偶發(fā)誤判。最后我們選擇的是LoRA加16-bit混合精度訓(xùn)練用4張A10訓(xùn)練效果和成本達(dá)到了一個比較舒服的平衡。微調(diào)參數(shù)上我們的經(jīng)驗是rank不要一味追求大。早期試過rank64訓(xùn)練收斂慢且推理時有額外顯存開銷穩(wěn)定下來用的是rank32、alpha64、dropout0.05這個配置在生成質(zhì)量和訓(xùn)練速度之間比較均衡。學(xué)習(xí)率用2e-4warmup ratio設(shè)為0.1batch size按每個GPU 16條樣本、梯度累積8步來設(shè)置相當(dāng)于每輪更新用512條樣本的梯度。訓(xùn)練輪數(shù)我們控制在2到3輪超過3輪會開始出現(xiàn)明顯的過擬合驗證集困惑度上升生成內(nèi)容變得死板。# 訓(xùn)練命令示例細(xì)節(jié)略去平臺相關(guān)配置 accelerate launch --mixed_precision bf16 \ --num_processes 4 \ finetune.py \ --base_model /data/models/qwen-7b-chat \ --adapter_name lora_ads_v1 \ --rank 32 \ --alpha 64 \ --learning_rate 2e-4 \ --num_epochs 2 \ --batch_size 16 \ --gradient_accumulation_steps 83.3 離線評測與上線前的三道關(guān)卡離線評測如果只用一個指標(biāo)大概率會被帶偏。我們設(shè)置了三個維度的指標(biāo)只有三個維度都達(dá)標(biāo)才允許進(jìn)入線上灰度。第一是生成質(zhì)量指標(biāo)。計算生成文案和歷史高轉(zhuǎn)化素材之間的ROUGE-L、BLEU同時對文本多樣性做統(tǒng)計比如重復(fù)n-gram占比、同一業(yè)務(wù)線下生成結(jié)果的成對相似度。我們希望ROUGE-L不要太高太高說明模型在背模板也不要太低太低說明模型跑偏了。第二是語義一致性指標(biāo)。把生成文案和原始需求放到底座模型的向量空間里算余弦相似度低于閾值的結(jié)果直接丟棄。這能過濾掉“答非所問”的生成結(jié)果。比如業(yè)務(wù)方要的是“同城貨運”模型生成“長途搬家”即使語句通順也不會被采用。第三是安全合規(guī)指標(biāo)。我們專門構(gòu)造了一個包含1200條挑戰(zhàn)樣本的評測集覆蓋夸大宣傳、敏感行業(yè)、競品詞、價格歧義等類型。大模型生成的每一條內(nèi)容都要經(jīng)過控制層審核審核不通過的直接攔截。這里對召回率的要求是至少99%哪怕誤殺率高一點都接受因為違規(guī)帶來的平臺風(fēng)險遠(yuǎn)比多花一點審核成本嚴(yán)重。三道關(guān)卡全部通過后我們才做小流量AB實驗。AB實驗觀測的不是單一的CTR而是綜合了點擊率、轉(zhuǎn)化率、獲客單價、投訴率四個指標(biāo)。第一輪實驗跑出來點擊率提升了8%左右獲客成本下降了6%左右但投訴率沒有明顯變化說明文案質(zhì)量過關(guān)。這里多說一句做AB時一定要同時設(shè)置一個“人工撰寫優(yōu)質(zhì)文案”的對照組不然老板會質(zhì)疑“是不是因為新人寫的文案太差才顯得大模型好”。4. 線上推理部署與廣告鏈路接入穩(wěn)定壓倒一切4.1 部署方式與首版性能數(shù)據(jù)線上部署我們用了vLLM作為推理框架它支持PagedAttention和Continuous Batching在高并發(fā)場景下能把GPU利用率拉得很滿。模型權(quán)重做了16-bit和8-bit兩種版本首版先用16-bit保證效果后續(xù)需要壓成本再切8-bit。一個比較穩(wěn)定的組合是單張A10跑7B模型16-bit最大輸入長度512、輸出長度128并發(fā)請求數(shù)設(shè)置成8首版線上壓測的單個請求P95時延在180毫秒左右QPS能做到40上下。這個時延對內(nèi)容生成類場景完全夠用但絕對不能放在用戶請求的同步主鏈路上。我們做了一個異步任務(wù)隊列上游把需要生成文案的素材包推送到MQ消費者從MQ拉取任務(wù)后批量調(diào)用推理服務(wù)生成結(jié)果回寫KV存儲再由廣告檢索服務(wù)讀取。首版上線后隊列積壓最嚴(yán)重的一次是凌晨大促活動幾十萬條素材同時涌入我們通過把消費者實例從3個擴容到10個在15分鐘內(nèi)就把積壓清掉了。部署時還有一個容易忽略的點模型熱加載。如果每次發(fā)版都手動重啟推理服務(wù)整個鏈路會中斷幾分鐘。我們最終把模型文件放在共享存儲上啟動時從共享存儲加載權(quán)重發(fā)版通過更新Adapter文件實現(xiàn)秒級切換。配合灰度發(fā)布流量按1%、5%、20%逐步放開隨時可以一鍵回滾到上一版。4.2 在廣告召回、精排、創(chuàng)意環(huán)節(jié)的落點大模型在召回環(huán)節(jié)的價值主要體現(xiàn)在語義召回。傳統(tǒng)的關(guān)鍵詞召回只能匹配字面重合比如用戶搜“搬鋼琴”關(guān)鍵詞系統(tǒng)只能召回標(biāo)題里帶“搬鋼琴”的廣告而“鋼琴搬運”“鋼琴托運”“貴重物品運輸”這些語義相關(guān)的廣告全部漏掉。我們利用大模型把用戶查詢詞和廣告標(biāo)題統(tǒng)一編碼成128維向量再疊加一層基于Faiss的ANN檢索。實踐下來的一個關(guān)鍵教訓(xùn)是向量召回不能單獨用要和傳統(tǒng)召回融合。我們在精排階段把兩種召回的得分都帶上用特征交叉讓精排自己學(xué)習(xí)偏重哪一種上線后召回率提升了12%但廣告主覆蓋率沒有下降說明融合確實有效。精排環(huán)節(jié)我們比較克制沒有直接把大模型作為打分器放進(jìn)去。只在精排特征里增加了一個“大模型生成文本質(zhì)量分”這個分?jǐn)?shù)是控制層審核后得到的綜合質(zhì)量得分包含語義相關(guān)性、合規(guī)置信度、風(fēng)格一致性等信息。精排模型拿到這個分?jǐn)?shù)后會更好地過濾掉低質(zhì)素材同時不影響原有特征體系。創(chuàng)意環(huán)節(jié)是大模型介入最深的地方。運營和廣告主上傳一條原始素材后系統(tǒng)自動基于用戶畫像生成多個版本的標(biāo)題和利益點描述。比如一條原始的“專業(yè)搬家”素材大模型可以生成“鋼琴也能安全搬運”“本周下單立減30元”“搬家?guī)煾堤崆半娫挏贤ā钡榷鄠€變體然后自動做小流量測試用真實點擊和轉(zhuǎn)化數(shù)據(jù)反饋給生成服務(wù)形成“生成-投放-反饋-再生成”的閉環(huán)。這個閉環(huán)跑起來之后我們不再依賴人工從一堆文案里挑選而是把篩選交給數(shù)據(jù)。4.3 廣告內(nèi)容合規(guī)與風(fēng)險控制廣告行業(yè)的合規(guī)要求非常嚴(yán)格虛假宣傳、違規(guī)承諾、敏感詞、競品貶低都是紅線。傳統(tǒng)詞表規(guī)則最大的問題是無法處理語義變體比如“不花一分錢就能搬家”這種表達(dá)詞表里未必有“不花一分錢”這個關(guān)鍵詞但語義上明顯屬于誘導(dǎo)夸大。我們的控制層用大模型做文本分類輸入是完整的待審核文案輸出是違規(guī)類型和風(fēng)險概率。模型覆蓋的違規(guī)類型包括虛假折扣、絕對化用語、醫(yī)療功效承諾、金融誤導(dǎo)、競品攀比、性暗示擦邊等。對于生成任務(wù)我們在prompt里強行加了一條“禁止輸出與事實不符的促銷信息禁止輸出模糊價格”同時在解碼階段做了logit級別的約束如果生成文本中包含未出現(xiàn)在白名單里的價格數(shù)字或優(yōu)惠折扣直接熔斷重試。這一招非常管用上線后由模型幻覺導(dǎo)致的虛假折扣問題下降了90%以上。還有一個容易被忽略的細(xì)節(jié)模型要識別平臺特有的業(yè)務(wù)黑話。有些詞匯在普通場景沒有風(fēng)險但在貨拉拉業(yè)務(wù)下就是違規(guī)詞比如“司機繞路”“私下交易”“場外結(jié)算”。我們會在訓(xùn)練數(shù)據(jù)里專門補充這類業(yè)務(wù)正負(fù)樣本并且維護(hù)一份動態(tài)的業(yè)務(wù)敏感詞表大模型分類結(jié)果和敏感詞表結(jié)果做加權(quán)融合兩者都判斷為風(fēng)險時才放行否則進(jìn)入人工審核列表。整體來說控制層的存在讓業(yè)務(wù)方對大模型生成內(nèi)容有了基本信任否則他們根本不敢把模型產(chǎn)出推到用戶面前。5. 踩坑記錄與問題排查這些坑常規(guī)文檔里不會寫5.1 模型幻覺差點把優(yōu)惠金額算錯第一次灰度時出現(xiàn)了一條“新用戶立減100元”的文案但運營后臺配置的真實優(yōu)惠是“新用戶立減30元”。原因是模型在讀歷史素材時學(xué)到了一個舊版本的優(yōu)惠信息把它當(dāng)成了通用的業(yè)務(wù)規(guī)則。這個問題光靠微調(diào)很難解決因為大模型本質(zhì)上是在做概率預(yù)測它不知道促銷活動具有時效性。我們最終的解決方案分三路提示詞里把當(dāng)前有效優(yōu)惠信息單獨放在“系統(tǒng)固話區(qū)”并用特殊分隔符和正文隔開生成結(jié)果里所有數(shù)字金額、折扣、滿減必須預(yù)先經(jīng)過模板化處理大模型只選擇活動模板ID不直接生成數(shù)值最后校驗?zāi)K檢查所有數(shù)字是否與配置中心的活動參數(shù)一致不一致直接攔截。三路都加完之后類似問題基本清零。5.2 生成內(nèi)容多樣性不足第一版模型剛上線時運營反饋“十條文案起碼六條驚人相似”我們檢查發(fā)現(xiàn)其實是解碼參數(shù)太保守了。為了求穩(wěn)我們把temperature設(shè)成了0.1top_p設(shè)成了0.8結(jié)果生成的候選池里最頻繁的幾條模板占據(jù)了絕大多數(shù)。后來調(diào)整成temperature0.8、top_p0.9同時加了一個重復(fù)懲罰參數(shù)把生成結(jié)果的多樣性明顯拉開。但過高的temperature也會導(dǎo)致語法錯誤和語義漂移所以現(xiàn)在的做法是先生成20個候選然后過一個多樣性篩選器保證最終進(jìn)入AB池的10條文案兩兩之間相似度不超過0.75同時語義一致性得分都高于閾值。5.3 數(shù)據(jù)穿越讓離線指標(biāo)虛高差點誤判模型能力在2.3里我提過數(shù)據(jù)穿越的問題這里再補充一個具體教訓(xùn)。有一版模型離線評估指標(biāo)特別好ROUGE-L和語義一致性都大幅超過前一版但上線后效果沒有明顯提升。定位后發(fā)現(xiàn)是訓(xùn)練數(shù)據(jù)里包含了來自未來時間段的素材。具體場景是我們當(dāng)時只按素材ID做了去重沒有嚴(yán)格按時間切分導(dǎo)致測試集里混入了已經(jīng)在線上投放過的歷史素材模型等于“開卷考試”。后來我們加了時間過濾同時用規(guī)則檢查訓(xùn)練集和驗證集的文本重疊度把這個bug徹底堵住。做數(shù)據(jù)工程的人都知道這件事但真正動手時特別容易因為圖省事而跳過我在這里強調(diào)第二次是因為它真的值得強調(diào)。5.4 線上推理延遲波動和GPU顯存溢出首版部署時我們用的是單路同步推理壓測時P95延遲非常好看但一上生產(chǎn)環(huán)境就原形畢露早晚高峰期用戶請求并發(fā)上來后P95時延從180毫秒飆到接近1秒偶爾還會報CUDA Out of Memory。排查后發(fā)現(xiàn)是實例上混跑了好幾個模型副本互相爭搶GPU顯存加上vLLM的KV Cache策略沒有配置好長尾請求把緩存占滿了。解決辦法是分配獨立的GPU實例給生成式服務(wù)并顯式設(shè)置KV Cache的顯存上限比例比如gpu_memory_utilization0.85同時配合請求排隊和隊列超時熔斷。這一輪調(diào)整之后高峰期的P95時延穩(wěn)定在350毫秒左右抖動幅度明顯收斂。6. 項目復(fù)盤與我的個人體會6.1 復(fù)盤中值得肯定的三件事第一件事是堅持了“小步快跑、分模塊上線”的節(jié)奏。我們沒有搞一個“大模型全流程改造”的大版本而是把生成層先灰度驗證穩(wěn)定后再推理解層最后才上控制層這樣每一層出問題時影響半徑都很小。第二件事是把數(shù)據(jù)工程和大模型訓(xùn)練放在了同等重要的位置前期花了將近三周時間做樣本清洗和標(biāo)注標(biāo)準(zhǔn)統(tǒng)一雖然看起來拖慢了啟動進(jìn)度但后面模型迭代的效率成倍提升。第三件事是建立了比較完整的離線評測和上線回歸體系特別是安全審核挑戰(zhàn)集讓業(yè)務(wù)方對生成內(nèi)容建立了信任。如果要說做得不夠好的地方我覺得是對大模型輸出結(jié)果的解釋性工具準(zhǔn)備得偏少。業(yè)務(wù)方經(jīng)常會問“為什么這個文案能過審、那個文案不能”我們只能事后分析日志。如果一開始就把日志埋點和歸因模塊做進(jìn)控制層后續(xù)溝通成本會低很多。6.2 后續(xù)我還會做什么下一步我們在看兩個方向。一個是多模態(tài)素材生成不只是文本而是把圖片、文案、落地頁結(jié)構(gòu)化信息打通用統(tǒng)一的大模型底座去生成整張廣告卡片這需要把視覺編碼器接入現(xiàn)有的生成流程對推理成本和延遲提出更高要求。另一個是Agent化運營讓大模型不只是“生成一條文案”而是能根據(jù)投放數(shù)據(jù)自動調(diào)整人群包和出價策略做成一個能對業(yè)務(wù)指標(biāo)負(fù)責(zé)的智能體。這兩個方向我們目前都在做技術(shù)驗證但核心原則不變?nèi)魏文P偷漠a(chǎn)出都必須經(jīng)過控制層校驗任何推廣效果都必須用AB實驗說話。從個人經(jīng)驗角度說這次項目最深的體會是大模型不是銀彈它更像是給廣告系統(tǒng)裝上了一個更強的“言語中樞”。真正決定項目成敗的不是你用了多大的模型而是你把它放在什么樣的工程鏈路里讓它在什么時候該出場、什么時候該閉嘴。這個分寸感才是應(yīng)用團隊最需要修煉的內(nèi)功。