從零打造屬於自己的 RAG-based LLM Line Bot 系列（四）：Line Bot 開發
在這個系列文章中（預計會有五篇），我會分享如何從頭開始開發一個 RAG-based 的 Line Bot，包含
目錄
前言
在上一篇資料準備與處理中，分享了如何使用自己想要的資料來當作聊天機器人的知識來源。
此篇便是介紹如何去建立一個介面去和這些資料溝通。會包含 streamlit 和 Line。前者在搭建上更容易，不只可以很快作為一個 POC，也可以利用他們官方的流程快速發佈，便透過網址來使用；而後者則是在介面上對台灣用戶更友善，不需要去記得這個網址，只需要像加入好友的方式便能使用服務。
Streamilt
程式碼是來自官方範例（chat_with_documents.py）。主要可以介紹三個角色，分別是 LLM、Retriever 和 Memory。
LLM
在第二篇的向量搜尋與答案生成中，有提到在搜尋出文章段落後，會利用 LLM 來總結這些段落並生成最後答案，通常就會使用 ChatGPT 來扮演這個角色。好處是是利用總結文章段落來限制 ChatGPT 的回應廣度，再來是只單純利用 ChatGPT 來總結也讓花費可以很低。
Retriever
在前一篇的文字向量化與儲存時提到，我們會對文字資料使用 Embedding Model 將文字向量化，並儲存這些向量化後的節果來做後續的的搜尋。
而 Retriever 負責的便是是如何針對用戶的提問去取出文章段落。在定義 Retriever 時會需要兩個角色，一個是 Embedding Model，另一個是 Vector DB。
Embedding Model 要做的是將用戶的 Query 向量化，由於是要做 Query 和 Document 的相似度搜尋，因此要在同一個向量空間上計算，所以 Embedding Model 的選擇就必須要和當時處理資料時的模型相同，這樣的相似度才有意義。而 Vector DB 就只需要給定前一步所儲存的 Chorma DB 的路徑，便可以初始化 Retriever。
程式碼請參考 configure_retriever。
Memory
在 Langchain 中 ConversationalBufferMemory 所扮演的角色是幫助聊天機器人記住對話歷史，這樣在接續問題時，即使省略某些主詞，但依舊可以理解上下文來回應更正確的答案，進而提升了整體的對話體驗。
在建立後上述的三個角色後，透過 python -m streamlit app_streamlit.py 便可以在本地端啟動這個應用程式。
再按照官方文件Deploy your app的步驟便可以發佈到線上使用。
Line
大部分的程式碼都是基於第二篇最後所附上的幾個參考來源來開發，由於一樣使用 Langchain 的 ConversationalRetreivalChain 來處理對話和搜尋的流程，所以同樣使用上述提到的幾個重要元件，分別是 LLM、Retriever 和 Memory。
以下是兩處略有不同部分
1. PGVector 來當作搜尋向量的資料庫
不同於載入一個本地端檔案來實現向量搜尋，使用 PGVector 可以讓 App 的啟動時間更短，並且也使用更少的資源，讓大家各自處理擅長的事情。使用的方式也非常簡單，只需要準備好連線字串即可。
2. 利用 source_documents 回傳 YouTube 連結
source_documents 是利用搜尋字串對預先處理好的文章片段所查詢後的結果，增加信賴感。
在 Streamlit 範例中， PrintRetreivalHandler 中的 on_retriever_end 將 source_documents 以文字對形式回傳給用戶。
在 Line Bot 中，我們使用 PGVector 取代了 Chroma Index，並且我們在建立資料時有一並把影片 ID 存進資料庫（不確定 Chroma Index 可否做到，沒有多深入研究），因此在回傳的 source_documents 中是有影片 ID 的資訊，我們便可以透過這些影片 ID 組成影片連結。
3. 其他
剩下的差異是一些後續開發的小功能，和 Streamlit 與 Line 無關，分別是簡轉繁（str_converter）以及語言偵測（AWS Comprehend）與翻譯（AWS Translate）。
小結
此篇為這個系列的第四篇，介紹兩個開發關於聊天機器人使用者介面的選項以及相對應的程式碼，一個是 Streamlit，另一個是 Line Bot。
下一篇（最後一篇）會介紹如何透過 Heroku 將所製作的 Line Bot 發佈到線上和一些簡單的 Demo，並附上 Github 連結讓大家參考。
對這個系列有興趣的讀者請持續保持關注，我們下次見！
