資深技術專家 陳科

在數(shù)字技術持續(xù)重構產(chǎn)業(yè)格局的今天，從分布式架構到人工智能的技術躍遷，正成為傳統(tǒng)金融行業(yè)數(shù)字化轉型的核心驅動力，而大模型與企業(yè)級知識服務的深度融合，更是券商在科技賦能業(yè)務中的關鍵探索方向。

如何將互聯(lián)網(wǎng)高并發(fā)、微服務與 PaaS 架構的成熟經(jīng)驗，遷移至強合規(guī)、高穩(wěn)定的金融技術體系；如何通過大模型與企業(yè)知識庫建設，破解內(nèi)部知識沉淀、場景落地、數(shù)據(jù)安全與應用實效等核心難題，成為金融科技領域亟待突破的焦點議題。

近日，我們有幸邀請到資深技術專家陳科老師，圍繞技術轉型與能力沉淀、金融數(shù)字化架構實踐、企業(yè)級大模型平臺建設、職業(yè)成長與技術路徑選擇，為理解全棧技術能力如何支撐金融 AI 轉型、重構企業(yè)技術價值提供深度洞察。

01

風采展示

問1：您好，陳老師！很榮幸有機會采訪到您，先簡單介紹一下您自己！

謝謝主持人，也很高興和大家交流。

我2012年畢業(yè)后進入互聯(lián)網(wǎng)行業(yè)，早期在網(wǎng)易和vivo主要做中間件研發(fā)、微服務架構和PaaS基礎設施，長期和高并發(fā)、分布式系統(tǒng)、服務治理這些問題打交道。后來進入證券行業(yè)，參與金融科技平臺和數(shù)字化轉型相關工作，把互聯(lián)網(wǎng)架構思維帶到金融場景里。最近兩年，隨著大模型技術的發(fā)展，我又把工作重心逐步轉向企業(yè)知識庫和大模型應用落地。一路走來，從中間件到平臺，再到AI應用，我一直在做一件事，就是用技術解決復雜業(yè)務問題。

問題2：從互聯(lián)網(wǎng)到券商，再切入大模型，三次大的方向躍遷，您是如何快速建立新領域認知，并把過往經(jīng)驗遷移過去的？

我進入一個新領域，通常先做三件事。第一，快速建立全局認知，先把業(yè)務鏈路、核心系統(tǒng)、關鍵約束搞清楚。第二，分辨哪些是行業(yè)特有的，哪些是通用規(guī)律。比如架構設計、穩(wěn)定性治理、平臺化建設，這些底層方法在很多行業(yè)都是通的；變化更多是在業(yè)務語義、監(jiān)管要求和落地方式上。第三，就是盡快通過真實項目把認知壓實。因為很多東西只有做過才真正理解。對我來說，跨領域不是推倒重來，而是把過去積累的能力，在新問題上重新組合、持續(xù)升級。

問題3：隨著技術的快速發(fā)展，如何保持對新技術、新趨勢的敏感度？你平時通過哪些渠道獲取行業(yè)前沿信息，又是如何篩選和判斷哪些信息對自己有價值并值得深入學習的？

我覺得保持敏感度很重要，但更重要的是判斷力。平時我主要通過幾個渠道獲取信息：一是頭部技術公司、云廠商、開源社區(qū)和技術博客，二是行業(yè)會議和同行交流，三是和業(yè)務、監(jiān)管相關的信息。因為尤其在金融行業(yè)，技術能不能落地，不只是看先進不先進，還要看業(yè)務價值和合規(guī)邊界。至于篩選，我主要看四點：是不是在解決真實問題，能不能工程化落地，和當前業(yè)務階段是否匹配，能不能沉淀成長期能力。很多熱點我不會一上來就重投入，而是先做小范圍驗證，看效果、成本和復雜度，再決定要不要深入。

02

微服務架構與PaaS基礎設施

問題4：在金融行業(yè)進行數(shù)字化轉型過程中，遇到了哪些技術難點和問題，是如何解決這些問題的？

金融行業(yè)數(shù)字化轉型最大的難點，不是在新系統(tǒng)上做建設，而是在大量存量系統(tǒng)之上做升級。這里面往往是多廠商、多技術棧、強監(jiān)管、不能輕易中斷，這幾個問題疊加在一起。我們的做法不是一刀切替換，而是先做分層治理和標準化接入。通過統(tǒng)一網(wǎng)關、統(tǒng)一 API 管理、服務邊界梳理，把新老系統(tǒng)逐步接起來。對于受監(jiān)管業(yè)務，則強調(diào)訪問隔離，核心服務盡量放在私有域里，對外只通過全局網(wǎng)關暴露有限 API，并做好鑒權和權限控制。同時在治理上，把核心 API、高延遲 API、外部 API 做分組隔離，發(fā)布必須灰度、滾動、可回滾。我的體會是，金融行業(yè)轉型的關鍵不是上了多少新技術，而是能不能在復雜存量和強監(jiān)管約束下，穩(wěn)步演進。

