如果用戶的OpenAI 未進行訂閱，這里則需要修改model為：”OPENAI_API_MODEL”: “gpt-3.5-turbo”

3.下載本地模型。如果您遇到wget命令的問題，您可以手動從此鏈接（https://huggingface.co/TheBloke/Mistral-7B-Instruct-v0.2-GGUF/resolve/main/mistral-7b-instruct-v0.2.Q6_K.gguf）下載模型并保存在’models’目錄中。

bash download-models.sh

4.啟動演示：

注：需要啟動 Docker Desktop`

bash run.sh

5.訪問 http://localhost:8501/ 上的用戶界面

在阿里云/AWS服務器運行

我們在阿里云和AWS上都測試過這個流程，在公有云上的過程中，1-4步和上面設置一樣，請確認服務器上已安裝Docker引擎。

如果服務器上配置有GPU，在第四步的命令中我們可以指定使用GPU來運行LLM：

bash run.sh -gpu

和本地運行不一樣的是，在云上運行的時候我們需要設置防火墻規(guī)則之后才能訪問界面。

5.配置防火墻規(guī)則

例如，對于阿里云，可參考https://help.aliyun.com/zh/simple-application-server/user-guide/manage-the-firewall-of-a-server

6.訪問 http://{云CPU實例的IP地址}:8501 上的用戶界面

可以在云服務商工作臺處查看服務器的IP地址，或者在連接服務器后使用如下命令查看IP地址：

curl ip.sb

隨后在瀏覽器中訪問 http://{云CPU實例的IP地址}:8501 訪問web ui.

瀏覽器訪問Web UI?

現(xiàn)在讓我們通過上傳一些示例數(shù)據(jù)來使用Web UI：

1.訪問提供的鏈接(https://github.com/ppasupat/WikiTableQuestions/releases/download/v1.0.2/WikiTableQuestions-1.0.2-compact.zip)下載一組示例CSV文件。解壓下載的文件。在演示中，我們將使用位于“WikiTableQuestions/csv/200-csv/11.csv”的文件。

2. 進入UI后，首先上傳一個CSV文件，比如剛剛解壓的文件。選擇“LLM類型”來處理您的查詢。您可以在“ChatGPT”和“Local_LLM”之間進行選擇。

3.選擇引擎來查詢您的表格數(shù)據(jù)文件。有兩個選項：“MixSelfConsistency[1]”和“ChainOfTable[2]”。

4. 選擇完這些選項后，您現(xiàn)在可以根據(jù)CSV文件中的數(shù)據(jù)提問了。例如，“誰贏得了1972年的最佳男演員獎？”點擊“查詢”按鈕提交您的問題，并從選擇的LLM獲得答案。

5. 在UI的側(cè)邊欄上，有一個查看LLM推理跟蹤的選項。這個功能可以讓您看到LLM逐步處理您的問題的過程，從而提供了如何得出答案的見解。

05 代碼結(jié)構(gòu)說明

該演示的代碼[3]主要包括以下幾個文件：

06 查詢引擎的運作機制

在演示中，我們使用了一個名為“11.csv”的CSV文件，該文件來自“WikiTableQuestions/csv/200-csv”示例數(shù)據(jù)集。該CSV文件包含在下表中顯示的結(jié)構(gòu)化表格數(shù)據(jù)。讓我們來探索一下查詢引擎對于問題“哪位提名者在1972年獲得了奧斯卡最佳男演員獎？”是如何回答的。

“MixSelfConsistency” 查詢引擎

“MixSelfConsistency” 引擎通過循環(huán)遍歷兩種不同的可配置迭代次數(shù)的查詢路徑來運行。這兩個路徑分別被稱為“文本推理”和“符號推理”。

“文本推理”路徑

這個路徑很直接。它將 CSV 文件的內(nèi)容直接整合到提示詞中，從而形成一個綜合查詢，然后輸入給LLM。我們執(zhí)行了三次這個流程，得到了結(jié)果列表：

['Gene Hackman', 'Gene Hackman', 'Gene Hackman'].

“符號推理”路徑

這條路徑使用LlamaIndex的PandasQueryEngine。該查詢引擎將CSV文件加載到pandas數(shù)據(jù)幀中，然后根據(jù)給定的問題生成pandas指令以獲取結(jié)果。在演示中,我們得到了三條 pandas 指令，每條指令對應一次迭代運行。

第一次運行：

df[(df['Award'] == 'Academy Awards, 1972') & (df['Category'] == 'Best Actor') & (df['Result'] == 'Won')]['Nominee']

第二次運行

df[(df['Award'] == 'Academy Awards, 1972') & (df['Category'] == 'Best Actor') & (df['Result'] == 'Won')]['Nominee'].iloc[0]

第三次運行

df[(df['Award'] == 'Academy Awards, 1972') & (df['Category'] == 'Best Actor') & (df['Result'] == 'Won')]['Nominee']

因此，結(jié)果列表為：

[    '2    Gene Hackman\nName: Nominee, dtype: object',    
     'Gene Hackman',
    '2    Gene Hackman\nName: Nominee, dtype: object'
]

自洽性聚合

最后一步是將從”文本推理”和”符號推理”生成的合并表中統(tǒng)計每個推理結(jié)果出現(xiàn)的次數(shù)，然后返回出現(xiàn)次數(shù)最多的那個推理結(jié)果，即為答案。在我們的演示中，出現(xiàn)計數(shù)最高并因此被判定為最有可能的答案的推理結(jié)果是”Gene Hackman”。

優(yōu)點和缺點

“MixSelfConsistency”查詢引擎通過融合文本推理和符號推理，并利用混合自洽性機制，提高了準確性。但是，對這些查詢路徑進行多次迭代運算可能會導致整體響應時間變長。

“ChainOfTable” 查詢引擎?

“ChainOfTable”引擎最初采用一系列操作將原始表格修改成可以直接處理查詢的格式。隨后，它將經(jīng)過修改的表格和問題結(jié)合起來創(chuàng)建一個提示詞，以便 LLMs 能夠推導出最終答案。這個最后階段類似于“MixSelfConsistency”引擎中的”文本推理”路徑。

表格操作鏈 

讓我們深入了解一下它構(gòu)建操作鏈的方法。在每次迭代中，引擎都會提示 LLM 下一步的操作，同時考慮當前的表格狀態(tài)和之前的操作歷史?？赡艿牟僮靼ǎ?nbsp;

1. f_add_column()：當表格需要額外的推斷數(shù)據(jù)來準確響應查詢時，使用這個操作添加新列。

2. f_select_row()：當只有特定行與問題相關時，使用這個操作來隔離并專注于特定行。

3. f_select_column()：與f_select_row()類似，使用這個操作將關注點縮小到回答查詢所需的特定列上。

4. f_group_by()：對于涉及具有相同值及其計數(shù)項的查詢，使用這個操作可根據(jù)這些項進行分組，從而提高數(shù)據(jù)表述的清晰度。

5. f_sort_by()：如果查詢涉及某列中數(shù)據(jù)的順序或排名，使用這個操作會根據(jù)問題的上下文對該項進行排序。

演示案例

回到我們的演示，讓我們重新審視一下查詢：“哪位提名者在1972年獲得了奧斯卡最佳男主角獎？”。作為回應，”ChainOfTable”引擎在第一次迭代時執(zhí)行了操作f_select_row([‘row 3’])。此操作導致創(chuàng)建了一個新的表，結(jié)構(gòu)如下：

最終的查詢變得直接了當，直接得出了最終答案：“Gene Hackman?！?/p>

優(yōu)點和缺點

“ChainOfTable”引擎創(chuàng)建了一系列操作，將原始表格轉(zhuǎn)化為與最終問題更加吻合的版本。這種方法顯著提高了對那些無法從原始表格中立即得出答案的查詢的準確性，需要一系列表格操作來澄清問題。然而，這個過程要求每次與 LLM的交互都要在提示中包含當前表格的內(nèi)容。這種方法可能會影響 LLMs 的性能，特別是在處理大型表格時，因為數(shù)據(jù)的大小直接影響處理負載。

性能比較

在我們的查詢引擎演示中，每次執(zhí)行查詢都會提供兩個關鍵信息：查詢引擎的響應和生成該響應所需的時間。通過使用演示中的 CSV 文件進行實驗，我們發(fā)現(xiàn)當使用 ChatGPT 推理時，”MixSelfConsistency “引擎往往比 “ChainOfTable “引擎更快、更準確。

需要注意的是，這些結(jié)果并不是通過系統(tǒng)的基準測試或?qū)煞N查詢引擎的全面比較得出的。我們提到的結(jié)果完全基于我們有限的實驗。因此，這些結(jié)果應被視為初步觀察結(jié)果，而非最終結(jié)論。

我們鼓勵對這一領域感興趣的個人以我們的演示為起點，進行更廣泛的比較或基準測試。

07 使用體會

與LLMs的交互

在本次演示的實現(xiàn)過程中，一個關鍵部分是與用于查詢的 LLMs 的 API 建立連接。這包括設置與 ChatGPT 的 OpenAI API 的建立連接以及與本地 LLMs 的類似 API 建立連接。以下是代碼的第一部分：

self.openai_llm = OpenAI(model=OPENAI_API_MODEL)
self.local_llm = OpenAILike(
   api_base=API_BASE,
   api_key=API_KEY,
   model=MODEL_NAME,
   is_chat_model=True,
   is_function_calling_model=True,
   context_window=3900,
   timeout=MAC_M1_LUNADEMO_CONSERVATIVE_TIMEOUT,
)

此外，設置 ServiceContext 對于 LLMs 也非常重要，特別是對于本地 LLMs 。本地 LLMs 使用的是 Huggingface 的本地 embed_model（來自此文檔https://docs.llamaindex.ai/en/stable/module_guides/models/embeddings.html，本地 embed_model 指的是 “BAAI/bge-large-en” ）：

if llm_type == GPT_LLM:
   chosen_llm = self.openai_llm
   embed_model = OpenAIEmbedding(embed_batch_size=10)
   service_context = ServiceContext.from_defaults(
       chunk_size=1024, llm=chosen_llm, embed_model=embed_model)
else:
   chosen_llm = self.local_llm
   service_context = ServiceContext.from_defaults(
       chunk_size=1024, llm=chosen_llm, embed_model="local")
   set_global_service_context(service_context)

上述實現(xiàn)在功能上是可行的，但在靈活性和切換不同 LLM（如 OpenAI 和本地 LLM ）的易用性方面并不理想。在理想的設置中，類似 OpenAI 或 OpenAILike 的類應能夠與 OpenAI 模型和本地 LLMs 建立連接。這可以通過簡單地指定這些兼容 API 的 api_base 和 api_key 來實現(xiàn)。

正如 LlamaIndex 所解釋的那樣，OpenAILike類是對 OpenAI 模型的輕量級封裝。其目的是確保與提供 OpenAI 兼容 API 的第三方工具兼容。然而，目前 LlamaIndex 限制了使用自定義模型的 OpenAI 類的使用，主要是因為需要從模型名稱中推斷出某些元數(shù)據(jù)。

這個限制說明未來需要優(yōu)化實現(xiàn)過程，讓用戶更容易集成和切換不同 LLMs，無論是 OpenAI 還是本地 LLMs。

OpenAI兼容的API服務

選擇使用與 OpenAI 兼容的 API 服務作為應用程序和 LLMs 之間的中介是一個戰(zhàn)略性的決定，旨在提高模塊化和增強靈活性。這種方法允許在不更改應用程序代碼的情況下無縫更換 LLMs，從而減輕了直接集成可能出現(xiàn)的兼容性問題。這樣的設置確保應用程序?qū)λ鼈兘换サ木唧w LLMs 保持中立，從而便于更容易地進行更新和維護。

在選擇合適的 API 服務的過程中，我們最初的選擇是 GPT4All Rest API。眾所周知，GPT4All是一個很好的工具，通過在標準硬件上啟用對 LLMs 的使用，使其更加大眾化。然而，現(xiàn)在 GPT4All Rest API 與當前的 OpenAI API 規(guī)范不兼容，因此我們無法切換后端的 LLM 服務。隨后，我們評估了 LocalAI ，它被證明與 LlamaIndex OpenAILike 類兼容并且能夠有效地運行。這種兼容性對我們來說十分重要，LocalAI 符合當前的規(guī)范，并能夠與我們的框架平滑集成。

管理Docker鏡像的大小

選擇在Docker容器中運行我們的演示是由Docker為LLM應用提供的諸多優(yōu)勢驅(qū)動的，包括增強的可移植性、可重現(xiàn)性、可擴展性、安全性、資源效率和簡化的部署流程。然而，在構(gòu)建我們的演示的Docker鏡像過程中，我們注意到安裝PyTorch后鏡像大小顯著增加。為了解決這個問題并減小CPU實例的Docker鏡像大小，我們選擇直接從官方的wheel安裝PyTorch，下載地址為 http://download.pytorch.org/whl/cpu：

pip install --no-cache-dir -r requirements.txt \    --extra-index-url https://download.pytorch.org/whl/cpu

此方法顯著減少了壓縮后的鏡像大小，僅為 435.06 MB，而GPU實例的壓縮后大小則變得更大了，為 5.38 GB。對于那些希望用 CPU 實例構(gòu)建鏡像的人來說，采用這種策略尤為有效，這一策略在功能和效率之間取得了平衡。

08 鏈接

本文Github 鏈接：

https://github.com/LinkTime-Corp/llm-in-containers/tree/main/tabular-data-analysis

博客原文：

https://blog.gopenai.com/enhancing-tabular-data-analysis-with-llms-78af1b7a6df9

[1]MixSelfConsistency

https://github.com/run-llama/llama-hub/tree/main/llama_hub/llama_packs/tables/mix_self_consistency

[2]ChainOfTable

https://github.com/run-llama/llama-hub/tree/main/llama_hub/llama_packs/tables/chain_of_table

[3]演示代碼

https://github.com/LinkTime-Corp/llm-in-containers/tree/main/tabular-data-analysis/src

[4]main.py

https://github.com/LinkTime-Corp/llm-in-containers/blob/main/tabular-data-analysis/src/main.py

[5]backend.py

https://github.com/LinkTime-Corp/llm-in-containers/blob/main/tabular-data-analysis/src/backend.py

[6]constants.py

https://github.com/LinkTime-Corp/llm-in-containers/blob/main/tabular-data-analysis/src/constants.py

分享到

zhupb

相關推薦