去年我花了小半年時間把一個“能自動找客戶、給客戶打標簽、再預(yù)測誰最可能成交”的銷售 Agent 從零搭起來了。這個項目后來在團隊里穩(wěn)定運行把市場部沉淀多年的公開線索池全部接進來線索生成環(huán)節(jié)的無效量從 40% 壓到 15% 以內(nèi)轉(zhuǎn)化預(yù)測模型在嚴格的時間外驗證下 AUC 做到 0.82 左右。整個過程踩了不少坑尤其是把線索生成、客戶畫像、轉(zhuǎn)化預(yù)測這三塊串成一條完整鏈路的時候數(shù)據(jù)口徑、特征時序、模型評估各種問題一起冒出來。這篇文章就把完整鏈路和踩坑點完整捋一遍給正在做銷售數(shù)字化、CRM 智能化的產(chǎn)品經(jīng)理、算法工程師和業(yè)務(wù)負責(zé)人參考。這個 Agent 不是一個單一的大模型而是一整套工程系統(tǒng)線索從公開渠道采集進來經(jīng)過清洗和匹配生成候選池然后給每個客戶打上結(jié)構(gòu)化的畫像標簽最后用模型預(yù)測轉(zhuǎn)化概率把結(jié)果按分數(shù)排序推給銷售跟進。它解決的核心問題很樸素銷售團隊每天時間有限與其讓他們自己翻資料、憑感覺找客戶不如讓系統(tǒng)把“誰值得聯(lián)系、為什么值得、現(xiàn)在聯(lián)系還是過兩周再聯(lián)系”提前算好。適合誰來參考一類是公司里負責(zé)銷售工具鏈的算法工程師另一類是手握客戶數(shù)據(jù)但不知道怎么用起來的業(yè)務(wù)負責(zé)人還一類就是像我一樣從零開始搭整套系統(tǒng)的“全棧打雜選手”。1. 整體鏈路設(shè)計與方案選型1.1 為什么拆成三條流水線而不是一個大模型最開始我也認真考慮過一種“偷懶”的方案把所有客戶資料喂給一個語言模型輸入公司名直接輸出“高/中/低意向”。試了一輪之后放棄了原因有三個。第一個原因是三個環(huán)節(jié)的數(shù)據(jù)特征差異太大。線索生成面對的是非結(jié)構(gòu)化的文本資料可能是公司簡介、官方網(wǎng)站上的產(chǎn)品詞、招聘信息里的業(yè)務(wù)描述客戶畫像需要的是結(jié)構(gòu)化的標簽推論比如“這家公司規(guī)模在 100 人左右、近 30 天有活躍行為”轉(zhuǎn)化預(yù)測本質(zhì)上是一個時間序列問題必須嚴格區(qū)分“在某個時間點之前知道什么”和“之后發(fā)生了什么”。三個問題用同一種模型硬做最后必然是各方面都平庸。第二個原因是更新頻率不匹配。線索生成可以每天批量跑一次客戶畫像的行為部分需要準實時更新而轉(zhuǎn)化預(yù)測更適合按批次刷新——因為預(yù)測結(jié)果太頻繁變化銷售根本沒法安排跟進計劃今天看是高意向明天變低了人就會徹底不信任系統(tǒng)。拆成獨立的流水線之后每個環(huán)節(jié)可以按自己的節(jié)奏迭代不會有“改一個匹配規(guī)則畫像標簽也得跟著重新訓(xùn)練”這種連鎖反應(yīng)。第三個原因是最關(guān)鍵的可解釋性。銷售團隊天然抵觸黑盒系統(tǒng)。你告訴他“這個客戶得分 0.87去聯(lián)系吧”他一定會問憑什么。線索生成環(huán)節(jié)給出匹配理由畫像環(huán)節(jié)明確展示標簽依據(jù)預(yù)測環(huán)節(jié)輸出命中特征和行動建議每一層都可解釋銷售才愿意把你的輸出當(dāng)參考。否則系統(tǒng)做得再準前端業(yè)務(wù)不用就是零。最終落地的架構(gòu)并不復(fù)雜一個調(diào)度器每天按編排好的順序執(zhí)行“采集、清洗、規(guī)則匹配、向量匹配、畫像標注、模型預(yù)測、結(jié)果回寫”這幾個步驟各步驟之間通過數(shù)據(jù)庫表和消息隊列解耦。任何一個環(huán)節(jié)升級不影響其他環(huán)節(jié)。1.2 數(shù)據(jù)來源與合規(guī)邊界銷售 Agent 的地基是數(shù)據(jù)但數(shù)據(jù)獲取這一步最容易出事。我做線索生成時給自己定了一條硬約束只使用公開信息。具體來說有三類來源。第一類是企業(yè)公開工商信息包括公司名稱、注冊地、行業(yè)分類、注冊資本、經(jīng)營范圍這些信息來自依法公示的公開渠道。第二類是行業(yè)展會和活動的公開報名信息但必須做脫敏處理不能直接用報名表里的電話和郵箱只能提取“這家公司參加過什么主題的活動”這個意圖信號。第三類是公司官網(wǎng)和公開新聞里主動披露的業(yè)務(wù)描述、聯(lián)系方式這些本身是公司希望被外部看到的公開內(nèi)容。很多人會勸你“買數(shù)據(jù)”“爬私有平臺的數(shù)據(jù)”我強烈建議不要碰。一方面有法律風(fēng)險不該用的數(shù)據(jù)來源會直接讓整個系統(tǒng)失去合規(guī)基礎(chǔ)另一方面從商業(yè)角度也不劃算。我踩過的一個教訓(xùn)是曾經(jīng)拿到一批“看起來很豐富”的關(guān)系網(wǎng)數(shù)據(jù)導(dǎo)入之后發(fā)現(xiàn)電話號碼錯號率超過六成最后還得全部清洗掉。數(shù)據(jù)質(zhì)量遠比數(shù)據(jù)量重要這是做線索生成繞不開的第一課。1.3 技術(shù)棧與資源選型這套系統(tǒng)的技術(shù)棧非常主流沒有任何冷門框架核心原因就是團隊維護成本必須低。采集層用 Python 的 requests 加 Playwright。大部分公開頁面用普通請求就能拿到遇到少數(shù)需要渲染的頁面再用無頭瀏覽器兜底。清洗和特征加工用 pandas數(shù)據(jù)量在幾十萬到百萬級別單機內(nèi)存完全夠用。任務(wù)編排用的 APScheduler 加一張數(shù)據(jù)庫隊列表沒有引入重型調(diào)度框架——因為鏈路只有十幾個任務(wù)復(fù)雜調(diào)度器反而增加運維負擔(dān)。特征和畫像的存儲用 MySQL 寬表加 Redis 熱點緩存向量相似度計算直接全內(nèi)存跑開源中文向量模型編碼后歸一化點積幾萬條候選向量計算出結(jié)果只需要秒級。模型層主力是 LightGBMXGBoost 做交叉驗證對比。對外統(tǒng)一用 FastAPI 封裝成服務(wù)CRM 系統(tǒng)只需要調(diào)一個接口就能拿到線索列表和預(yù)測評分。這套選型的邏輯很簡單能用單機解決的不用分布式能用 SQL 解決的不用引入大數(shù)據(jù)組件能用一個團隊熟悉的語言解決的就不要搞異構(gòu)系統(tǒng)。我見過不少團隊上來就上全套大數(shù)據(jù)框架結(jié)果數(shù)據(jù)量連一張寬表都填不滿純屬給自己添麻煩。2. 線索生成模塊從零實現(xiàn)2.1 候選線索池的構(gòu)建與清洗線索生成的起點是候選池。這一步別急著上模型先把數(shù)據(jù)管道做扎實。我做的第一版采集任務(wù)特別粗糙就是定時去抓公開頁面然后把內(nèi)容整段塞進數(shù)據(jù)庫。上線第二天就出問題了同一條線索因為來源不同被插入了五次銷售跟進列表里出現(xiàn)大量重復(fù)還有一些頁面抓下來帶著亂碼和廣告位文字直接導(dǎo)致后續(xù)相似度計算質(zhì)量下降。后來我把清洗流程拆成五步每一步都有明確產(chǎn)出第一步去重用“行業(yè) 地域 聯(lián)系人歸一化 域名”拼接成指紋MD5 后建唯一索引第二步去噪剝離 HTML 標簽、去掉導(dǎo)航欄文案和版權(quán)聲明這類重復(fù)內(nèi)容第三步字段標準化統(tǒng)一公司名簡稱、統(tǒng)一地域?qū)懛ǖ谒牟铰?lián)系方式校驗號碼長度、號段規(guī)則都要過一遍明顯無效的剔除第五步給每條線索標記來源和首次入庫時間方便后續(xù)監(jiān)控數(shù)據(jù)新鮮度。這里有一個經(jīng)驗數(shù)據(jù)新鮮度一定要監(jiān)控。我踩過的坑是某個數(shù)據(jù)源連續(xù)兩周沒有增量更新但采集任務(wù)一直顯示“運行成功”因為 HTTP 請求返回了 200 但頁面結(jié)構(gòu)已經(jīng)變了解析結(jié)果為空。所以在線索表里一定要維護“最近更新時間”字段調(diào)度器每次檢查超過閾值就告警。數(shù)據(jù)源斷更這種問題不會立刻報錯但會像慢性病一樣腐蝕整個 Agent 的輸出質(zhì)量。2.2 規(guī)則引擎與向量召回的雙通道匹配線索生成的核心是“匹配”。我最終采用的是規(guī)則引擎加向量召回雙通道而不是單純跑一個模型。規(guī)則引擎解決的是業(yè)務(wù)硬約束。比如“只做華東地區(qū)的制造業(yè)客戶”“排除注冊資本低于 100 萬的個體工商戶”“排除已知黑名單行業(yè)”。這些約束用規(guī)則寫死清晰透明也方便業(yè)務(wù)方直接提需求。規(guī)則引擎的產(chǎn)出是候選集 A保證每一條候選都符合基本業(yè)務(wù)邊界。向量召回解決的是長尾機會。把公司簡介、主營產(chǎn)品、官網(wǎng)業(yè)務(wù)描述用文本向量模型編碼和理想客戶畫像向量做相似度計算取 top N 作為候選集 B。這部分能發(fā)現(xiàn)規(guī)則匹配不出來的機會比如一家公司官網(wǎng)寫著“提供柔性生產(chǎn)線解決方案”但工商經(jīng)營范圍里只有“機械設(shè)備銷售”光靠關(guān)鍵詞規(guī)則怎么都匹配不上向量卻能抓到語義上的相關(guān)性。雙通道的合并邏輯是候選集 A 全部保留候選集 B 中與 A 不重合的部分按相似度閾值截斷后加入。我實測下來單規(guī)則通道的有效線索率在 35% 左右單向量通道在 28% 左右雙通道合并之后有效線索率提升到了 45%因為規(guī)則通道保證了底線向量通道補足了多樣性。這里說的“有效線索”定義是銷售人工確認“這家公司確實有潛在需求”的比例后面要按這個口徑持續(xù)統(tǒng)計。2.3 匹配閾值怎么定才不是拍腦袋向量召回必須要有一個相似度閾值這一步最容易犯的錯誤是憑感覺定一個 0.6 或者 0.7 就開始跑。我在項目里做了一輪閾值掃描方法很簡單把歷史候選數(shù)據(jù)按相似度分桶從 0.5 到 0.75 每隔 0.05 算一組指標每組都統(tǒng)計覆蓋率、精準率、有效線索率然后畫成曲線看拐點。結(jié)果非常有意思閾值在 0.6 以下的時候覆蓋率雖然高但有效線索率只有 20% 出頭拉到 0.65 的時候覆蓋率掉了 15%但有效線索率升到了 38%再往上拉到 0.7覆蓋率又掉一大截有效線索率只增加兩個百分點。所以我的選擇是 0.65因為從業(yè)務(wù)角度看覆蓋率損失可以接受而精準率提升是實打?qū)嵉摹N售每天能打的電話數(shù)量是固定的與其給他們 100 條碰運氣的線索不如給 60 條更有把握的。另外匹配結(jié)果一定要給銷售留一個人工駁回入口。銷售在跟進列表里點“不相關(guān)”并選擇原因這些數(shù)據(jù)會回流到負樣本池既用于后續(xù)調(diào)閾值也用于模型訓(xùn)練。沒有這個反饋閉環(huán)匹配質(zhì)量永遠不會變好。3. 客戶畫像模塊從標簽到動態(tài)更新3.1 三層特征體系怎么搭客戶畫像不是簡單貼幾個標簽了事我把它拆成了三層特征體系。第一層是身份特征包括行業(yè)、地域、規(guī)模區(qū)間、成立年限、注冊資本區(qū)間。這些特征相對靜態(tài)來自采集和清洗階段的結(jié)構(gòu)化字段是畫像的底色。第二層是行為特征包括訪問官網(wǎng)頻次、打開郵件次數(shù)、下載資料次數(shù)、發(fā)起詢盤動作。行為來自埋點和業(yè)務(wù)系統(tǒng)的操作日志要求實時性好是判斷客戶當(dāng)前興趣度的核心。第三層是意向特征包括模型預(yù)測分區(qū)間、最近活躍時間、關(guān)鍵詞命中強度、線索來源質(zhì)量分。意向特征部分是模型輸出回傳的結(jié)果部分是規(guī)則計算的衍生指標。三層的關(guān)系可以這么理解身份特征決定“這家公司是不是我們的菜”行為特征決定“他最近有沒有對我們的菜動心”意向特征決定“現(xiàn)在是不是推一把的最佳時機”。單看任何一層都會失真。我見過一個極端例子一家身份特征非常匹配的客戶行為特征全為零如果只看身份特征會給高分但實際跟進發(fā)現(xiàn)對方需求已經(jīng)轉(zhuǎn)移了反過來也有身份特征不太匹配但連續(xù)兩周高頻訪問定價頁面的客戶最后反而成交了。3.2 標簽存儲與冷啟動更新策略標簽存儲這塊很多人會過度設(shè)計動不動就上圖數(shù)據(jù)庫。我這次用非常樸素的方式解決了一張客戶主表存身份特征和靜態(tài)標簽一張行為匯總表存統(tǒng)計類特征一張 JSON 擴展列存動態(tài)標簽。單表一百萬級別的客戶配合 Redis 緩存熱點數(shù)據(jù)查詢性能完全夠用開發(fā)效率還高。動態(tài)標簽必須考慮時間衰減。我的策略是行為特征按時間窗口計算比如近 7 天、近 30 天、近 90 天的訪問次數(shù)分別統(tǒng)計意向標簽則做加權(quán)衰減30 天無任何動作的客戶意向分自動下降一檔。標簽不是貼上就永遠有效的客戶的興趣會衰退你的標簽體系也得跟著腐爛。冷啟動是新線索繞不開的問題。沒有行為數(shù)據(jù)的客戶唯一的依據(jù)就是身份特征和線索生成階段的匹配分。我的處理方式是冷啟動客戶先打一個“待觀察”標簽預(yù)測分數(shù)給一個中性偏保守的值等行為數(shù)據(jù)積累超過一周再進入正式畫像計算。實測這樣做的好處是避免了大量冷啟動客戶被高估意向銷售跟進無效電話的投訴明顯減少。3.3 畫像質(zhì)量驗證不要相信拍腦袋標簽畫像模塊最容易出的事是工程師覺得標簽體系設(shè)計得很完美但業(yè)務(wù)根本看不懂。我在上線前做了一次標簽可用性評審從線上隨機抽了 100 條已標注客戶讓銷售團隊人工核實“這個標簽是否符合你對這家公司的了解”。結(jié)果三檔分布是符合 62 條模糊 26 條不符合 12 條。模糊和不符合加起來快四成了說明標簽定義和業(yè)務(wù)的認知有偏差。比如我把“活躍”定義成“近 30 天有任意行為”但銷售認為“活躍”必須是“有實質(zhì)互動比如打開郵件或點擊鏈接單純訪問不算”。后來把標簽口徑重新對齊把“弱活躍”和“強活躍”分開模糊比例降到了 15% 以內(nèi)。畫像驗證這件事要周期性地做不能上線驗一次就再也不管。數(shù)據(jù)分布會漂移業(yè)務(wù)重點會調(diào)整標簽體系也需要持續(xù)維護否則三個月后畫像就成了一堆沒人看的僵尸標簽。4. 轉(zhuǎn)化預(yù)測模塊模型與樣本工程4.1 正負樣本定義與觀察期設(shè)置轉(zhuǎn)化預(yù)測是整個 Agent 里最講究“科學(xué)方法”的模塊。第一步就是定義清楚什么是正樣本、什么是負樣本這一步如果定義錯了后面所有模型工作都白做。我用的正樣本定義是線索進入系統(tǒng)后 90 天內(nèi)發(fā)生有效詢盤或成交標記的客戶。負樣本定義是90 天內(nèi)銷售關(guān)閉且沒有任何有效互動的客戶。注意這里加了一個“進入系統(tǒng) 90 天”的觀察期約束——只有觀察期內(nèi)沒有被標記為成交也沒有被關(guān)閉的客戶才能作為樣本進入模型訓(xùn)練。為什么不能簡單把“當(dāng)前已經(jīng)是客戶”的標成正樣本、把“還沒成交”的標成負樣本因為那些“還沒成交”的客戶可能只是還在跟進中把他當(dāng)負樣本會嚴重扭曲模型。樣本定義還有一個容易踩的坑正負樣本比例。銷售場景下正樣本往往很少可能只有 5% 到 10%。這個比例下 LightGBM 很容易出現(xiàn)“全預(yù)測為負樣本”的偷懶行為所以訓(xùn)練時要設(shè)置正負樣本權(quán)重或者用采樣策略讓模型見到的正例比例提高到 20% 左右。我整理樣本集時最終保留了約 8 萬條觀察期內(nèi)的樣本正樣本占比 7%按正負 1:4 的權(quán)重配比訓(xùn)練。4.2 時間穿越陷阱與特征一致性時間穿越是我在這個項目里踩過最大的坑沒有之一。典型表現(xiàn)是驗證集上的 AUC 高達 0.9 以上看著爽到不行一上線就效果崩盤。原因就是特征工程里用了“未來數(shù)據(jù)”。舉個例子我要在 T 日預(yù)測某個客戶會不會在未來 90 天內(nèi)轉(zhuǎn)化那么模型輸入只能包含 T 日之前能拿到的信息。我做特征的時候好的一版是“截至預(yù)測日止近 30 天訪問次數(shù)”壞的一版是直接用整張匯總表里“總訪問次數(shù)”——后者包含了預(yù)測日之后才發(fā)生的行為在訓(xùn)練時等于偷偷看了答案。防止時間穿越的幾條硬規(guī)矩我寫進了項目文檔第一所有行為特征必須帶時間窗口不能存在“全量累計值”這種特征第二訓(xùn)練集和驗證集必須按時間切分不能用隨機抽樣——用驗證集數(shù)據(jù)里未來時間段的信息去預(yù)測過去指標必然虛高第三特征工程代碼和預(yù)測代碼必須共用同一套函數(shù)不能在訓(xùn)練時寫一套 SQL、預(yù)測時寫另一套。我那次的排查過程很典型。模型上線三周后銷售反饋“系統(tǒng)給的 90 分客戶打過去基本沒反應(yīng)”我拉數(shù)據(jù)一看預(yù)測分在中高分段大量堆積?；夭樘卣鞑虐l(fā)現(xiàn)某個行為特征在訓(xùn)練階段用了全量統(tǒng)計而預(yù)測階段實時計算只能拿到截止當(dāng)前的數(shù)據(jù)。修正之后 AUC 從虛高的 0.9 降到了 0.82但整個系統(tǒng)的可信度反而回來了。4.3 模型選型、特征篩選與業(yè)務(wù)閾值算法選擇上沒有太多花活。主力是 LightGBMXGBoost 作為交叉驗證的對照組。對比下來 LightGBM 在這個數(shù)據(jù)量級下訓(xùn)練速度快一倍精度相當(dāng)所以最后生產(chǎn)環(huán)境用了 LightGBM。類別特征的處理上高基數(shù)的標簽比如行業(yè)細分、來源渠道用了頻數(shù)編碼和標簽編碼的組合沒有做 one-hot——幾十個類別做 one-hot 可以接受幾百個上千個類別做 one-hot 就是在自找麻煩。特征數(shù)量最終控制在 80 個左右。篩選過程用 LightGBM 的特征重要性排序輔助但更重要的是做了一輪業(yè)務(wù)側(cè)的人工特征審查把明顯不合理的特征直接剔除。比如說“客戶官網(wǎng)建站年份”這種特征相關(guān)性很弱留它只會增加過擬合風(fēng)險。模型評估指標上我只看了兩個數(shù)時間外驗證的 AUC以及按分數(shù)分桶后的實際轉(zhuǎn)化率單調(diào)性。前者衡量排序能力后者衡量業(yè)務(wù)可用性。AUC 0.82 左右、分桶轉(zhuǎn)化率從 3% 到 25% 單調(diào)遞增這個模型才算達到可上線標準。閾值選擇同樣不能拍腦袋我按預(yù)測分從高到低切成 Top 5% 到 Top 30% 幾個檔位統(tǒng)計每個檔位覆蓋的預(yù)期成交客戶數(shù)和電話量成本最后選了 Top 15% 作為銷售優(yōu)先跟進線因為再往下拉新增線索的電話成本會翻倍但新增轉(zhuǎn)化很少。4.4 可解釋性與銷售采納模型要落地必須讓銷售理解為什么。我做了兩個很簡單的設(shè)計。一個是在線索詳情頁展示“命中特征 TOP 3”。比如“命中特征近 30 天訪問官網(wǎng) 12 次、行業(yè)標簽匹配、中大型規(guī)模區(qū)間”銷售一眼就能明白這條線索為什么分數(shù)高。另一個是給出行動建議文案根據(jù)預(yù)測分和畫像標簽組合生成比如“高活躍、多標簽命中建議兩天內(nèi)電話跟進”“活躍度低但畫像高度匹配建議先發(fā)資料培育”。沒有這兩步模型再準也沒用。我見過太多算法團隊把預(yù)測分數(shù)做成一個 API前端直接展示一個孤零零的數(shù)字銷售根本不買賬。銷售需要的是“System 告訴我現(xiàn)在該干什么”不是一個抽象的概率。所以行動建議這部分一定要讓業(yè)務(wù)方參與設(shè)計哪怕只是簡單的規(guī)則模板人機信任感也會完全不同。5. Agent 鏈路集成與工程落地5.1 任務(wù)編排與依賴管理三塊模塊各自開發(fā)完之后真正的挑戰(zhàn)在于如何把它們編排成一條穩(wěn)定運行的鏈路。我的做法是數(shù)據(jù)庫隊列表加狀態(tài)機。隊列表里每一條任務(wù)記錄包括任務(wù)類型、依賴條件、狀態(tài)、開始時間、結(jié)束時間、重試次數(shù)、錯誤信息。狀態(tài)機只有四種狀態(tài)pending、running、success、failed。調(diào)度器每隔一分鐘掃一次把滿足依賴條件的 pending 任務(wù)拉起失敗的任務(wù)重試最多三次三次都失敗就置為 failed 并觸發(fā)告警。實際跑的調(diào)度鏈是這樣每天凌晨兩點觸發(fā)采集任務(wù)采集完觸發(fā)清洗清洗完成之后并行跑規(guī)則匹配和向量編碼兩道匹配都完成之后合并候選池再按客戶 ID 觸發(fā)畫像更新畫像更新完成后跑轉(zhuǎn)化預(yù)測預(yù)測結(jié)果寫回業(yè)務(wù)表早上八點前把當(dāng)日優(yōu)先跟進列表推送到銷售工作臺。每步任務(wù)的耗時在分鐘級全鏈路跑完大概四十分鐘。為什么用數(shù)據(jù)庫隊列表而不是直接寫一個 Python 腳本按順序執(zhí)行因為線上環(huán)境一定有任務(wù)失敗直接順序執(zhí)行會讓“某一個環(huán)節(jié)失敗導(dǎo)致整條鏈路不跑”變成常態(tài)。狀態(tài)機的好處是某一步依賴失敗其他任務(wù)可以跳過它繼續(xù)跑等下一次調(diào)度重試時再補上。5.2 性能優(yōu)化與外部依賴容錯這套系統(tǒng)在性能上其實壓力不大。幾百個采集源、幾十萬客戶庫、每天新增幾千條線索單機完全能扛住。真正容易翻車的是外部請求的不確定性。我對外部采集請求做了統(tǒng)一封裝核心參數(shù)是連接超時 10 秒、讀取超時 30 秒、失敗重試 3 次、退避策略用指數(shù)退避。沒有這套容錯任何一個外部源的偶發(fā)超時都可能拖死整條采集鏈路。向量匹配的性能優(yōu)化用了一個小技巧預(yù)先把所有候選公司的向量矩陣加載到內(nèi)存新線索到來時用歸一化點積計算相似度幾萬條候選只需要幾百毫秒。幾百毫秒看起來無所謂但如果每天要跑幾千條候選性能差距會實打?qū)嵱绊懻{(diào)度鏈路的耗時。數(shù)據(jù)量上也預(yù)留了擴展空間。如果客戶池增長到千萬級別內(nèi)存向量匹配會吃力到時候再引入近似最近鄰索引現(xiàn)階段單機的方案簡單可靠完全夠用。5.3 人機協(xié)同閉環(huán)Agent 給建議人為 Agent 糾偏Agent 跑得再順也必須有一條人機協(xié)同的反饋回路。線索生成給銷售的是候選建議銷售跟進完要標記“有意向”“無需求”“暫時不匹配”三種結(jié)果預(yù)測模型給銷售的是分數(shù)銷售要去執(zhí)行跟進動作跟進結(jié)果會作為新的樣本回流到訓(xùn)練集。我做過一個體驗很好的功能銷售在系統(tǒng)中對線索點“不感興趣”時必須選擇一個原因標簽比如“行業(yè)不符”“規(guī)模不符”“需求已被滿足”。這些原因會實時進入線索生成模塊的規(guī)則引擎如果某類原因積累超過一定數(shù)量對應(yīng)的規(guī)則權(quán)重自動下調(diào)。另一個功能是每周一自動生成模型診斷報告包括分數(shù)分布、成交轉(zhuǎn)化率、特征重要性變化讓算法團隊每周花半小時確認系統(tǒng)沒有跑偏。沒有這條閉環(huán)Agent 一定越跑越偏。數(shù)據(jù)分布會漂移銷售策略會調(diào)整市場環(huán)境會變化靜態(tài)的系統(tǒng)就像沒有方向盤的車直線跑一段還可以時間一長必然偏離方向。6. 常見問題與排查實錄6.1 線索重復(fù)率高怎么辦現(xiàn)象銷售反饋同一個公司出現(xiàn)在跟進列表里多次。原因不一定是采集重復(fù)也可能是規(guī)則匹配把所有關(guān)聯(lián)公司都帶出來了。我的處理方式是加多層去重第一層指紋去重過濾完全相同的記錄第二層按域名和工商注冊號做相似合并第三層是把同一集團下的強關(guān)聯(lián)公司打上“集團提示”標簽讓銷售知道這兩家可能是一個老板。去重之后重復(fù)率從 12% 降到了 3% 以內(nèi)。6.2 畫像標簽覆蓋率不足現(xiàn)象上線后運行了兩周統(tǒng)計標簽覆蓋率只有 60%大量線索只有身份標簽沒有行為標簽和意向標簽。原因有兩條一是行為埋點數(shù)據(jù)接入得晚老線索沒有歷史行為二是部分外部來源的線索本身信息就少。處理方式是放寬統(tǒng)計窗口把“近 30 天行為”放寬到“近 90 天行為”先頂一陣子同時加快行為埋點的歷史數(shù)據(jù)回補。這件事本質(zhì)上是數(shù)據(jù)歷史問題不是模型問題急不來。6.3 預(yù)測分整體過高區(qū)分度消失現(xiàn)象模型上線一段時間后80% 以上客戶的預(yù)測分都集中在高分段銷售看不出誰該優(yōu)先跟進。排查后發(fā)現(xiàn)是特征泄漏某個特征包含了未來信息模型學(xué)到了一個虛假的高相關(guān)關(guān)系。按 4.2 的方式修正特征后分數(shù)分布恢復(fù)成“高分段少而精、中分段平穩(wěn)”的健康形態(tài)。這里想強調(diào)的是分數(shù)分布一定要納入日常監(jiān)控異常往往在業(yè)務(wù)投訴之前就能發(fā)現(xiàn)。6.4 外部數(shù)據(jù)源突然斷更現(xiàn)象采集任務(wù)一直顯示成功但線索表新增量為零。排查發(fā)現(xiàn)是頁面結(jié)構(gòu)改版解析規(guī)則失效程序沒有報錯只是抓回空列表。處理方式是加數(shù)據(jù)新鮮度監(jiān)控線索表每日新增量低于閾值即告警同時給每個采集源單獨配置“最近更新時間”指標。這個問題給了我的一個教訓(xùn)不要只監(jiān)控任務(wù)是否執(zhí)行成功要監(jiān)控任務(wù)產(chǎn)出的結(jié)果是否合理。6.5 銷售反饋“打過去都不相關(guān)”現(xiàn)象銷售對系統(tǒng)推薦的線索滿意度下降反饋集中在“行業(yè)不對”“已經(jīng)不是目標市場了”。處理方式分兩步第一步上調(diào)向量匹配閾值寧可少推也不亂推第二步把銷售的駁回原因做成負樣本重新校準畫像標簽權(quán)重。調(diào)完之后的直接變化是銷售優(yōu)先跟進列表的撥打量下降了 20%但有效通話時長提升了 30%。對銷售工具來說“不該推的少推”比“該推的多推”更重要。6.6 排查實錄一次差點上線的事故上線前最后一周我用最近三個月的線上數(shù)據(jù)重新回測模型發(fā)現(xiàn) AUC 從 0.82 掉到了 0.79。第一反應(yīng)是數(shù)據(jù)出問題了查了整整三天才發(fā)現(xiàn)是畫像模塊新增了一個“近期瀏覽競品頁面”的事件標簽但這個事件回傳的數(shù)據(jù)只覆蓋了新客戶老客戶全為空值等于特征上有了缺失模式偏差。這個問題的麻煩在于模型訓(xùn)練用的是全量客戶預(yù)測時老客戶的該特征為空會被填充成“無行為”但新客戶的該特征有真實值。模型學(xué)到的是“這個特征為空代表老客戶”而不是“有瀏覽競品行為的客戶意向更高”。最后處理方式是放棄這個特征等數(shù)據(jù)覆蓋率到 80% 以上再考慮加入。這件事提醒我新增特征之前要做覆蓋率評估不能因為某類新數(shù)據(jù)的采集方式很順就急著進模型。7. 沉淀下來的幾點經(jīng)驗如果讓我只保留幾條最值得說的經(jīng)驗我會選這幾條。第一銷售 Agent 的成敗往往不取決于模型多先進而取決于數(shù)據(jù)管道、特征時序和反饋閉環(huán)是否扎實。我見過太多團隊把精力花在換更強的大模型上忽略了數(shù)據(jù)質(zhì)量結(jié)果照樣效果拉胯。第二時間穿越是轉(zhuǎn)化預(yù)測最危險也最隱蔽的錯誤來源所有特征必須有明確的時間窗口評估必須按時間切分上線后必須監(jiān)控分數(shù)分布。第三系統(tǒng)要給業(yè)務(wù)留反饋入口不能只做單向輸出。銷售推動跟進結(jié)果模型才能持續(xù)迭代否則就是一個越跑越偏的靜態(tài)腳本。這套系統(tǒng)后續(xù)的擴展方向還很清晰引入更細粒度的行為序列建模補充多觸點歸因以及把預(yù)測結(jié)果直接接到自動化的觸達動作上。不過這些都是后話了先把現(xiàn)有的閉環(huán)跑穩(wěn)讓銷售團隊真正把 Agent 當(dāng)作每天工作的第一站才是從 0 到 1 之后最重要的事。我個人在實際操作中最深的體會是搭銷售 Agent 本質(zhì)上是在把銷售團隊的經(jīng)驗結(jié)構(gòu)化。模型學(xué)到的每一條規(guī)律其實都是銷售老手已經(jīng)知道的經(jīng)驗系統(tǒng)能做的是讓這些經(jīng)驗以穩(wěn)定的、可放大的方式用在每一個客戶身上。想清楚這一點你就知道該把時間花在哪里了——不是堆模型而是把經(jīng)驗翻譯成數(shù)據(jù)、特征和規(guī)則。