本文將介紹如何借助于Langflow的直觀GUI界面來創建一個RAG聊天機器人的完整過程，期間將LLM與向量數據庫集成以實現上下文驅動的響應。

簡介

檢索增強生成（Retrieval Augmented Generation，簡稱“RAG”）是一種自然語言過程，它涉及將傳統檢索技術與LLM（大型語言模型）相結合，通過將生成屬性與檢索提供的上下文相結合來生成更準確和相關的文本。最近，這種技術在聊天機器人開發中得到了廣泛的應用，使公司能夠通過使用其數據定制的尖端LLM模型來改善與客戶的自動化通信。

Langflow（https://github.com/langflow-ai/langflow）是Langchain的圖形用戶界面，Langchain是LLM的集中式開發環境。早在2022年10月，LangChain就發布了，到2023年6月，它已成為GitHub上使用最多的開源項目之一。可以說，如今LangChain席卷了整個人工智能社區，特別是為創建和定制多個LLM而開發的框架，這些LLM具有與最相關的文本生成和嵌入模型集成、鏈接LLM調用的可能性、管理提示的能力、配備向量數據庫以加速計算的選項，以及將結果順利交付給外部API和任務流等功能。

在這篇文章中，我們將使用著名的開源泰坦尼克號（Titanic）數據集（https://www.kaggle.com/datasets/vinicius150987/titanic3）展示如何使用Langflow開發一個完整的端到端RAG聊天機器人。

使用Langflow平臺開發RAG聊天機器人

首先，需要在Langflow平臺（https://astra.datastax.com/langflow/）進行注冊。為了開始一個新項目，可以根據用戶需求快速定制一些有用的預構建流程。本文中要創建一個RAG聊天機器人程序，最好的選擇是使用向量存儲（Vector Store）RAG模板。圖1顯示了這種方案的原始操作流程。

圖1：Langflow向量存儲RAG模板流

在上述模板中，為嵌入和文本生成預先選擇了OpenAI，這些是本文中使用的技術；但是，其他一些選項，如Ollama、NVIDIA和Amazon Bedrock等，也都是可用的，只需設置相關的API密鑰即可輕松將其集成。值得注意的是，在使用與LLM提供程序的集成之前，要檢查所選的集成是否在配置上處于活動狀態，如下圖2所示。此外，可以定義全局變量，如API鍵和模型名稱，以便于對流對象進行輸入。

圖2：OpenAI集成和概述的界面

向量存儲Rag模板上提供了兩種不同類型的流。其中，下面的一個顯示了Rag的檢索部分，其中通過上傳文檔、拆分、嵌入，然后將其保存到Astra DB（【譯者注】。Astra DB是一個基于Apache Cassandra的開源云原生數據庫服務，它提供了強大的向量存儲能力，非常適合用于構建RAG系統）上的向量數據庫中來提供上下文，該數據庫可以在流界面上輕松創建。

目前，默認情況下，Astra DB對象能夠自動檢索Astra DB應用程序令牌，因此甚至不需要收集它。最后，需要創建將嵌入值存儲在向量DB中的集合。為了正確存儲嵌入結果，集合維度需要與文檔中提供的嵌入模型中的維度相匹配。因此，如果你選擇的嵌入模型是OpenAI的text-embedding-3-small的話，那么創建的集合維度必須是1536。下圖3顯示了完整的檢索流程。

圖3：泰坦尼克號數據集的檢索流程

用于增強聊天機器人上下文的數據集是Titanic數據集（https://www.kaggle.com/datasets/yasserh/titanic-dataset?resource=download，CC0許可證）。在RAG流程結束時，聊天機器人應該能夠提供具體的細節并回答有關乘客的復雜問題。但首先，我們需要在通用文件加載器對象上更新文件，然后使用全局變量“separator；”對其進行拆分，因為原始格式是CSV。此外，塊重疊和塊大小需要設置為0，因為通過使用分隔符，每個塊都將描述為一個乘客對應數據。如果輸入文件是純文本格式，那么，有必要應用塊重疊和大小設置來正確創建嵌入。為了完成流程，向量存儲在demo_assistente數據庫的titanic_vector_db中。

