在數(shù)字時代，準確可靠的數(shù)據(jù)對企業(yè)來說至關(guān)重要。這些數(shù)據(jù)為企業(yè)提供個性化的體驗，并幫助他們做出明智的決策[1]。然而，由于龐大的數(shù)據(jù)量和復(fù)雜度，處理數(shù)據(jù)常常面臨重大挑戰(zhàn)，需要進行大量枯燥且手動的工作。在這種情況下，大語言模型（LLM）應(yīng)運而生，這項變革性技術(shù)具備了自然語言處理和模式識別的能力，有望徹底改變數(shù)據(jù)清洗的過程，使數(shù)據(jù)更具可用性。

在數(shù)據(jù)科學(xué)家的工具箱中，LLM就像是扳手和螺絲刀，能夠重塑活動并發(fā)揮作用，以提升數(shù)據(jù)質(zhì)量。就像諺語中說的一錘定音，LLM將揭示出可行的洞見，最終為創(chuàng)造更好的客戶體驗鋪平道路。

現(xiàn)在，讓我們直接進入今天的案例。

案例

當對學(xué)生進行調(diào)查問卷時，將事實字段設(shè)為自由形式的文本是最糟糕的選擇！你可以想象我們收到的一些回答。

開個玩笑，我們的客戶之一是Study Fetch，這是一個AI驅(qū)動的平臺，利用課程材料為學(xué)生創(chuàng)建個性化的全方位學(xué)習(xí)套件。他們在大學(xué)生中進行了一項調(diào)查，收到了超過10,000個反饋。然而，他們的首席執(zhí)行官兼聯(lián)合創(chuàng)始人Esan Durrani遇到了一個小問題。原來，在調(diào)查中，"主修"字段是一個自由形式的文本框，這意味著回答者可以輸入任何內(nèi)容。作為數(shù)據(jù)科學(xué)家，我們知道這對于進行統(tǒng)計計算來說絕對不是一個明智的選擇。所以，從調(diào)查中獲得的原始數(shù)據(jù)看起來像這樣...

天了嚕，讓你的Excel準備好吧！準備好花上一個小時，甚至三個小時的冒險來對付這些數(shù)據(jù)異類。

但是，別擔心，我們有一把大語言模型（LLM）的錘子。

正如一位長者所言，假如你只有一把錘子，那么所有的問題都會像是釘子。而數(shù)據(jù)清洗工作難道不正是最適合這把錘子的任務(wù)嗎？

我們只需要簡單地使用我們友好的大語言模型將它們歸類到已知的類別中。特別是，OpenAI的生成式預(yù)訓(xùn)練Transformer（GPT）模型，正是當下流行的聊天機器人應(yīng)用ChatGPT背后的LLM。GPT模型使用了高達1750億個參數(shù)，并且已經(jīng)通過對來自公開數(shù)據(jù)集Common Crawl的26億個存儲網(wǎng)頁進行訓(xùn)練。此外，通過一種稱為從人類反饋中的強化學(xué)習(xí)（RLHF）的技術(shù)，訓(xùn)練者可以推動并激勵模型提供更準確和有用的回答[2]。

對于我們的目標來說，我相信超過1750億個參數(shù)應(yīng)該足夠了，只要我們能給出正確的提示（prompt）。

圖片由Kelly Sikkema上傳至Unsplash

關(guān)鍵在于提示語

來自某AI公司的Ryan和Esan，他們的主要業(yè)務(wù)是編寫出色的提示語。他們提供了我們的提示語的第一個版本。這個版本很棒，使用語言推斷[3]效果非常好，但有兩個可以改進的地方：

首先，它僅適用于單個記錄。

其次，它使用了達芬奇模型的'Completion'方法（一提到它，我的銀行賬戶就開始恐慌）。

這導(dǎo)致了過高的成本，這是我們無法接受的。因此，Ryan和我分別使用'gpt-3.5-turbo'重新編寫了提示語，以便進行批量操作。對我來說，OpenAI的提示語最佳實踐和ChatGPT Prompt Engineering for Developers課程非常有幫助。經(jīng)過一系列思考、實施、分析和改進的迭代，我們最終獲得了一個出色的工作版本。

