07
企業 BI 與大數據應用策略銀河軟體 CLASS07 · Force Cheng
SPEC FIRST · POC FIRST · DATA TO DECISION

企業 BI 與大數據應用策略

提升營運決策品質

從一張名片開始，看懂 AI 如何介入專案。透過可拆開、比較、替換的教學案例，串起資料取得、資料庫、大數據分析、BI 儀表板與 AI 輔助決策。

名片人物情境物件與品牌對話CRM

從 SPEC 到可驗證 POC

點選步驟，查看教學焦點。

01定義情境誰在什麼時候遇到什麼問題？
02寫出 SPEC輸入、輸出、限制與成功條件。
03切出 POC只驗證最不確定的關鍵。
04比較路線AI、非 AI、雲端與地端。
05人工驗證看證據、信心與錯誤案例。

一個案例，多個 AI 觀念

每個區塊都可以獨立授課或現場抽換。

01

多模態輸入

照片、文字、聲音與既有資料如何進入同一流程。

02

傳統 AI

OCR、物件偵測、語音辨識與分類不等於 LLM。

03

大小模型

固定任務交給小模型，理解與生成再考慮大模型。

04

雲端與地端

比較能力、延遲、隱私、硬體與維運成本。

05

資料庫選擇

SQL 保存事實，全文與向量處理不同搜尋需求。

06

Token 模式

分清按 Token、按次計費與本機運算成本。

07

AI Coding

AI 協助寫 SPEC、程式、測試與介面，但仍需驗證。

08

治理內建

從資料取得、權限、保存到人工確認都屬於設計。

09

排程情報

定期取得客戶公開資訊，經整理、驗證後更新企業知識。

10

BI 與決策

將客戶、互動與商機資料轉為指標、分群、趨勢及行動提示。

OCR 到 KM：基礎 POC

先用最低成本完成可驗證主線，再依需求替換資料層、模型與部署方式。

FALO 基礎 AI 應用模板

標準 HTML＋GAS＋Google Sheets＋Gemini API

HTML 維持單一版本，可用於 Cloudflare Pages、GitHub Pages 與離線包；GAS 保存金鑰、處理流程並連接 Google Sheets、Drive 與 Gemini API。

圖片上傳Gemini 辨識欄位確認人物匹配Sheets KM摘要與運用

一張實體名片，最多三個檔案

一次建檔只處理一張實體名片；不同角色的另一張名片必須分開建立。

名片第 1 面

主要圖片，建立人物時可作為第一張來源名片。

名片第 2 面（選填）

只有同一張實體名片採雙面印刷時上傳，不接受另一張獨立名片。

人物相片（選填）

保存於人物 KM，第一版先做上傳與預覽，後續再擴充封閉資料庫匹配。

一筆建檔＝一張實體名片＝一個名片 Key
若同一人物另有其他公司、品牌或角色名片，請完成本筆後另外新增，讓每張實體名片各自保有來源、時間與 Key。

Key 與資料原則

Key 保存系統歷史；來源日期與現實資訊則可以修正。

項目格式／範例規則
名片 KeyC-20260803-001建檔日期＋當日流水號；寫入前檢查，重複時只替新資料遞增，不修改舊 Key。
人物 Key鄭福強#C-20260803-001建立時主要姓名＋第一張名片 Key；同名仍可唯一，建立後保持不變。
姓名資料原名、現名、英文名、別名OCR 修正與本人改名分開處理；現名可更新，原名與歷史保留。
來源時間source_date可依實際情況修正，不影響名片 Key 與建檔時間。
人物素材資料夾drive_folder_id人物層級欄位；第一版由使用者手動貼上 Google Drive 資料夾網址或 ID，不自動建立、搬移檔案或調整權限。

Google Drive 人物素材入口

將名片以外的照片、簡報、文件及其他素材連回同一人物。

手動提供

建立或確認人物時，貼上 Drive 資料夾完整網址或資料夾 ID。

人物共用

同一人物的多張名片沿用同一個資料夾，不因新增名片重複建立。

第一版邊界

系統只保存、驗證格式及提供開啟連結；檔案整理與權限仍由使用者處理。

來源明細：保存事實

  • 每張實體名片具有獨立來源與原始 OCR
  • 名片圖片、建檔時間、取得來源可追溯
  • 不因人物換工作而覆蓋歷史名片
  • 所有 AI 結論保留引用的名片 Key

人物 Context：保存歸納

  • 整合多張名片、中文英文名及多重角色
  • 提供 Gemini 可直接理解的時間排序內容
  • AI 提出人物候選、理由與信心
  • 經人工確認後更新，必要時可以重新產生

辨識與人工確認

AI 負責提出答案，使用者保有資料主導權。

01上傳預覽名片第 1 面、第 2 面與人物相片。
02欄位對應姓名、公司、角色、聯絡方式與未分類文字。
03人物候選姓名、Email、電話、公司與歷史角色交叉比對。
04手動調整修改欄位、改選人物、新增人物或標記待確認。
05寫入 KM保存名片明細並重新歸納人物 Context。

教學案例模組

選擇左側模組，查看輸入、輸出與可比較的技術。

技術路線比較

同一需求並沒有唯一答案；先從限制與驗證目標出發。

方式適合處理優點注意事項成本型態

不一定要用向量

  • 電話、Email、統編等精確比對
  • 日期、狀態、權限與商機金額
  • 固定欄位統計與報表
  • 明確規則可以處理的去重

向量開始有價值

  • 搜尋意思相近的會談與需求
  • 從授權圖庫找相似影像候選
  • 尋找過往相似商機或案例
  • 提供 RAG 所需的相關背景

POC 組裝台

勾選想在課堂展示的內容，即時生成一份教學 POC 摘要。

治理也是教材的一部分

範例可以大膽，但輸出必須說明證據、不確定性與使用邊界。

DATA

資料來源

照片、錄音、名片及 CRM 是否取得適當告知、同意或其他合法基礎。

SCOPE

目的限制

教學展示、授權測試與正式使用應分開，避免資料被拿去做未告知的用途。

HITL

人工確認

人物、品牌與商機推測只提供候選及證據，不直接替使用者做最終認定。

LIFE

資料生命週期

規劃保存期限、權限、刪除、操作紀錄與模型更換後的重新處理方式。

可以作為教學範例

  • 辨識可見物件與可能品牌
  • 整理對方明確表達的需求
  • 提出有證據的溝通切入點
  • 顯示候選、信心與不確定因素

不要包裝成確定事實

  • 從單張照片斷定人格或財力
  • 推測政治、宗教、疾病等敏感資訊
  • 把向量最相近直接當成同一人
  • 以情緒或語氣判定對方是否說謊