LINE 語音筆記助手｜人工智慧專責辦公室

專案介紹

會議紀錄、課堂錄音或 Podcast 等長篇音訊資料，本質上是非結構化的，無法直接進行文本檢索。即便市面上有轉錄服務，通常也面臨嚴格的時長計費限制以及企業內部資料外流的隱私疑慮；此外，單純將語音轉為逐字稿，使用者仍需耗費大量時間閱讀，無法有效解決資訊超載的問題。

為此，我們開發了「LINE 語音筆記助手」。這是一個基於混和雲（Hybrid Cloud）架構的零成本語音處理系統。透過使用者最熟悉的 LINE 介面輸入音訊，系統將運算密集的「語音轉文字」推論落地於本機 GPU 執行以確保隱私與免除推論成本，並將後續的「資料結構化、重點摘要與心智圖生成」交由雲端 Serverless 工作流引擎非同步處理。

技術棧 (Technology Stack)

邊緣閘道 (Edge Gateway)： Python / Flask
本地推論 (Local Inference)： OpenAI Whisper
雲端編排 (Cloud Orchestration)： n8n — 部署於 HuggingFace Space，作為事件驅動的工作流引擎。
AI 引擎 (LLM)： 串接大語言模型執行自然語言處理、長文摘要與資料結構化轉換。
資料儲存 (Data Storage)： Google Drive — 透過 API 介接，作為非結構化檔案（TXT、HTML）的物件儲存空間。
通訊介面 (Messaging Gateway)： LINE Messaging API — 處理 Webhook 監聽與主動推播 (Push Message) 。

系統架構圖

階段一：接入與非同步解耦 (使用者端 ↔ 本機伺服器)

步驟 1：傳送語音訊息 使用者透過 LINE APP 發送語音檔案，系統透過 Webhook 將音訊資料傳遞至本機伺服器的「本地端伺服器」。
步驟 2：立即回覆"處理中"。本地端伺服器收到音檔後，必須在主執行緒立刻回覆 LINE 伺服器，以避開 LINE API 嚴格的 30 秒逾時（Timeout）強制斷線機制。此動作宣告同步通訊結束，後續任務轉為非同步處理。

階段二：本地硬體推論 (本機伺服器內部)

步驟 3：將錄音檔轉錄為文字 FLASK 將耗時的語音處理任務派發至「背景執行」的執行緒中。由掛載於本地 GPU 的「WHISPER 模型」接手，執行高密度的矩陣運算，將音訊特徵轉為文字。

階段三：雲端邏輯編排與持久化 (本機伺服器 ↔ 雲端自動化)

步驟 4：發送轉錄文字 本地端 WHISPER 轉錄完成後，由 FLASK 將資料發送至部署於 HuggingFace Space 的「n8n 工作流」接收端。
步驟 5：產生重點摘要和心智圖 資料進入雲端後，n8n 扮演工作流呼叫「LLM 大語言模型」執行自然語言處理，將長篇逐字稿提煉為結構化的摘要與心智圖。
步驟 6：存入檔案 為確保資料持久化，n8n 將處理完的文本或心智圖檔案，透過 API 寫入「Google Drive」進行物件儲存。
步驟 7：推送最後結果 工作流的最後一步，n8n 透過 LINE Push API，主動將精煉後的摘要與檔案連結還有原文，異步推播回使用者的 LINE APP，完成完整的端到端（End-to-End）資料處理閉環。

n8n流程圖

1. 觸發與預處理 (Ingestion & Pre-processing)

資料接收： 工作流由最左側的 Webhook 節點觸發，負責接收從本地端（Flask 閘道）跨網路傳遞過來的 JSON 封包，其中包含語音轉錄好的逐字稿及相關 Metadata。
初步清洗： 接收資料後，系統先呼叫 LLM 進行初步的資料清洗，執行「添加標點符號」與「語意分段」。這一步是為了將 Whisper 轉錄出來缺乏結構的純文字，轉換為後續模型更容易處理的標準化格式。

2. 平行處理管線 (Parallel Processing Pipelines)

預處理完成的文本會同時分發到三條獨立的邏輯管線中平行運算，這有效降低了整體流程的延遲（Latency）：

管線 A（特徵萃取）： 專注於摘要生成。再次呼叫 LLM 提取文本的核心觀點，生成結構化的重點摘要，並在資料末端附加處理時間戳記，確保資料的可追溯性。
管線 B（視覺化轉換）： 負責將文本轉換為圖形結構。首先透過 LLM 將文本邏輯轉譯為 Markmap 格式，接著將此語法傳遞給自訂的 JavaScript 節點，由程式碼直接將其渲染並封裝成「互動式 HTML 檔案」。
管線 C（原文保留）： 負責資料的持久化（Persistence）策略。透過一個條件判斷節點（If Node）進行字數評估：
- > 2000 字（長文）： 觸發，將字串轉為 .txt 檔案格式，並上傳寫入 Google Drive 進行物件儲存（Object Storage），避免過長的文字直接塞爆通訊軟體版面。
- < 2000 字（短文）： 判定為輕量級資料，不進行檔案寫入，直接將字串向後傳遞。

3. 非同步輸出 (Asynchronous Delivery)

結果匯聚與推播： 三條管線的處理結果（包含管線 A 的摘要文字、管線 B 的 Google Drive 心智圖連結、管線 C 的短文或長文 Drive 連結）會在最後階段進行打包。
LINE Push API： 最終透過呼叫 LINE 的 Push API，將這些處理結果以非同步的方式主動推播（Push）到使用者的手機端。

LINE 語音筆記助手