現(xiàn)在，讓我們馬上展示經(jīng)過第二次修訂后的提示語：

對這個提示語，LLM給的回應(yīng)是：

這個方法或多或少會有些效果。但我并不太喜歡那些重復(fù)的、長篇大論的項目名稱。在LLM中，文本就是tokens，tokens就是真金白銀啊。你知道，我的編程技能是在互聯(lián)網(wǎng)泡沫破裂的火熱深淵中鍛煉出來的。讓我告訴你，我從不放過任何一次節(jié)省成本的機會。

因此，我在“期望的格式”部分略微修改了提示語。我要求模型只輸出調(diào)查反饋的序數(shù)（例如，上面的戲劇為1）和項目的序數(shù)（例如，文學(xué)為1）。然后Ryan建議我應(yīng)該要求輸出JSON格式而不是CSV，以便更簡單地解析。他還建議我添加一個“示例輸出”部分，這是一個極好的建議。

最終的提示語如下（為清晰起見，已簡化）：

模型的輸出結(jié)果是：

所以，正如我們之前討論的，模型的輸出是我們定義的類別與調(diào)查響應(yīng)的序數(shù)之間的映射。以第一行為例：1,1。這意味著1是響應(yīng)編號，1是相應(yīng)的映射程序編號。調(diào)查響應(yīng)1是“戲劇”，映射的程序1是“文學(xué)與人文”。這看起來很正確！戲劇在它應(yīng)有的#1位置，成為了所有人的焦點。

雖然輸出結(jié)果乍看之下像是嵌入的輸出（用于聚類和降維），但它們只是相同的映射信息，只不過是序數(shù)位置。除了在token使用上提供一些成本優(yōu)勢外，這些數(shù)字還更容易解析。

我們現(xiàn)在可以把原始的調(diào)查反饋文件轉(zhuǎn)換為有意義的專業(yè)，做聚合，獲得有價值的可操作的洞察。

但等等，我不打算坐在電腦前，把每一塊調(diào)查反饋輸入瀏覽器并計算映射。這除了令人頭腦麻木，錯誤率也是無法接受的。

我們需要的是一些好的自動化工具。讓我們來看看API...

API救世主

可能你已經(jīng)知道，應(yīng)用程序接口（API）使我們的程序能夠高效地與第三方服務(wù)進行交互。盡管許多人通過使用ChatGPT實現(xiàn)了令人印象深刻的成果，但語言模型的真正潛力在于利用API將自然語言能力無縫地集成到應(yīng)用程序中，使用戶感覺不到它的存在。就像你正在用來閱讀這篇文章的手機或電腦背后的令人難以置信的科學(xué)技術(shù)。

我們將使用REST來調(diào)用chat completion API。調(diào)用的示例如下：

我們快速看一下參數(shù)及其效果。

模型

到目前為止，對公眾開放的聊天完成模型只有g(shù)pt-3.5-turbo。Esan可以使用GPT 4模型，我對此非常嫉妒。雖然gpt-4更準確，且出現(xiàn)錯誤的可能性更小[2]，但它的成本大約是gpt-3.5-turbo的20倍，對于我們的需求來說，gpt-3.5-turbo完全足夠了，謝謝。

溫度（temperature）

temperature是我們可以傳遞給模型的最重要的設(shè)置之一，僅次于提示。根據(jù)API文檔，它可以設(shè)置在0和2之間的值。它有著顯著的影響[6]，因為它控制輸出中的隨機性，有點像你開始寫作前體內(nèi)的咖啡因含量。你可以在這里找到一個對于每個應(yīng)用可以使用的值的指南[7]。

對于我們的用例，我們只想要沒有變化的輸出。我們希望引擎給我們原封不動的映射，每次都是相同的。所以，我們使用了0的值。

N值