問題5：在微服務架構落地過程中，服務治理、限流、熔斷、降級這幾塊，您踩過最致命的坑是什么？

這個更多是我在互聯(lián)網(wǎng)公司時期做高并發(fā)系統(tǒng)時的經(jīng)驗。踩得最深的坑，其實是治理策略過于粗暴，把局部問題放大成整體問題。比如下游只是少量實例抖動，但上游熔斷做得太粗，一觸發(fā)就把整個服務都熔斷了，結果本來只是局部異常，最后變成全鏈路不可用。還有一種情況是限流只考慮‘攔’，沒有考慮‘攔完以后怎么辦’，所有請求直接失敗，核心和非核心業(yè)務沒有區(qū)分，限流、熔斷、降級沒有按照層級和維度去區(qū)分，導致用戶體驗會非常差。我記得在網(wǎng)易工作時，APP推薦首頁就是一個高并場景，我們就是通過不同層級，不同維度去落地的，例如按照用戶比例去限流和降級，保障確保VIP用戶正?？捎茫Ｕ掀胀ㄓ脩粼谟|發(fā)降級時看到的兜底內(nèi)容是一致的。再就是重試配置不當，本來是為了提高成功率，結果在高并發(fā)下反而把下游打穿了。

所以我后來最大的經(jīng)驗是，限流、熔斷、降級一定要分層、分級、分粒度設計，不能用統(tǒng)一模板一把梭。

問題6：做高并發(fā)系統(tǒng)時，是如何做容量規(guī)劃、壓測體系與全鏈路監(jiān)控的？有哪些關鍵指標？

這部分也是我在互聯(lián)網(wǎng)時期的工作體會。高并發(fā)系統(tǒng)最核心的，不是流量來了能不能扛一次，而是你知不知道自己的邊界在哪里。容量規(guī)劃上，我一般會從業(yè)務峰值倒推整條鏈路，包括網(wǎng)關、應用、緩存、數(shù)據(jù)庫、消息隊列和外部依賴，最后形成容量模型，并且預留冗余。壓測體系不能只做單接口壓測，還要做核心場景壓測、混合流量壓測、全鏈路壓測，甚至故障演練，驗證系統(tǒng)在異常情況下能不能穩(wěn)住。監(jiān)控方面，除了 CPU、內(nèi)存這些基礎指標，更要看 QPS、TPS、P95、P99、錯誤率、超時率、線程池、連接池、消息積壓，以及關鍵業(yè)務成功率。我的經(jīng)驗是，真正的穩(wěn)定性來自提前發(fā)現(xiàn)邊界，而不是出問題后再補救?！?/p>

03

技術實踐與落地

問題7：在券商內(nèi)部建設企業(yè)知識庫平臺時，如何選擇適合金融領域知識處理的大模型，考慮了哪些模型性能指標和金融業(yè)務特點，不同模型之間有哪些差異和優(yōu)劣？

企業(yè)知識庫平臺的核心，其實不只是選模型，而是知識治理、檢索體系、權限體系和模型能力的整體組合。金融場景里，不能簡單追求‘哪個模型最強’，而要先看場景到底要解決什么問題，是問答、檢索、總結、審核，還是結構化抽取。選型時我主要看幾個指標：專業(yè)理解能力、事實準確性、幻覺控制、長文本處理能力、結構化輸出能力、響應速度和部署成本。同時還要重點考慮私有化、安全隔離和審計留痕。閉源模型通常通用能力更強、效果更穩(wěn)定，適合快速驗證；開源模型則更可控、更適合私有化和深度定制。所以實際落地時，往往不是單模型，而是基座模型、Embedding、Rerank、規(guī)則和權限系統(tǒng)組合起來一起工作。

問題8：券商擁有海量但分散的數(shù)據(jù)，大模型應用需要高質(zhì)量、結構化的數(shù)據(jù)支持，如何建立有效的數(shù)據(jù)治理體系，對數(shù)據(jù)進行清洗、整合和標注，為大模型提供優(yōu)質(zhì)的數(shù)據(jù)輸入，有哪些數(shù)據(jù)治理工具和流程？

我一直認為，大模型在企業(yè)里的上限，很多時候是由數(shù)據(jù)治理決定的。券商的數(shù)據(jù)特點不是少，而是多、散、雜，而且權限邊界復雜、口徑不統(tǒng)一。所以第一步一定是數(shù)據(jù)盤點和分類分級，先搞清楚數(shù)據(jù)歸誰管、能不能用、有沒有敏感風險。第二步是標準化清洗和結構化處理，包括去重、糾錯、版本識別、元數(shù)據(jù)補全、標簽和摘要生成。第三步是權限和安全治理，要做到按業(yè)務域、按部門、按角色細粒度授權。第四步是效果反饋閉環(huán)，根據(jù)召回準確率、人工審核意見和實際使用效果持續(xù)優(yōu)化。工具上會涉及文檔解析、OCR、元數(shù)據(jù)管理、脫敏、標注審核、向量檢索和評測體系，但核心還是要形成持續(xù)迭代的數(shù)據(jù)治理流程。

