# Flowney 技術問答時間

## 問題模板

* **日期:**
* **提問人:**
* **題目:**
* **回答:**
1. 回答 (回答人)
2. 回答 (回答人)
---

* **日期:** 6/17
* **提問人:** 黃鉅燊
* **題目:** 這些分析和回應的工作使用傳統判別式 AI 就能夠達成，為甚麼還需要使用 LLM，使用的必要性在哪裡 ?
* **回答:**
1. 我們會需要根據使用者在後來的問答中給予回應，我們無法確定使用者問的問題為何，再加上判別式 AI 較難做到上下文的理解，這兩點我們用LLM就可以解決以上問題。**(郭兆逸)**
2. 判別式 AI 學習資料中的條件機率分布，再對場景進行判斷、分析和預測。生成式 AI 則學習資料中的聯合機率分布，使用深度學習技術等，創作模仿式，自動生成全新內容。**(楊瑞文)**

---

* **日期:** 6/18
* **提問人:** 郭兆逸
* **題目:** 後端有特別要用什麼框架會比較好嗎? 可以用flask嗎?(目前相對熟悉)有需要特別寫除錯嗎?
* **回答:**
1. 後端選用開發人員自己熟悉的框架是最好的，但考慮到 Flowney 會使用到 LLM 的技術，使用 **Python** 的框架作為後端是較好的選擇 **(程式碼可兼容)**，有幾種選擇 (Flask、Django、FastAPI) 是較常見的後端框架，我自己比較熟悉 FastAPI。至於除錯的部分傳統上最直觀的方式就是 **Print Debug**，利用在 Console 的錯誤訊息去除錯，較專業也是企業會有的作法是使用 **Log**，相較之下我們可以針對訊息去進行分級處理 **(Info、Warning、Error)**，在進行開發時可以比較快速了解問題出錯的地方。另外在正式開發的話我們會需要去測試 **API** 的連接、資料型態、內容是否符合程式要求，所以會需要去撰寫 **Test**，也就是後端的 Quality Assurance 的一部份，如果想要看範例可以參考 **Postman** 現在有的 AI 生成 API 測試功能。 **(黃鉅燊)**
2. 後端我目前只會node js和一點php，平常也是使用pstman測試api，若後端確定使用python flask那我要惡補一下嘍。**(楊瑞文)**

---
* **日期:** 6/19
* **提問人:** 楊瑞文
* **題目:** 想知道我們如何訓練模型來分析客戶資訊，使用的技術、軟體...
* **回答:**
1. 這邊按照順序來講，先講模型的選擇，我們會使用的做法是直接去串接 OpenAI 的 GPT 模型的 API，你不妨去想一想為甚麼要使用 OpenAI 這種第三方技術而不直接使用 **「開源」** 的本地端模型 ? 接下來是 **「訓鍊」模型**這件事，用訓練去講太廣義，我把它細分一點分為兩個部分，一個是 **Prompt Engineering**、另一個是 **RAG**，我們並沒有要去 **Fine-Tune** 模型 (這個有牽涉到我上面讓你們反思的問題)，我們會和負責財務、會計那邊的成員們配合去製作出**多個**適合用來幫我們完成**分析客戶資訊**的子任務的 **Prompt Template**，另外也會去找專業的文獻或是範例去做成 **LLM 的背景知識庫**，也就是 RAG。上述說的這些我們會使用 **Python** 配合其 **OpenAI** 以及 **LangChain** 套件去完成這些任務 (Bonus: 如果你想要知道一些可以幫你快速建立 LLM 相關應用或調適的話可以去看看 Ollama 或是 Coze 這種工具)。**(黃鉅燊)**
2. 我目前有聽過prompt engineering，主要是透過引導、優化的方式提升AI產生的結果，讓這個結果比較準確。**(郭兆逸)**

---

* **日期:** 6/20
* **提問人:** 黃鉅燊
* **題目:** 如果使用第三方語言模型 (OpenAI)，你們要如何確保使用者的資料安全問題 ?
* **回答:**
1. 我有幾個想法，第一個是要做到 **匿名化和去識別化**，匿名化可以避免資料直接暴露使用者的資料；去識別化這邊舉例好了，主管 Daniel 我們可以改成 User123，這屬於去識別化中的 **資料假名化** 。他的出生日期是2003-12-19，我們可能會取2003年，這則屬於去識別化的 **資料泛化** 。 第二個是 **數據保留和刪除策略**，如中國淘寶會保留歷史訂單7年，一旦訂單經歷7年後，訂單將會自動刪除。第三個是可以做到 **資料加密**，有許多方法，像是：**資料庫加密(TDE)**、**檔案層加密**和**硬碟加密**，其防護能力則是由高到低排列。**(郭兆逸)**
2. 資料可以做去識別化，加入salt後加密。資料庫也應有防護措施保護內部資訊。 **(楊瑞文)**

---

* **日期:** 6/21
* **提問人:** 郭兆逸
* **題目:** 在做發票醫生的Figma時，我們會需要輸入年齡、性別和月收入等資訊，接著會等待分析。如果分析的時間過長，我們應該怎麼**加快分析的時間**或是**如何用其他方式解決這個問題?**
* **回答:**
1. 首先我們先定義這個分析時間 **「過長」** 這件事，我把它認定為以使用者視角來說 **「體感時間較長」**，根據研究，一般使用者遇到網頁進行資料輸出超過大約 5 秒鐘就會失去繼續等待的想法。而造成分析時間過長的原因可以分為 **「硬體」、「軟體」、「網路」** 三種層面，基本上我們硬體方面會使用 Google App Engine，他可以根據使用流量自動進行資源擴充，所以硬體不會是我們的短板，而軟體方面我們會使用 Python LangChain 配合 OpenAI 套件，這部分可以去了解看看 LangChain 和直接使用 OpenAI 套件的效能差異，另外我們這種面向多對象的應用程式都會撰寫**異步執行**的模式去利用好效能，而程式本身撰寫時就考驗到各位對於**資料結構以及演算法**的理解，如何去優化程式效率是很重要的議題。至於網路的部分取決於使用者本身的連線，我們這部分會和硬體一起連動，基本上不會有效能影響。**(黃鉅燊)**
2. 硬體的部分可以增填或增強目前效能，軟體的部分則可以優化程式端。**(楊瑞文)**

