1. 為什么一個殺熟案例值得AI工程師反復(fù)琢磨我在算法團隊做過幾年推薦和定價相關(guān)的事情最怕的不是模型跑不動而是某天運營群里甩來一張截圖兩臺手機、同一個收貨地址、同一家店、同一份餐一個顯示28.5元一個顯示21元。然后有人全體成員問一句這是怎么回事。那一刻你會發(fā)現(xiàn)所有的離線指標、AUC、召回率、GMV提升曲線在這張截圖面前都沒有說服力。這就是大數(shù)據(jù)殺熟這四個字為什么總能引爆輿論的原因。它不是一個純技術(shù)問題也不是一個純商業(yè)問題而是人工智能、大數(shù)據(jù)與工程倫理三者交匯處最典型的一個斷面。外賣平臺是這個議題被討論得最多的場景因為它高頻、剛需、價格構(gòu)成復(fù)雜商品價、包裝費、配送費、紅包、滿減、會員權(quán)益混在一起用戶又很難橫向比價。對于做算法、做數(shù)據(jù)、做產(chǎn)品的同學(xué)來說這個案例的價值在于它把我的模型選擇和別人多付了幾塊錢之間的因果鏈條第一次拉得足夠短、足夠清晰。這篇東西主要寫給三類人。一類是在校學(xué)生尤其是做人工智能大作業(yè)、大數(shù)據(jù)畢設(shè)、準備人工智能導(dǎo)論課程論文的同學(xué)你們需要一個能撐起論證深度的真實案例而不是空談AI要講道德。第二類是剛?cè)胄械乃惴?、?shù)據(jù)、產(chǎn)品崗從業(yè)者你們需要一套能落地的方法把倫理審查嵌進日常研發(fā)流程而不是等出事了再寫檢討。第三類是做技術(shù)管理的人你們需要在需求評審會上有底氣問出幾個關(guān)鍵問題。我會盡量避開兩種寫法一種是把倫理寫成口號滿篇應(yīng)當(dāng)必須另一種是把技術(shù)寫成擋箭牌說模型自己學(xué)出來的我也控制不了。前者沒用后者不負責(zé)任。1.1 先分清現(xiàn)象層、算法層和責(zé)任層討論這個問題最容易犯的錯誤是把三個層次混成一鍋粥?，F(xiàn)象層說的是用戶看到的結(jié)果同樣的服務(wù)不同的人付不同的錢而且這個差異和成本無關(guān)、和用戶身份有關(guān)。用戶感知到的被針對就發(fā)生在這個層次。算法層說的是這個結(jié)果是怎么產(chǎn)生的它通常不是某一個模型單獨決定的而是用戶畫像、價格敏感度預(yù)測、優(yōu)惠券分配策略、運籌優(yōu)化求解器、A/B實驗平臺這一整條鏈路協(xié)同的產(chǎn)物。你很難指著某一行代碼說就是它殺的熟。責(zé)任層說的是誰該為這個結(jié)果負責(zé)是寫特征工程的工程師是設(shè)定目標函數(shù)的產(chǎn)品經(jīng)理是批準上線的業(yè)務(wù)負責(zé)人還是設(shè)計實驗方案的算法科學(xué)家這個問題不解決倫理討論就會變成互相甩鍋。把這三層拆開之后你會發(fā)現(xiàn)工程倫理介入口其實在中間那一層。因為現(xiàn)象層是結(jié)果責(zé)任層是事后追認只有算法層是工程師真正有權(quán)限、有能力做出不同選擇的地方。特征選不選歷史客單價目標函數(shù)里加不加老用戶價格保護約束實驗分組怎么設(shè)計這些都發(fā)生在鍵盤前面。1.2 這個案例的三處不適感從哪來為什么同樣是差別定價機票淡旺季浮動大家能接受外賣的差異化定價卻讓人憤怒我琢磨了很久覺得有三處結(jié)構(gòu)性的不適感。第一處是信息不對稱的方向反了。機票漲價是公開的、可預(yù)期的、和你的身份無關(guān)你可以提前買、可以換航班。而外賣的差異化定價對用戶是黑箱你不知道自己是不是被分到了高支付意愿那一組也不知道換個賬號會不會更便宜。當(dāng)信息優(yōu)勢完全落在平臺一側(cè)用戶的第一反應(yīng)必然是不信任。第二處是關(guān)系的不對等被放大了。老用戶之所以是老用戶是因為信任和習(xí)慣這在很多商業(yè)邏輯里會被視為忠誠度資產(chǎn)。但如果模型把忠誠度高翻譯成價格敏感度低進而翻譯成可以少給優(yōu)惠那忠誠就變成了被懲罰的理由。用戶能隱約感覺到這個轉(zhuǎn)換雖然他說不出價格彈性這個詞。第三處是生活場景的脆弱性。點外賣這件事實在太日常了它不像買機票那樣是一個決策事件而是肌肉記憶。在肌肉記憶的領(lǐng)域里被算法悄悄區(qū)別對待那種不適感會直接轉(zhuǎn)化為道德判斷。理解了這三處不適感你就能明白為什么這個案例在課堂上、在面試里、在技術(shù)社區(qū)里被反復(fù)提起。它是一個絕佳的載體讓人工智能偏見這個抽象概念落到了一份麻辣燙的價格上。2. 大數(shù)據(jù)殺熟到底是怎么被算出來的外行看這件事容易想象成程序員寫了個if語句是老用戶就加價。真做這行的人都知道沒人會這么寫。真實的鏈路要文明得多也隱蔽得多。這一章我把技術(shù)路徑拆開講因為不理解技術(shù)倫理討論就只能停留在表層。2.1 用戶畫像與價格敏感度分層是地基任何差異化定價策略的第一步都是把用戶分群。這一步在技術(shù)上叫用戶分層在商業(yè)上叫精細化運營在輿論里叫貼標簽。常用的特征大概能分成幾類。交易類特征包括歷史客單價、月下單頻次、優(yōu)惠券使用率、退款率、加購未支付次數(shù)。行為類特征包括比價行為是否頻繁來回切換商家、點擊深度、瀏覽時段、對配送費變動的反應(yīng)速度。賬戶類特征包括注冊時長、會員狀態(tài)、支付方式綁定情況、設(shè)備型號和系統(tǒng)版本。把這些特征喂給一個模型預(yù)測目標通常是用戶對價格的敏感程度也就是價格彈性。彈性的定義不難價格變動1%需求量變動多少百分比。彈性絕對值大說明這個人一貴就跑叫高彈性彈性絕對值小說明貴一點他照樣買叫低彈性。生活化的類比就是菜市場。老練的攤主看人報價看的是你問價的語氣、猶豫的時間、有沒有轉(zhuǎn)身要走。算法做的事情本質(zhì)上一樣只不過它用的是幾百個維度的特征而且永不疲倦、永遠一致、可復(fù)制到每一單。這就是大數(shù)據(jù)三個字在這件事里的分量不是數(shù)據(jù)本身有惡意而是數(shù)據(jù)的密度讓看人下菜碟這件事第一次具備了工業(yè)級的可執(zhí)行性。提示價格彈性不是一個固定值它是隨場景、時段、品類變化的。同一用戶在深夜點夜宵時的彈性可能遠低于中午點工作餐時的彈性。2.2 三種典型技術(shù)路徑風(fēng)險等級完全不同業(yè)內(nèi)討論這個話題時經(jīng)?；\統(tǒng)地說差異化定價但不同實現(xiàn)方式的性質(zhì)差異很大。我按自己的經(jīng)驗整理成一張表。實現(xiàn)路徑技術(shù)做法用戶可感知度可解釋性倫理風(fēng)險差異化優(yōu)惠券投放對高彈性用戶多發(fā)券低彈性用戶少發(fā)或不發(fā)中等較高券是顯性的中差異化配送費/動態(tài)加價按時段、運力、區(qū)域動態(tài)調(diào)整配送費高明碼顯示高可歸因到供需較低個性化展示價同一商品對不同用戶展示不同基礎(chǔ)價低最隱蔽低難以歸因高第一類路徑最常見也最有爭議空間。因為發(fā)券本身是給好處問題在于給誰不給誰。如果模型系統(tǒng)性地讓老用戶拿到更少的券那在用戶視角里就是我越忠誠越吃虧。第二類路徑反而是這三類里最經(jīng)得起推敲的。動態(tài)配送費可以解釋為運力調(diào)度手段雨天、高峰期、偏遠區(qū)域加價目的是引導(dǎo)訂單在時間和空間上分散。它符合成本邏輯用戶也能理解雖然不爽。第三類路徑風(fēng)險最高。基礎(chǔ)商品價對所有人應(yīng)該是一致的這是用戶心理的底線。一旦基礎(chǔ)價開始因人而異任何解釋都顯得蒼白因為用戶找不到任何和自身付出相關(guān)的合理依據(jù)。我做過的項目里內(nèi)部有一條不成文的紅線優(yōu)惠可以個性化標價不能個性化。這條紅線不寫在任何規(guī)范里但它是很多團隊能睡得著覺的原因。2.3 一段可復(fù)現(xiàn)的彈性建模示例為了讓大家看清楚數(shù)學(xué)上正確和倫理上有問題之間的距離有多近我用一段簡化代碼演示彈性估計。數(shù)據(jù)是模擬的邏輯是真的。import numpy as np import pandas as pd import statsmodels.api as sm # 模擬每個用戶的訂單金額與對應(yīng)優(yōu)惠力度 # discount_rate 表示優(yōu)惠占原價比例price_ratio 1 - discount_rate np.random.seed(42) n 20000 user_price_sensitivity np.random.beta(2, 5, n) # 隱變量越低越不敏感 base_fee np.random.normal(30, 5, n) discount_rate np.random.uniform(0, 0.3, n) price_ratio 1 - discount_rate # 需求量彈性越大的用戶漲幅對其需求抑制越明顯 qty 10 * price_ratio ** (-user_price_sensitivity * 5) qty np.maximum(qty, 0.1) df pd.DataFrame({ price_ratio: price_ratio, qty: qty, user_id: np.arange(n) }) # 對整體做 log-log 回歸回歸系數(shù)即價格彈性 X sm.add_constant(np.log(df[price_ratio])) y np.log(df[qty]) model sm.OLS(y, X).fit() print(整體價格彈性估計:, model.params[price_ratio]) # 按用戶分組估計彈性真實系統(tǒng)里按畫像分群 df[group] pd.qcut(user_price_sensitivity, 5, labelsFalse) for g, sub in df.groupby(group): Xg sm.add_constant(np.log(sub[price_ratio])) yg np.log(sub[qty]) m sm.OLS(yg, Xg).fit() print(f第{g}組彈性: {m.params[price_ratio]:.3f})跑完你會發(fā)現(xiàn)不同群體的彈性估計值差異明顯。一個理性的定價系統(tǒng)拿到這個結(jié)果下一步動作幾乎是必然的對彈性絕對值小的群體減少補貼對彈性絕對值大的群體加大補貼。從優(yōu)化目標看這一步完全正確——它讓每一塊錢補貼都花在最能撬動訂單的人身上補貼效率最大化。但從倫理看恰恰是這一步把忠誠和低彈性劃了等號讓老用戶成了被減少補貼的那一批。注意這里的問題不在于模型錯了而在于目標函數(shù)里只有效率沒有公平約束。這是工程師真正能改變的地方后面第5章會講具體怎么加。3. 工程倫理的幾把尺子以及它們各自的盲區(qū)聊倫理最怕空對空。我的經(jīng)驗是準備三到四把尺子遇到具體決策時輪著量一遍哪把尺子量出來都不舒服那就該停下來重新設(shè)計了。這一章我把最常用的幾把尺子講清楚同時說明它們各自在什么情況下會失靈。3.1 后果論算總福利但算不出誰在承擔(dān)代價后果論的核心思路是看結(jié)果一個決策讓總體福利增加了還是減少了。放到差異化定價上支持方的論證通常是補貼總額固定把補貼給更需要的價格敏感人群能帶來更多訂單平臺、商家、騎手、用戶的總福利都上升。這個論證在數(shù)學(xué)上成立。問題在于它只關(guān)心總量不關(guān)心分布。如果總福利上升100但代價是讓1000萬老用戶每人多付2塊錢后果論本身沒有給出這能不能接受的答案。它只是把問題轉(zhuǎn)化成了這100和那1000萬怎么折算而折算規(guī)則是人定的不是算出來的。所以后果論有用但只能當(dāng)?shù)谝话殉咦印Ｋ鼛湍愦_認這事確實有效率收益但不能幫你確認這收益值得拿。我見過太多團隊止步于此拿一份GMV提升報告就去上線了。3.2 義務(wù)論與知情同意用戶到底同意了什么義務(wù)論關(guān)心的是行為本身是否違反了某種義務(wù)不管結(jié)果好壞。在數(shù)據(jù)倫理里它最常落到的落點是知情同意。用戶注冊時勾選的那份用戶協(xié)議通常包含我們可能根據(jù)您的使用情況提供個性化服務(wù)這類表述。這句話覆蓋的范圍很寬但它能不能覆蓋對同一種商品向你展示不同價格我的判斷是在絕大多數(shù)情況下不能。因為用戶在勾選時腦子里想的是推薦更合口味的店不是我可能因為這個勾選而多付錢。知情同意要成立有三個條件知道、理解、自愿。協(xié)議文本做到了知道雖然沒人讀做不到理解至于自愿就更勉強了——在一個已經(jīng)高度依賴外賣的生活節(jié)奏里不同意就別用算不算自愿是很難回答的問題。做工程的人從中能得到一條非常具體的啟發(fā)個性化推薦和個性化定價應(yīng)該分開授權(quán)。前者風(fēng)險低可以用默認開啟加顯式說明后者風(fēng)險高應(yīng)該有獨立、清晰、可撤回的開關(guān)。我不能說現(xiàn)在的產(chǎn)品都做到了這一點但這個方向是對的。3.3 美德倫理與工程師的職業(yè)責(zé)任前面兩把尺子都在看外部第三把尺子看內(nèi)部作為一個手藝人你愿不愿意公開說明你做了什么。這條自測標準非常鋒利。設(shè)想你要在技術(shù)評審會上用十分鐘向一群非技術(shù)同事解釋你設(shè)計的定價邏輯你用了哪些特征、目標函數(shù)是什么、約束條件是什么、實驗是怎么分組的。如果這個過程中有幾處你會下意識地含糊過去那么這幾處就是問題所在。我在團隊里推過一個很土的辦法叫家屬測試假設(shè)你爸媽用的就是這個產(chǎn)品你能不能坦然告訴他們您的價格是按這個規(guī)則算出來的。這個測試不能替代正式的倫理審查但它能在五秒鐘內(nèi)告訴你自己心里有沒有數(shù)。3.4 價值敏感設(shè)計把倫理從事后審查挪到事前設(shè)計上面三把尺子都是判斷工具價值敏感設(shè)計Value Sensitive Design則是流程工具。它的核心主張是倫理價值不應(yīng)該等產(chǎn)品做完了再評估而應(yīng)該在概念設(shè)計階段就被當(dāng)作設(shè)計需求之一和性能、成本、工期并列。具體到外賣定價場景這意味著公平不是一句口號而是要翻譯成可測量的設(shè)計指標。比如老用戶與新用戶在同一條件下的價格差異不超過某個閾值同一城市同一時段內(nèi)同類商品的展示價方差控制在某個范圍內(nèi)補貼覆蓋率的基尼系數(shù)不高于某個值。一旦翻譯成指標它就能進實驗平臺、進監(jiān)控大盤、進上線卡點。這才是工程師能真正使上勁的地方。倫理一旦能被度量它就從理念變成了工程約束。4. 邊界在哪個性化服務(wù)、差異化定價與殺熟的三方關(guān)系討論到這一步必須處理一個繞不開的問題個性化服務(wù)和差異化定價本身不是壞事那殺熟的邊界到底在哪如果答案模糊所有討論都會變成站隊。4.1 用四個維度把三個概念切開我的經(jīng)驗是用四個維度做判定定價依據(jù)、信息透明度、用戶選擇權(quán)、代價歸屬。做成一張對照表會清晰很多。維度合理的個性化服務(wù)合理的差異化定價大數(shù)據(jù)殺熟定價依據(jù)口味偏好、配送時間偏好供需關(guān)系、運力成本、時段用戶身份、忠誠度、支付意愿信息透明度推薦理由可見價格規(guī)則公開可查規(guī)則不公開用戶無法歸因用戶選擇權(quán)可關(guān)閉、可調(diào)整可選擇時段、可換渠道無實質(zhì)退出選項代價歸屬平臺承擔(dān)讓利需求方承擔(dān)但可預(yù)期忠誠用戶承擔(dān)且不可預(yù)期這張表最好用的地方是第四行。代價由誰承擔(dān)、承擔(dān)者能不能預(yù)期這是最鋒利的一刀。高峰期配送費上漲代價由需求方承擔(dān)但用戶能預(yù)期、能選擇避開而殺熟的代價由最信任平臺的那批用戶承擔(dān)且他們完全無法預(yù)期。4.2 五個可以在評審會上直接問的問題我把這套判斷壓縮成五個問題用起來比表格快。這個價格差異能不能用成本差異解釋清楚如果解釋不了差異的依據(jù)是什么用戶如果知道自己被分到了哪一組會不會覺得受騙用戶有沒有一個現(xiàn)實可操作的方式避免支付這個差異如果這個策略被完整公開在首頁上業(yè)務(wù)還做得下去嗎承擔(dān)這個差異的是新用戶、隨機用戶還是最忠誠的那批用戶這五個問題里第五個最有殺傷力。很多方案在1到4上都勉強能自圓其說一到第5個就露餡了。4.3 為什么這件事特別容易誤判需要說明的是輿論里被指認為殺熟的案例有一部分其實是誤判。我見過幾種常見的混淆源。第一種是優(yōu)惠券的隨機發(fā)放。平臺做A/B實驗時會給不同用戶發(fā)不同面額的券這在統(tǒng)計上看起來就是同物不同價但它的目的不是收割而是測試。這種方案在合規(guī)和倫理上的問題在于測試期沒有向用戶說明差異性且測試結(jié)束后的策略選擇可能被最優(yōu)轉(zhuǎn)化這個單一指標綁架。第二種是緩存與時效差異。同一個商品在不同時間點被加載商家可能剛好調(diào)價或者滿減活動剛好切換。用戶截圖時間差了幾分鐘結(jié)果看起來像殺熟。第三種是會員權(quán)益的疊加邏輯。會員費和權(quán)益是兩筆賬當(dāng)權(quán)益計算方式復(fù)雜到用戶算不清時用戶會默認自己吃虧。這是表達問題不是定價問題但殺傷力一樣大。區(qū)分這三類對工程師有實際意義前兩類需要在產(chǎn)品層面做說明和補償?shù)谌愋枰褭?quán)益計算做成一張用戶能看懂的賬單。我個人的看法是可解釋性本身就應(yīng)該是一項產(chǎn)品需求而不是等出了輿情再補的公關(guān)材料。5. 把倫理審查嵌進研發(fā)流程的落地方案前面幾章都在講判斷這一章講操作。我按研發(fā)流程的時間順序走一遍每一步給出可以直接抄的清單、腳本或指標。這部分是我認為最有價值的部分因為它把倫理從討論變成了工序。5.1 需求評審階段一份十問清單需求評審是成本最低的攔截點。一個方案在這個階段被攔下?lián)p失幾乎為零上線后再回滾損失的是用戶信任。我在團隊里推過一份十問清單評審定價類需求時必須逐條回答。這個策略的收益來自哪里是新增訂單還是存量訂單的價格提升價格差異的判定依據(jù)里有沒有包含用戶身份、注冊時長、會員狀態(tài)這類非成本特征是否設(shè)置了價格差異上限上限是怎么算出來的老用戶和新用戶在同一條件下的價格是否存在系統(tǒng)性差異實驗組和對照組的分組方式是什么會不會導(dǎo)致特定群體長期處在被測試狀態(tài)用戶能否感知到這個差異如果感知到我們的解釋是什么有沒有一個用戶可以實際操作的退出路徑策略的監(jiān)控指標里除了轉(zhuǎn)化率有沒有價格公平類指標一旦出現(xiàn)輿情或投訴回滾方案是什么回滾需要多長時間這套邏輯如果被完整公開我們的對外說明會怎么寫最后一條是壓力測試。如果第10條寫不出來或者寫出來自己都覺得牽強那這個方案就不該往前走。5.2 開發(fā)階段可解釋性埋點和約束條件到了寫代碼這一步有兩件事必須做進系統(tǒng)。第一件是可解釋性埋點。每一次價格計算都要把為什么是這個價記錄下來命中了哪些特征、折扣是怎么來的、被哪些規(guī)則調(diào)整過。這些日志平時沒人看出事的時候就是唯一的證據(jù)鏈。沒有它你既證明不了自己清白也發(fā)現(xiàn)不了自己的問題。第二件是把公平寫成約束條件。這是本文最想傳遞的一條操作建議。原來的優(yōu)化目標可能是maximize 總訂單量 - λ * 補貼總額加上公平約束后變成maximize 總訂單量 - λ * 補貼總額 subject to 同一條件下老用戶價格 ≤ 新用戶價格 * (1 ε) 同類商品展示價方差 ≤ σ2 補貼覆蓋率的基尼系數(shù) ≤ Gε、σ2、G 這三個參數(shù)就是倫理討論最終的落點。它們不該由算法同學(xué)單獨拍而應(yīng)該由產(chǎn)品、法務(wù)、數(shù)據(jù)和業(yè)務(wù)共同確定并且寫進文檔。參數(shù)一旦確定它就變成了一個普通的工程約束可以測試、可以監(jiān)控、可以回歸。我在實際項目里的體會是把倫理翻譯成參數(shù)這件事比開十次倫理研討會都有用。5.3 上線前價格一致性回歸測試腳本上線前一定要跑一遍跨賬號、跨設(shè)備、跨地域的價格一致性測試。這類測試的價值在于它能把我們覺得沒問題變成我們測過沒問題。import time import statistics import requests BASE_URL https://example-api.internal/price/quote def fetch_price(token, store_id, item_id, address_id): headers {Authorization: fBearer {token}} params { store_id: store_id, item_id: item_id, address_id: address_id, } resp requests.get(BASE_URL, headersheaders, paramsparams, timeout5) resp.raise_for_status() data resp.json() return { base: data[base_price], delivery: data[delivery_fee], final: data[final_price], coupon: data.get(coupon_amount, 0), } def audit(tokens, store_id, item_id, address_id, rounds5): results {} for round_idx in range(rounds): for name, token in tokens.items(): results.setdefault(name, []).append( fetch_price(token, store_id, item_id, address_id) ) time.sleep(2) # 避開瞬時波動也降低對線上接口的壓力 print(f{賬號:12}{平均終價:10}{基礎(chǔ)價:10}{配送費:10}{券:8}) base_prices [] final_prices [] for name, rows in results.items(): avg_final statistics.mean(r[final] for r in rows) avg_base statistics.mean(r[base] for r in rows) avg_delivery statistics.mean(r[delivery] for r in rows) avg_coupon statistics.mean(r[coupon] for r in rows) base_prices.append(avg_base) final_prices.append(avg_final) print(f{name:12}{avg_final:10.2f}{avg_base:10.2f} f{avg_delivery:10.2f}{avg_coupon:8.2f}) # 基礎(chǔ)價必須完全一致這是紅線 if max(base_prices) - min(base_prices) 0.01: raise AssertionError( f基礎(chǔ)價不一致極差 {max(base_prices) - min(base_prices):.2f} f這屬于標價個性化必須阻斷上線 ) # 終價允許有差異來自券但差異要有上限 spread max(final_prices) - min(final_prices) if spread 8: print(f警告終價極差 {spread:.2f}超過預(yù)設(shè)閾值 8 元需人工復(fù)核) return results if __name__ __main__: tokens { 新用戶A: token_new_a, 老用戶B: token_old_b, 老用戶C: token_old_c, 會員D: token_vip_d, } audit(tokens, store_id10086, item_id555, address_id999)這段腳本的核心設(shè)計思路是把紅線和不紅線分開測。基礎(chǔ)價必須完全一致這是零容忍項一旦超出直接阻斷終價允許因券而不同但要有極差閾值超出就報警讓人看。這樣既不會因為正常的營銷差異頻繁誤報也不會漏掉真正的問題。5.4 上線后監(jiān)控指標與熔斷機制上線不是終點。我的經(jīng)驗是至少要盯三組指標。第一組是價格公平指標同一條件下跨用戶群的終價極差、老用戶與新用戶的平均價格比、補貼覆蓋率的基尼系數(shù)。這三個指標畫成時間序列一旦出現(xiàn)趨勢性偏移就要查。第二組是用戶感知指標關(guān)于價格的客訴量、客服話術(shù)中為什么我和朋友價格不一樣的命中次數(shù)、退款申請中的價格相關(guān)理由占比。這組指標是前哨比輿情早得多。第三組是策略漂移指標模型的特征重要性排序變化、被高頻命中的特征列表變化。因為有很多問題是模型在持續(xù)訓(xùn)練中慢慢學(xué)壞的——初始版本可能是干凈的跑三個月之后它自己發(fā)現(xiàn)了注冊時長這個強特征然后系統(tǒng)性地開始區(qū)別對待。這種漂移最危險因為它沒有責(zé)任人只有時間。熔斷機制也簡單價格公平指標一旦越過閾值自動把定價策略降級到統(tǒng)一券池模式也就是所有人發(fā)同樣的券先止血再排查。6. 常見問題與排查技巧實錄這一章整理我在實際工作中遇到和聽說過的典型問題。表格形式方便速查。現(xiàn)象常見原因排查思路處理建議老用戶價格系統(tǒng)性偏高模型學(xué)到了注冊時長作為低彈性代理特征導(dǎo)出特征重要性看是否含身份類特征從特征集中移除身份代理特征或加入公平約束同一時刻不同賬號基礎(chǔ)價不同緩存不一致或灰度配置錯亂對比不同節(jié)點返回、檢查灰度規(guī)則基礎(chǔ)價走統(tǒng)一配置源禁止個性化券面額差異過大實驗分組不均或策略過激檢查各組樣本量和券額分布設(shè)置券額極差上限實驗期同步白名單用戶投訴變多但數(shù)據(jù)看著沒問題權(quán)益賬單不可讀讓客服復(fù)現(xiàn)用戶視角的完整價格構(gòu)成把價格構(gòu)成做成可讀賬單主動展示模型上線后逐步變壞策略漂移定期回歸價格一致性測試建立月度審計機制納入上線流程輿情爆發(fā)但定位不到邏輯缺少價格計算日志查埋點覆蓋情況補全可解釋性埋點作為長期基建除了表格還有幾個我踩過的坑值得單獨說。第一個坑以為公平約束會拖垮效果。我一開始也擔(dān)心加約束會讓優(yōu)化效果大幅下降實際測下來把價格差異上限設(shè)在一個合理區(qū)間對總訂單量的影響通常在1%到3%之間而客訴和退款率的改善會明顯得多。這筆賬長期看是劃算的只是短期KPI不好看。第二個坑把告知做成了免責(zé)。有一陣子我們在用戶協(xié)議里加了一段關(guān)于個性化定價的說明寫得非常專業(yè)結(jié)果是沒人看而且投訴的時候用戶會說你們就是靠這個免責(zé)的。后來改成了在訂單頁用一句話說明本單優(yōu)惠由系統(tǒng)按活動規(guī)則發(fā)放效果反而好一些。告知的關(guān)鍵不是法律上站得住而是用戶能看懂。第三個坑指標定義本身有爭議。我們內(nèi)部一開始用平均價格做公平監(jiān)控后來發(fā)現(xiàn)平均值會掩蓋結(jié)構(gòu)性問題——如果只有10%的用戶價格明顯偏高平均值看不出來。后來改成同時看均值、極差和分位數(shù)才算能抓住問題。第四個坑跨部門的分歧無法用數(shù)據(jù)解決。有些爭論本質(zhì)上是價值判斷不是技術(shù)判斷。比如老用戶價格比新用戶高多少算過分這個問題沒有唯一答案。我的經(jīng)驗是把這類分歧擺到臺面上讓業(yè)務(wù)負責(zé)人拍板并留下文檔記錄而不是讓算法同學(xué)自己背著。留痕這件事在事后非常重要它保護的是做技術(shù)的人。7. 踩過坑之后我的幾點體會做這行時間長了我對人工智能倫理這個說法的理解一直在變。剛?cè)胄袝r覺得它是務(wù)虛的是給論文和會議準備的做過幾個真實項目之后我越來越覺得它是這行最難、也最見功力的一部分。因為技術(shù)問題有標準答案倫理問題沒有。我現(xiàn)在比較確信的一點是倫理問題的落點永遠在具體參數(shù)上。不是要公平而是老用戶價格不得超過新用戶價格的1.05倍不是要透明而是訂單頁必須能展開看到價格構(gòu)成的每一行。凡是不能落到參數(shù)和界面上的倫理討論最后都會變成會議紀要里的一段漂亮話。第二點是工程師在這件事上的處境其實比想象中主動。很多人覺得這是老板定的我只是執(zhí)行。但實際操作中特征怎么選、約束怎么加、日志怎么埋、測試怎么寫這些決定權(quán)確實在工程師手上。把身份類特征從模型里拿掉把公平約束加進目標函數(shù)把價格一致性測試接進發(fā)布流水線這些事情不需要誰批準就能做。真做了之后你才有資格在更上游的決策里說話。第三點是關(guān)于表達。很多價格爭議之所以升級不是因為定價本身有多離譜而是因為用戶看不懂、問不到、找不著人解釋。把價格構(gòu)成做得讓一個普通人三十秒內(nèi)看明白這件事的技術(shù)難度遠低于模型調(diào)優(yōu)但對信任的價值高出很多。我甚至覺得可解釋性的投入產(chǎn)出比在這類產(chǎn)品里被嚴重低估了。至于這個案例本身我把它當(dāng)作一面鏡子。每次做定價、推薦、風(fēng)控相關(guān)的項目我都會拿那五個問題自問一遍成本能不能解釋、用戶知道后會不會覺得受騙、有沒有退出路徑、敢不敢公開、承擔(dān)代價的是不是最信任平臺的那批人。這五個問題不能讓我做出正確的決定但至少能讓我在做決定之前清楚自己在做什么。如果你正在寫相關(guān)的課程論文或者人工智能大作業(yè)我的建議是不要停在應(yīng)該加強監(jiān)管這種結(jié)論上。往下一層去寫清楚算法鏈路是怎么形成價格差異的去給出一個可以量化的公平約束去設(shè)計一個能跑的審計腳本。把倫理問題寫成工程問題這篇東西才算有分量。