圖4：完整的生成流程

接下來，讓我們轉到RAG的生成流程，如圖4所示，它是由聊天中的用戶輸入觸發的，然后搜索到數據庫中，為以后的提示提供上下文。因此，如果用戶在輸入中詢問與名稱“Owen”相關的內容的話，搜索將在向量數據庫的集合中運行，尋找與“Owen“相關的向量，然后檢索并通過解析器運行它們以便將其轉換為文本，最后獲得稍后提示所需的上下文。圖5顯示了相應的搜索結果。

圖5：在向量數據庫中進行搜索以獲取上下文的結果

回到一開始，使用檢索流中的相同模型將嵌入模型再次連接到向量數據庫以運行有效搜索也是很關鍵的一步；否則的話，由于檢索和生成流中使用的嵌入模型的不同，會導致檢索結果內容總是空的。此外，這一步證明了在RAG中使用向量DB的巨大性能優勢，在RAG中將上下文快速檢索并傳遞給提示，然后才能對用戶做出任何類型的響應。

在圖6所示的提示中，上下文來自已轉換為文本的解析器，問題來自原始用戶輸入。下圖顯示了如何構建提示，并將上下文與問題結合起來。

圖6：將傳遞給AI模型的提示信息

提示寫好后，是時候使用文本生成模型了。在此流程中，我們選擇使用GPT4模型，其溫度參數（temperature）設置為0.5，這是聊天機器人的標準推薦參數值。溫度參數將控制著LLM預測的隨機性。一個較低數值的溫度參數將產生更確定和直接的答案，從而產生更可預測的文本。相對來說，一個較高數值的溫度參數將產生更具創造性的輸出——盡管這個參數值太高時，模型很容易產生幻覺并產生不連貫的文本。最后，只需使用全局變量和OpenAI的API鍵設置API鍵，這一步就很容易了。接下來，是時候運行完整的流程并在Playground交互環境上檢查一下運行結果了。

圖7：Playground交互環境顯示RAG聊天機器人的運行結果

圖7中的對話清楚地表明，聊天機器人能夠正確地獲取上下文，并正確地回答了有關乘客的詳細問題。盡管發現泰坦尼克號上沒有羅斯或杰克可能會令人失望，但不幸的是，這是真的。現在，RAG聊天機器人已經創建結束；我們還可以繼續增強其功能以提高會話性能并覆蓋一些可能的“誤解”，但是本文主要展示Langflow框架如何輕松地適應和定制LLM。

小結

最后，我們來介紹一下流部署的問題。當前，存在多種可以供參考的部署方案。HuggingFace Spaces是一種部署RAG聊天機器人的簡單方法，它具有可擴展的硬件基礎設施和本地Langflow，不需要任何安裝。當然，Langflow也可以通過Kubernetes集群、Docker容器安裝和使用，也可以通過VM和Google Cloud Shell直接在GCP中安裝和使用。有關部署的更多信息，請參閱此框架有關文檔（https://docs.langflow.org/deployment-hugging-face-spaces）。

總之，新時代即將到來，低代碼解決方案開始為人工智能在不久的將來在現實世界中的發展定下基調。本文介紹了Langflow如何通過直觀的UI和模板集中多種集成來徹底改變人工智能。如今，任何具備人工智能基礎知識的人都可以構建一個復雜的應用程序——這種程序的開發在本世紀初的話需要大量的編碼和深度學習框架專業知識。

譯者介紹

朱先忠，51CTO社區編輯，51CTO專家博客、講師，濰坊一所高校計算機教師，自由編程界老兵一枚。

原文標題：??Creating a RAG Chatbot with Langflow and Astra DB??，作者：Bruno Caraffa