大家好，我們是成都小火科技，今天是2025年6月29日，星期天。我們公司成立于2013年，有自己的全棧技術開發(fā)團隊。目前我們開發(fā)的軟件系統(tǒng)中，90%都有AI的功能?？梢赃@樣說，有了AI之后，傳統(tǒng)的軟件都需要即時接入AI功能。今天就以我們開發(fā)過的「智能供應鏈預測系統(tǒng)」為例，聊聊AI軟件開發(fā)的具體流程。

記得2024年接這個項目時，客戶是一家連鎖零售企業(yè)，他們希望系統(tǒng)能根據(jù)歷史銷售數(shù)據(jù)預測未來三個月的庫存需求。當時我們第一時間做的不是寫代碼，而是開了整整三天的需求分析會。我們拿著白板梳理業(yè)務邏輯，確定AI模塊需要解決的核心問題：是要處理時序數(shù)據(jù)的季節(jié)性波動，還是要考慮促銷活動對銷量的影響？最后我們在需求文檔里明確了技術指標：預測誤差率要控制在8%以內，模型響應時間不超過200ms。

接下來進入數(shù)據(jù)階段。這個項目我們總共接入了12個數(shù)據(jù)源，包括POS系統(tǒng)的銷售數(shù)據(jù)、ERP的庫存數(shù)據(jù)、甚至還有天氣API的數(shù)據(jù)。記得當時數(shù)據(jù)工程師花了兩周時間做數(shù)據(jù)清洗，發(fā)現(xiàn)有30%的銷售記錄缺少門店編號，還有15%的庫存數(shù)據(jù)存在異常峰值。我們用Python的pandas庫做數(shù)據(jù)插值，用IsolationForest算法識別異常值，光數(shù)據(jù)預處理的代碼就寫了2000多行。后來在模型訓練時才發(fā)現(xiàn)，這些數(shù)據(jù)清洗的工作有多重要——最初用原始數(shù)據(jù)訓練的LSTM模型誤差率高達18%，優(yōu)化數(shù)據(jù)后直接降到了10%。

模型選型階段我們做了AB測試。先是用傳統(tǒng)的ARIMA模型，發(fā)現(xiàn)對促銷活動的響應不夠靈敏；然后試了LSTM神經(jīng)網(wǎng)絡，雖然能捕捉時間序列的規(guī)律，但計算量太大，服務器扛不住；最后決定用Facebook的Prophet模型，搭配XGBoost做特征工程。調參過程挺折騰的，記得為了確定Prophet里changepoint_prior_scale參數(shù)的值，我們從0.05試到5，每調一次參數(shù)就要跑8小時的訓練，整整一周才找到最優(yōu)解0.3。

集成開發(fā)時遇到了架構設計的挑戰(zhàn)。我們原本想把AI模型直接嵌入后端服務，但發(fā)現(xiàn)每次模型更新都要重啟整個服務，很不方便。后來改成微服務架構，單獨做了一個AI預測服務模塊，用gRPC協(xié)議和其他服務通信。這個模塊里我們用TensorFlow Serving部署模型，用Redis做預測結果的緩存，前端請求過來先查緩存，沒有的話再調用模型計算，響應時間從原來的500ms降到了150ms。

測試階段有個有意思的插曲。我們用歷史數(shù)據(jù)做離線測試時，模型誤差率穩(wěn)定在7.5%，但上線試運行第一天就出了問題——下午三點的預測數(shù)據(jù)突然偏差很大。后來發(fā)現(xiàn)是當天有臨時促銷活動，而我們的模型沒接入實時的活動數(shù)據(jù)接口。于是趕緊迭代版本，增加了活動數(shù)據(jù)的實時接入通道，還做了動態(tài)權重調整，現(xiàn)在遇到突發(fā)活動時，模型能在10分鐘內調整預測策略。

現(xiàn)在這個系統(tǒng)已經(jīng)運行一年多了，我們每個月都會做模型復盤。上個月剛把Prophet模型升級成了Transformer架構，預測誤差率又降低了1.2%。其實AI軟件開發(fā)和傳統(tǒng)軟件開發(fā)最大的不同，就是它需要持續(xù)的模型優(yōu)化。就像我們給系統(tǒng)加了個「自進化」模塊，每天凌晨會用最新的24小時數(shù)據(jù)微調模型，就像人每天學習新知識一樣。

前幾天客戶還打電話來說，用了我們的系統(tǒng)后，他們的庫存周轉率提升了22%，缺貨率下降了18%。聽到這些數(shù)據(jù)，我們團隊都挺有成就感的。其實AI軟件開發(fā)就像搭積木，每個環(huán)節(jié)都得嚴絲合縫，從數(shù)據(jù)清洗到模型部署，每個步驟都藏著技術細節(jié)，只有把這些細節(jié)都摳到位，才能做出真正能用的AI系統(tǒng)。

文章來源網(wǎng)址：http://www.jt-toy.com/archives/xitongkaifa01/1948，轉載請注明出處！