生成多少個聊天完成選擇？如果我們是為了創(chuàng)造性寫作并希望有多個選擇，我們可以使用2或者3。對于我們的情況，n=1（默認）會很好。

角色

角色可以是system（系統(tǒng)）、user（用戶）或assistant（助手）。系統(tǒng)角色提供指令和設(shè)定環(huán)境。用戶角色代表來自最終用戶的提示。助手角色是基于對話歷史的響應(yīng)。這些角色幫助構(gòu)造對話，并使用戶和AI助手能夠有效地互動。

模型最大Token

這不一定是我們在請求中傳遞的參數(shù)，盡管另一個參數(shù)max_tokens限制了從聊天中獲取的響應(yīng)的總長度。

首先，token可以被認為是一個詞的一部分。一個token大約是英語中的4個字符。例如，被歸于亞伯拉罕·林肯（Abraham Lincoln）和其他人的引語“The best way to predict the future is to create it”包含了11個token。

如果你認為一個token就是一個詞，那么這里有一個64個token的例子，可以顯示它并非那么簡單。

做好準備，因為現(xiàn)在要揭示一個令人震驚的事實：每個你在消息中使用的表情符號都會額外增加高達6個重要令牌的成本。沒錯，你喜愛的笑臉和眨眼都是偷偷摸摸的小令牌竊賊！

模型的最大token窗口是一種技術(shù)限制。你的提示（包括其中的任何額外數(shù)據(jù)）和答案必須適應(yīng)模型的最大限制。在對話完成的情況下，內(nèi)容、角色和之前的所有消息都會占用token。如果你從輸入或輸出（助手消息）中刪除一條消息，模型將完全失去對它的了解[8]。就像多麗在尋找奇科時，沒有法比奧，沒有賓果，沒有哈波，沒有艾爾莫？... 尼莫！

對于gpt-3.5-turbo，模型的最大限制是4096個token，或大約16000個字符。對于我們的示例來說，提示大約占用2000個字符，每個調(diào)查反饋平均約20個字符，映射反饋約為7個字符。因此，如果我們在每個提示中放入N個調(diào)查反饋，最大字符數(shù)應(yīng)為：

2000 + 20N + 7N應(yīng)小于16000。

解這個等式后，我們得到一個小于518或大約500的N值。從技術(shù)角度來說，我們可以在每個請求中放入500個調(diào)查反饋，并處理我們的數(shù)據(jù)20次。然而，我們選擇在每個反饋中放入50個反饋，并進行200次處理，因為如果我們在單個請求中放入超過50個調(diào)查反饋，我們會偶爾收到異常響應(yīng)。有時候，服務(wù)可能會出現(xiàn)問題！我們不確定這是一個系統(tǒng)的長期問題，還是我們碰巧遇到了不幸的情況。

那么，我們該如何使用我們擁有的API呢？讓我們進入精彩部分，代碼。

代碼的方法

Node.js是一個JavaScript運行環(huán)境[9]。我們將編寫一個Node.js/JavaScript程序，它將按照這個流程圖所描述的動作執(zhí)行操作：

程序的流程圖，由作者繪制

我的Javascript技能并不是那么出色。我可以寫更好的Java，PHP，Julia，Go，C#，甚至Python。但是Esan堅持使用Node，所以就用Javascript吧。

完整的代碼，提示和樣本輸入可以在這個GitHub鏈接（https://github.com/aaxis-nram/data-cleanser-llm-node）中找到。然而，讓我們先看一下最吸引人的部分：

首先，讓我們看看我們?nèi)绾问褂谩癱sv-parser” Node庫來讀取CSV文件。

接下來，我們調(diào)用分類器來生成映射。

然后，我們從類別、主提示文本以及CSV中的數(shù)據(jù)構(gòu)造出提示。接著，我們使用他們的 OpenAI Node 庫將提示發(fā)送給服務(wù)。

最后，當所有迭代都完成后，我們可以將 srcCol 文本（即調(diào)查反饋）轉(zhuǎn)換為 targetCol（即標準化的項目名稱），并寫出CSV。

