雜談：怎麽讓AI能根據我的雲端硬碟回答問題 / TALK: How Can I Enable AI to Answer Questions Based on My Cloud Storage?
Nextcloud的AI應用程式不能處理中文，所以我自己用Langflow整合到Nextcloud，讓大型語言模型能夠根據我在雲端硬碟裡面的內容來回答問題。這篇就講一下大致上的做法。
Nextcloud的llm2應用程式 /
(圖片來自：https://www.youtube.com/watch?v=6_BPOZzvzZQ&t=138s )
https://docs.nextcloud.com/server/latest/admin_manual/ai/app_assistant.html#installation
Nextcloud在好幾年前就嘗試將LLM (大型語言模型)接入到Nextcloud。有了LLM的輔助，我們可以在Nextcloud裡面作翻譯、寫作等功能。Nextcloud的AI應用可以用OpenAI GPT-3.5的API，也可以在本地架設Llama 3.1模型。它能做到機器翻譯、語音轉文字(透過stt_whisper2)、產生文字、摘要、產生標題、抽取主題詞、根據上下文重新撰寫(context write)、重寫、文字轉圖片(使用tex2image_stablediffusion2 )、上下文對談(context chat，此處的context是指Nextcloud裡面的檔案)、上下文助理 (context agent)，功能非常豐富。
不過要架設具有AI功能的Nextcloud Assistant並不容易。乍看之下，好像是要用nextcloud aio版本，搭配appapi之類的東西才能運作。需要的元件很多，稍微複雜了一些，真是令人困擾。
https://github.com/nextcloud/context_chat_backend
研究的過程中，我發現Nextcloud很多AI元件其實背後也是使用langchain。既然如此，那我何不自己用langchain來處理就好了呢？
Langchain的低程式碼版本：Langflow / Low-Code LangChain: Langflow
最近因為工作的需求，我開始研究Langchain的相關應用。基於Dify的開發經驗，我也想找一個low code版本的開發方式，也許這可以讓未來接手的人更容易理解LLM的運作過程。在Langchain眾多的變型框架中，我選擇的其中一個框架就是Langflow。
Langflow是一個針對LangChain設計的使用者介面(GUI)，採用react-flow設計，提供了一種透過拖拉元件和聊天框來輕鬆實驗和原型化流程的方式。Langflow簡化了使用大型語言模型(LLM) 建構應用程式的流程，讓使用者可以更直覺地設計和測試LangChain流程。它讓使用者無需編寫程式碼，即可視覺化地建構複雜的AI應用程式，並透過互動式的介面快速迭代和改進。Langflow支援各種LangChain元件，方便使用者探索不同的LLM、提示工程策略、鏈(Chains)、代理(Agents)等，並快速建構原型，驗證想法。
Langflow作為LangChain的圖形化使用者介面，大大降低了使用LangChain的門檻。使用者可以透過拖拉預先建置好的元件，例如提示模板、LLM模型、資料庫連接等，到畫布上，並將它們連接起來，形成一個完整的工作流程。這種視覺化的建構方式，讓使用者更容易理解和掌控整個流程的邏輯，也更方便除錯和修改。此外，Langflow還提供了一個互動式的聊天框，讓使用者可以即時測試建構好的流程，並觀察其輸出結果，進而快速調整並改進應用程式。
用Langflow作RAG / Building a RAG Application with Langflow
用Langflow作RAG非常簡單。我參考Langflow的範本，並進行一些基本的修改。
我把輸入資料進行索引的流程獨立成一個flow。
然後執行RAG並結合LLM能夠詢問問題的流程再另外建立成另一個flow。
跟原本預設範本不一樣的地方是：
- 我改用了Chroma DB。因為Langflow的Docker映像檔內建了Chroma DB，可以不用外接其他服務。
- Embedding使用Google Generative AI的modes/text-embedding-004。其實應該要用text-multilingual-embedding-002，這樣才能處理多國語言。但Langflow沒有提供這方面的功能。儘管如此，它還是能夠看得懂中文。
- LLM使用Google Generative AI的gemini-1.5-pro。
- Google的API KEY保存在外部的.env，在docker-compose.yml讀取時載入，然後在Node的程式碼用Python載入環境變數。因此就不會直接在Langflow寫入API KEY。
一開始我本來想要接本地的Ollama，但是失敗了。後來統一接Google，建立Chroma DB等後續步驟就變得很簡單。在Playground這裡很快就能使用RAG來詢問問題。
雲端硬碟整合RAG的系統架構 / Cloud Storage Integration with RAG System Architecture
掌握了如何客製化Nextcloud跟用Langflow作RAG這兩個關鍵技術後，接下來的操作就比較簡單了。上圖是一個比較容易理解的架構圖，整個流程如下：
- Nextcloud作為檔案管理的前端介面，使用者可以在裡面修改檔案，或是用Nextcloud的Client作讓雲端硬碟的檔案跟本機資料夾同步。
- 資料夾被另一個程序Data Monitor監控。如果資料夾裡面的檔案有變動，則會嘗試將它轉換成Markdown，當作是RAG的索引。這邊我用的是微軟推出的Markitdown，但它處理表格的形式不太合格。如果檔案有被刪除，則會移除對應的Markdown以及清理空的資料夾。
- 如果Markdown有所增減，接下來會呼叫Langflow的API，請它根據更新後的Markdown來進行索引。這邊的索引我先用最基本的RAG，也就是單純的切片chunking、轉換成embedding、保存到向量資料庫。
- 最後，我們就可以在Nextcloud裡面呼叫Langflow widget，使用彈出式的視窗來跟AI對談。AI對談的內容全部都是基於Nextcloud裡面的資料，這樣就完成了基本的雲端硬碟RAG應用。
成果展示 / Results Demonstration
最後成果的畫面如上圖。Nextcloud右下角多出了Langflow Widget的按鈕，按下去就會跳出可以跟AI對談的對話視窗。
我們可以直接修改Nextcloud裡面的檔案。
AI會讀取新的內容，然後搭配原本的上下文脈絡，給出綜合性的回答。這樣就完成囉。
結語 / Conclusion
這次的嘗試讓我們看到了Nextcloud跟Langflow結合的可能性。實際上，要達到此結果，有很多細節需要克服。現在的做法也會在處理大量檔案的時候遭遇問題。另一方面，雖然乍看之下不需要用到Nextcloud那種複雜的架構也能做到雲端硬碟RAG應用，但Nextcloud還有許多改寫、生成的功能，也不是單純插入Langflow Widget就能做到的事情。如果要更進一步的運用Nextcloud的話，老老實實地去佈署Nextcloud的AI元件，應該還是比較合理的做法吧。
另一方面，其實我對Langflow的表現也不太滿意。作為一個low code應用框架，Langflow是可以讓我改寫節點的Python，以此添增或客製化許多功能。但現在RAG大多要做到能夠標註資料來源，這樣使用者才能循線找到原始資料進行驗證。這件事情要在Langflow上做到，看起來並沒有這麼簡單。
總之，這個試驗性的小專案就這樣做完了。作為活絡筋骨的暖身運動，感覺還不錯。
