HackMD
Applying Generative AI to FinTech: From Prototype to Production in 3 Months - 許竣翔
從這開始
PPT: https://docs.google.com/presentation/d/1XC0NcycpdWGYBVRxlSvdJ_E2DCubHXSqr9dmJvc63yE/edit?usp=sharing
重點摘要
AI 應用的是與不是
- LLM 只是一種方法，要先分析過問題的本質再套用
- 應用：
- 資料與商業需求（限制）
- 模型
- 部署
- 監控
要瞭解資料先了解產業
- 如何使用 LLM 加速整合交易融資申請的審核文件過程。
- 問題
- 海運業數位化能力很低，很多還在用傳真。
- 解法
- LLM的第一個'L'讓他展現出對資料的理解能力能根據上下文判斷合理選項
- in-context-texting不用labal就能理解文件，對labal稀缺任務值得一試
- 實際使用情境
- 直接把申請文件丟給 LLM 詢問這間公司能不能借錢給他。
- 什麼叫「能不能」？
- 人是先想後說，LLM 是先說後想，所以有可能先說了才補足自己的陳述。
- 比方yes/no問題，若回答了yes則後頭會持續圓前面的結果，即使答案是no。
- SOP
- 理解文件、欄位 → 將訂單號碼、金額輸入到外部網站查證交易（物流、海關網站）
- 直接把申請文件丟給 LLM 詢問這間公司能不能借錢給他。
目前架構是否符合需求
Image Not Showing
Possible Reasons
- The image was uploaded to a note which you don't have access to
- The note which the image was originally uploaded to has been deleted
Image Not Showing
Possible Reasons
- The image was uploaded to a note which you don't have access to
- The note which the image was originally uploaded to has been deleted
- 商業需求
- 時間：不能超過人力審核時間。
- 成本：依照公司價值評估成本。
- 準度：KPI 為節省審核人員的時間。
- AI 的不確定性是否為問題？（非 0/1）
- 要想的是錯了要怎麼處理
- 目標為人機合作
如何實作人機合作的架構
- 拆分為多輪流程（divide & conquer)）
- 判斷是何種文件 → 載入對應文件的 Prompt
- 與 domain expert 合作
- 把問題拆小、一次只做一件事
- 資料搜集（從prompt, evals開始）
- 成本：Prompt < RAG（給參考書）< Fine-tune（思想改造）
- ChatGPT PROS
- RLHF、MLOps 做得好
- PhD 來跟它說哪個回覆好
- evals & monitoring 為關鍵
- metric: F1-Score
- test data: not for training, just for eval
- 測試(實習生測試)
- 想像LLM是實習生，給予他先備知識後執行。
- 若結果不穩定可能是任務過於複雜，此時就再拆分任務。
- 改善（加速從錯誤中學習）
- 投資視覺化工具（e.g. Streamlit）
- 投資 Ops 工具（e.g. MLflow, Langfuse）
- 更快得到實驗結果
- Parallielize LLM calls to reduce I/o bound in the LLM
Production 監控
- 與外部網站的比對錯誤率
- Request I/O tracing and metrics (cost & latency)
- 爬蟲error
- health check
Image Not Showing
Possible Reasons
- The image was uploaded to a note which you don't have access to
- The note which the image was originally uploaded to has been deleted
結論
- 商業與資料理解
- 實物場景的資料與限制 (時間,成本,準度要求)
- 想好ＡI錯了會怎樣
- 建立模型與評估
- 把任務切小切具體，減少隱含不確定性
- 盡早投資視覺化工具、Ops 工具 & 平行化程式，加速錯誤中學習
- 要最佳化的是 Strategy，而不是 Goal（KPI）
- 部署與監測
- 想好能用來 fact-checking 的資料是什麼、是即時產生還是會延遲很久（持續監測 data drift）
問答
-
聽眾有相關經驗，主要為銀行業的文件，常常為掃描後的檔案，並且內容為非結構化的文字，在 OCR 的過程並非很容易，想問有無做特別的處理，讓接收文字時更清楚？
- OCR 專注在抽取文字，如果圖片本身不是很清楚且文字精度要求高，可以用更強的 OCR 服務，如 AWS Textract，來配合 LLM 的理解能力去轉出品質高的結構化資料
-
迭代模型版本時考量的點
- AI 應用永遠不會有正確率 100% 的時候，有的話也是 overfitting，所以迭代上線前，會以業務量最高的資料集先跑測試，確保修好一些 edge case 的同時主線任務也維持得好好的
-
物流、海關等網站上的資訊已經是正確答案了，為何還需要跟 LLM 的結果比對
- 分成幾個面向
- 以審核申請文件層面來說，首先要確保客戶提供的文件是對的上的，這會影響到如果後續壞帳時的保險理賠流程
- 以使用科技 scale up 現有流程來說，我們需要建起 pipeline，並用外部資料當成監控 LLM 輸出品質的依據
- 以資料分析來說，物流、海關上的資料比較片面，而且申報時也有可能低報金額等等的資訊來減少進口稅，所以直接從文件去拉出資訊是最完整最準的
- 分成幾個面向