這點 JavaScript 并沒有我預(yù)期的那么復(fù)雜，而且在2到3小時內(nèi)就完成了。我想，任何事情在你開始做之前總是看起來令人生畏的。

所以，現(xiàn)在我們已經(jīng)準備好了代碼，是時候進行最終的執(zhí)行了…

執(zhí)行過程

現(xiàn)在，我們需要一個地方來運行這個代碼。在爭論是否應(yīng)該在云實例上運行負載之后，我做了一些快速的計算，意識到我可以在我的筆記本電腦上在不到一個小時內(nèi)跑完。這還不算太糟糕。

我們開始進行一輪測試，并注意到該服務(wù)在10次請求中有1次會返回提供給它的數(shù)據(jù)，而不是映射數(shù)據(jù)。因此，我們只會收到調(diào)查反饋的列表。由于沒有找到映射，CSV文件中的這些反饋將被映射為空字符串。

為了避免在代碼中檢測并重試，我決定重新運行腳本，但只處理目標列為空的記錄。

腳本會先將所有行的目標列設(shè)為空，并填入規(guī)范化的程序名稱。由于響應(yīng)中的錯誤，一些行的目標列不會被映射，保持為空。當腳本第二次運行時，它只會為第一次運行中未處理的響應(yīng)構(gòu)建提示。我們運行了幾次程序，并將所有內(nèi)容都映射出來。

多次運行大約花費了30分鐘左右，并且不需要太多監(jiān)督。以下是模型中一些更有趣的映射的精選：

輸入與程序名稱之間的樣例映射，圖表由作者繪制

大多數(shù)看起來都對。不確定組織行為（Organizational Behavior）是否屬于社會科學(xué)（Social Sciences）或商業(yè)（Business）？我想任何一個都可以。

每個大約50條記錄的請求總共需要大約800個token。整個練習(xí)的成本是40美分。我們可能在測試、重新運行等方面花費了10美分。所以，總成本大約是50美分，大約2.5小時的編碼/測試時間，半小時的運行時間，我們完成了任務(wù)。

總成本：大約不到1美元

總時間：大約3小時

或許手動使用Excel進行轉(zhuǎn)換，排序，正則表達式，和拖拽復(fù)制，我們可能在相同的時間內(nèi)完成它，并節(jié)省了一點小錢。但是，這樣做更有趣，我們學(xué)到了東西，我們有了可以重復(fù)的腳本/流程，并且還產(chǎn)出了一篇文章。而且，我覺得StudyFetch可以負擔得起50美分。

這是我們以高效率，高收益的方式實現(xiàn)的一個很好的應(yīng)用，但LLM還可以用于哪些其他用途呢？

探索更多的用例

將語言功能添加到你的應(yīng)用程序中可能有比我上面所示更多的用例。以下是與我們剛剛查看的評論數(shù)據(jù)相關(guān)的更多用例：

數(shù)據(jù)解析和標準化：LLM可以通過識別和提取非結(jié)構(gòu)化或半結(jié)構(gòu)化數(shù)據(jù)源（如我們剛剛看到的數(shù)據(jù)源）中的相關(guān)信息，幫助解析和標準化數(shù)據(jù)。

數(shù)據(jù)去重：LLM可以通過比較各種數(shù)據(jù)點來幫助識別重復(fù)記錄。例如，我們可以在評論數(shù)據(jù)中比較姓名、專業(yè)和大學(xué)，以標記潛在的重復(fù)記錄。

數(shù)據(jù)摘要：LLM可以對不同的記錄進行摘要，以了解回答的概況。例如，對于問題“在學(xué)習(xí)過程中你面臨的最大挑戰(zhàn)是什么？”，一個大語言模型可以對來自同一專業(yè)和大學(xué)的多個回答進行摘要，以查看是否存在任何模式。然后，我們可以將所有的摘要放入一個請求中，得到一個整體的列表。但我猜每個客戶細分的摘要可能會更有用。