---

* **日期:** 6/22
* **提問人:** 楊瑞文
* **題目:** 使用發票醫生的Figma時，是否要支援無線模式，如需要要如何達成?
* **回答:**
1. 我這邊把無線模式理解成**離線模式**，我們首先要先完成**本地存儲**，這邊可以使用 **SQLite** 作為本地端的資料庫，因為它支援跨平台的應用(註1)。接著，要做到**數據同步**的部分，主要有兩個重點：**同步策略**和**同步衝突解決**。同步策略我們可以使用**實時同步**，他的概念是今天一旦接收到網路，立即同步數據。而同步衝突解決以**最後寫入優先( LWW )** 為主。還有，**緩存**也很重要，我們會要做到**資源緩存**和**數據緩存**，資源緩存的概念是可以將圖片、文件等**靜態資源**緩存在本地端；而數據緩存主要是將**向網路發請求拿到的數據**緩存在本地端。
**註1**：當然不只本地端的資料庫，也有瀏覽器的本地儲存，像是： **LocalStorage**, **SessionStorage**, **indexedDB** 等，有興趣可以去查看看他們的區別。**(郭兆逸)**
2. 首先，我不太理解使用 Figma 時支援無線模式代表甚麼意思，如果你指的是我們 **「製作」** 發票醫生 Figma 時這件事的話，那麼我可以很明確的告訴你，**我們不會支援離線模式**，第一點：發票醫生是個網頁並且作為 MVP，他的功能並不多，他甚至只是一頁式的網站，所以我們本就不會有 **「未連上網路」** 還能使用網頁的情況發生，再者我們的模型串聯 OpenAI，載具串聯財政部的 API，這些都要確保在網路環境下方可使用。如果你指的是 Figma 是否支援離線編輯的話，那根據官方說法他們是**瀏覽器面向**，所以不會有離線模式。**(黃鉅燊)**

---

* **日期:** 6/23
* **提問人:** 黃鉅燊
* **題目:** 如果使用本地端的開源語言模型不是可以更好的管理使用者資安問題嗎? 為甚麼你們選擇使用第三方公司的模型 (OpenAI)?
* **回答:**
1. 從資安問題來考慮確實第三方公司模型不如本地端模型。然而，從**資源角度**來說，本地端模型需要自行計算**大量資料以及儲存空間**；而選擇第三方公司模型**減少了對於本地端的算力要求**。另外，第三方公司模型會負責**更新以及維護**模型，由於他們是由**公司**去做這件事，維護的成本相對就會比較**低**，同時也能讓使用者當前使用的是**最佳的模型**。**(郭兆逸)**
2. 第三方公司會負責更新、強化以及維護語言模型，這樣我們的維護成可大大降低。

---

* **日期:** 6/24
* **提問人:** 郭兆逸
* **題目:** 我想問我們在**發票醫生**幫使用者分析的結果有需要儲存在資料庫嗎? 還是說**單純讓 LLM 協助使用者分析完即可?** 如果有要儲存的話，會將資料應用在哪裡呢?
* **回答:**
1. 嚴格來說是這樣的，我們的商業模式中，我們會收集使用者的資料去進行「二次利用」，去分析使用者消費的 pattern 後去做一些行銷。但是分析完的資料會比較偏向個人化且學術領域，以商業的角度來說，暫時對這部分沒有特別的安排。**(黃鉅燊)**
2. 個人認為每次的分析結果需要儲存，讓消費者能夠回溯之之前步驟。儲存的資料可以用來分析準確率... **(楊瑞文)**

---

* **日期:** 6/27
* **提問人:** 楊瑞文
* **題目:** 從財政部api拿到雲端發票資料後，我們要儲存在資料庫後再分析，還是拿到資料分析完後不儲存?
* **回答:**
1. 這個問題和6/24的問題非常相近，而我自己會比較傾向將儲存在資料庫。原因如下，數據儲存下來後，我們如果之後有需要做其他研究就可以從資料庫撈，可以去做像是：時間預測分析、數據視覺化等。**(郭兆逸)**
2. 使用者的消費資料我們可以直接從財政部的 API 獲取，如果考慮到我們的商業模式後續會在其他地方使用到這些「連續」的資料的話，我們應該是將這個資料儲存到硬碟作為 Log 保存，如果存放在資料庫中會佔用太多效能及資源。**(黃鉅燊)**

* **日期:** 7/1
* **提問人:** 郭兆逸
* **題目:** 未來有需要上架 **Google Play** 和 **App Store**，那應該會使用**跨平台開發的工具**，我們會比較傾向 **Flutter** 還是 **React Native**？
* **回答:**

1. 我們會使用 Flutter 來去開發，詳細比較可以看 [React Native 與 Flutter 比較](https://www.pintech.com.tw/article_page/88/react-native-vs-flutter-choosing-cross-platform-framework-for-next-project)，總歸來說現在新型的 APP 有很多都是利用 Flutter 進行開發，它的性能還有開發效率相對更高、檔案也更小。