“ 人工智能做數(shù)據(jù)分析的原理是生成相對應的分析語句或代碼，而不是直接讓大模型對數(shù)據(jù)進行處理。”

最近在研究基于人工智能進行數(shù)據(jù)分析，主要研究了基于langchain集成Pandas的數(shù)據(jù)分析智能體；以及數(shù)據(jù)分析開源項目Vanna，一個基于大模型做數(shù)據(jù)分析的框架。

而在對比兩者實現(xiàn)原理的過程中就發(fā)現(xiàn)了一個問題，基于SQL做數(shù)據(jù)分析和基于Pandas做數(shù)據(jù)分析的區(qū)別以及優(yōu)劣勢是什么。

基于人工智能的數(shù)據(jù)分析

在傳統(tǒng)的數(shù)據(jù)分析過程中主要采用的也是SQL和Pandas兩種方式進行數(shù)據(jù)處理；記憶SQL的優(yōu)點是結構化處理功能強大，借助于SQL引擎能夠處理大批量數(shù)據(jù)；而Pandas則主要基于內存進行處理，雖然可以進行分批加載，但在某些場景下會存在一些問題。

而現(xiàn)在基于大模型做數(shù)據(jù)分析，其本質上還是利用SQL和Pandas的處理能力，并不是讓大模型直接對數(shù)據(jù)進行分析；不管是Langchain的Pandas數(shù)據(jù)處理還是Vanna的數(shù)據(jù)分析，都是讓大模型理解人類的自然語言，然后生成相應的SQL語句或Pandas代碼，然后調用執(zhí)行引擎獲取結果。

只不過在這里大模型取代了人類的工作，在之前進行數(shù)據(jù)分析時，DBA工程師需要根據(jù)需求編寫SQL或其它代碼，然后獲得結果；而有了大模型之后，就可以讓大模型自己理解需求，然后生成相對應的代碼，這樣就大大提升了數(shù)據(jù)分析的效率。

所以大模型做數(shù)據(jù)分析的本質，其實是代碼生成；其核心是基于自然語言理解和代碼生成的結合。

那么使用SQL和Pandas各有什么優(yōu)劣勢呢？

Pandas由于是依靠內存進行處理，因此Pandas在處理大批量數(shù)據(jù)有天生的缺陷；而SQL依靠SQL引擎，在處理大批量數(shù)據(jù)時有一定的優(yōu)勢；但如果是基于傳統(tǒng)的關系型數(shù)據(jù)庫，當數(shù)據(jù)量達到一定程度時，SQL依然會存在各種各樣的問題。

因此，如果數(shù)據(jù)量非常大的情況下，需要使用一些數(shù)倉中間件，比如說flink，hive等。

但SQL相對于Pandas還有一個優(yōu)點就是，SQL是完全結構化的數(shù)據(jù)，沒有那么多亂七八糟的格式；而Pandas雖然也擅長處理格式化數(shù)據(jù)，但有些數(shù)據(jù)并不是完全格式化的，或者說是完全標準的二維表關系。

比如說，在csv和excel表中，雖然也是格式化的數(shù)據(jù)；但可以對其單元格進行合并，特別是excel表，雖然看起來數(shù)據(jù)格式很簡單，但實際場景中其數(shù)據(jù)結構非常復雜；有合并行，也有合并列，而且可以在不同的地方進行合并，這就對Pandas的數(shù)據(jù)處理產生很大的影響。

所以，在借助大模型做數(shù)據(jù)分析時，我們需要根據(jù)自己的需求以及數(shù)據(jù)格式和數(shù)據(jù)量，選擇適合自己的處理方式；而且有些時候可以把兩種方式結合起來。

畢竟，在不同的數(shù)據(jù)庫引擎中，其SQL也有一定的差別；而Pandas卻可以統(tǒng)一成固定的df對象進行處理，這一點屏蔽了不同數(shù)據(jù)源之間的區(qū)別，對后續(xù)處理來說更加的方便。

本文轉載自???AI探索時代??? 作者：DFires