問題9：金融監(jiān)管政策不斷更新變化，大模型在券商應用中如何確保實時跟進并滿足新的合規(guī)要求，例如在反洗錢、投資者適當性管理等場景，有沒有建立動態(tài)的合規(guī)監(jiān)測機制嵌入到大模型應用流程中？

在券商場景里，大模型不能只追求能力強，更要追求可控、可審計、可糾偏。我的理解是，合規(guī)必須前置，嵌入整個應用流程，而不是事后補丁。我們的思路是把外部監(jiān)管要求和內(nèi)部制度要求持續(xù)沉淀成動態(tài)更新的知識和制度體系，也就是常說的‘外規(guī)內(nèi)化’。具體做法上，一層是知識檢索，確保模型引用的是最新、權威的制度依據(jù)；一層是規(guī)則校驗，對敏感內(nèi)容和關鍵場景做硬約束；再往上是人工復核和審計留痕。像反洗錢、投資者適當性管理這些場景，我認為大模型更適合做輔助識別、歸納總結和風險提示，而不應該直接替代最終判斷。這樣既能提高效率，也能守住合規(guī)底線。

04

行業(yè)洞察與未來思考力

問題10：隨著大模型技術的不斷發(fā)展，未來在券商業(yè)務中還可能拓展出哪些新的應用場景，對于這些潛在場景，目前做了哪些前瞻性的研究和準備？

我覺得未來大模型在券商里的應用空間會非常大，而且不會只停留在智能問答這種淺層場景。隨著模型能力、工具調(diào)用能力和企業(yè)治理能力逐步成熟，它會從信息輔助，慢慢走向流程輔助，再進一步走向業(yè)務協(xié)同。

具體看，我比較看好的方向有幾類：一類是“外規(guī)內(nèi)化”，比如監(jiān)管規(guī)則理解、制度對齊、變更影響分析、執(zhí)行檢查等，幫助機構把外部規(guī)則更快轉化成內(nèi)部可執(zhí)行能力；第二類是“數(shù)字員工”，比如投研、運營、合規(guī)、研發(fā)、客服等崗位的輔助；第三類是“智能工具化”場景，比如合同審核、制度文件審核、會議紀要、知識檢索、材料撰寫等，這類場景邊界清晰、收益也更容易驗證，應該優(yōu)先落地。再往后，還可以逐步延伸到投顧輔助、財富管理、投行業(yè)務支持、風險排查、培訓傳承等更深層業(yè)務。

不過我覺得現(xiàn)階段也不能太激進，更現(xiàn)實的策略還是優(yōu)先瞄準業(yè)內(nèi)相對成熟的場景，讓子彈先飛一會。因為開源模型和智能體方案迭代非?？?，今天花很大力氣做的定制優(yōu)化，可能下一次模型升級后就被快速覆蓋，收益反而不如直接升級模型。比如有些最近很火的開源 Agent 方案，更適合個人產(chǎn)品，離企業(yè)級、強合規(guī)的券商場景還有距離。所以我認為現(xiàn)階段更重要的是先把知識庫、智能體平臺、模型服務平臺和安全治理底座搭好，為后續(xù)規(guī)?；涞刈鰷蕚洹?/p>

問題11：大模型正在重構技術棧，你認為未來工程師的核心能力模型會發(fā)生怎樣的變化？

我認為未來工程師的核心能力模型會繼續(xù)上移，但不是簡單地從“代碼實現(xiàn)者”變成“系統(tǒng)設計者”，因為今天的大模型和智能編程工具已經(jīng)開始深入?yún)⑴c設計本身。真正稀缺的能力，將越來越體現(xiàn)在對問題和約束的定義、對方案優(yōu)劣的判斷、對復雜系統(tǒng)的取舍，以及對最終結果的驗證和責任承擔上。換句話說，未來工程師依然要懂實現(xiàn)，也依然要懂設計，但更核心的競爭力會轉向“駕馭設計與實現(xiàn)過程”的能力。誰能把業(yè)務目標、系統(tǒng)約束、數(shù)據(jù)條件、風險邊界和工具能力說清楚，誰就更能借助AI放大產(chǎn)出。因此，未來工程師最重要的能力，第一不是單點編碼能力，第二也不只是傳統(tǒng)意義上的架構設計能力，而是更高一層的系統(tǒng)級判斷能力與人機協(xié)作編排能力。前者決定做什么、為什么這樣做，后者決定如何把模型、工具、流程和人工協(xié)同組織成一個可靠閉環(huán)。從這個意義上說，工程師不會被壓縮成“提示詞操作員”，也不會只剩下寫代碼或畫架構圖，而會逐步演變成面向復雜問題的解決者、約束定義者、結果校驗者和智能系統(tǒng)的指揮者。