情感分析：LLM可以分析評論以確定情感，并提取有價值的見解。對于問題“你愿意為幫助你學(xué)習(xí)的服務(wù)付費嗎？”，LLM可以將情感分類為0（非常負面）到5（非常正面）。然后，我們可以利用這一點通過細分分析學(xué)生對付費服務(wù)的興趣。

盡管學(xué)生評論只是一個微小的示例，但這項技術(shù)在更廣泛的領(lǐng)域中有著多種應(yīng)用。在我所在的AAXIS公司，我們專注于企業(yè)和消費者數(shù)字商務(wù)解決方案。我們的工作包括將大量數(shù)據(jù)從現(xiàn)有的舊系統(tǒng)遷移到具有不同數(shù)據(jù)結(jié)構(gòu)的新系統(tǒng)。為了確保數(shù)據(jù)的一致性，我們使用各種數(shù)據(jù)工具對源數(shù)據(jù)進行分析。這篇文章中介紹的技術(shù)對于這個目標非常有幫助。

其他數(shù)字商務(wù)用例包括檢查產(chǎn)品目錄中的錯誤、編寫產(chǎn)品說明、掃描評論回復(fù)和生成產(chǎn)品評論摘要等等。相比詢問學(xué)生的專業(yè)，編寫這些用例的代碼要簡單得多。

然而，需要注意的是，盡管LLM在數(shù)據(jù)清洗方面是強大的工具，但它們應(yīng)與其他技術(shù)和人工監(jiān)督相結(jié)合使用。數(shù)據(jù)清洗過程通常需要領(lǐng)域?qū)I(yè)知識、上下文理解和人工審核，以做出明智的決策并保持數(shù)據(jù)的完整性。LLM并不是推理引擎[10]，它們只是下一個詞的預(yù)測器。它們往往以極大的自信和說服力提供錯誤的信息（幻覺）[2][11]。在我們的測試中，由于我們主要涉及分類，我們沒有遇到任何幻覺的情況。

如果您謹慎行事并了解其中的陷阱，LLM可以成為您工具箱中強大的工具。

尾聲

在這篇文章中，我們首先研究了數(shù)據(jù)清洗的一個具體應(yīng)用案例：將調(diào)查問卷反饋規(guī)范化為一組特定的值。這樣做可以將反饋進行分組并獲得有價值的見解。為了對這些反饋進行分類，我們使用了OpenAI的GPT 3.5 Turbo，一個強大的LLM。我們詳細介紹了使用的提示、如何利用API調(diào)用來處理提示以及實現(xiàn)自動化的代碼。最終，我們成功地將所有組件整合在一起，以不到一美元的成本完成了任務(wù)。

我們是不是像拿著一把傳說中的LLM錘子，找到了在自由文本形式的調(diào)查反饋中那顆完美閃亮的釘子？也許吧。更可能的是，我們拿出了一把瑞士軍刀，用它剝皮并享用了一些美味的魚肉。雖然LLM不是專門為此而設(shè)計的工具，但仍然非常實用。而且，Esan真的非常喜歡壽司。

那么，你有什么LLM的用例呢？我們非常樂意聽聽你的想法！

鳴謝

本文的主要工作由我、Esan Durrani和Ryan Trattner完成，我們是StudyFetch的聯(lián)合創(chuàng)始人。StudyFetch是一個基于人工智能的平臺，利用課程資料為學(xué)生創(chuàng)建個性化的一站式學(xué)習(xí)集。

我要感謝AAXIS Digital的同事Prashant Mishra、Rajeev Hans、Israel Moura和Andy Wagner對本文的審查和建議。

我還要感謝我30年的朋友、TRM Labs的工程副總裁Kiran Bondalapati，感謝他在生成式人工智能領(lǐng)域的初期引導(dǎo)以及對本文的審閱。

同時，我要特別感謝我的編輯Megan Polstra，她一如既往地為文章增添了專業(yè)和精致的風格。