譯者 | 朱先忠

審校 | 重樓

VoxelGPT使用自然語言查詢圖像數據集（圖片由作者提供）

簡介

與表格數據不同，計算機視覺任務的數據集是非結構化的——如像素塊、標簽堆、標簽袋，有時還存在一些結構化的元數據。盡管如此，我們這些從事計算機視覺工作的人仍然需要能夠有效地篩選這些數據，以了解數據集，準備訓練和測試集，找到模式，識別邊緣案例，并評估模型性能等。

當我需要理解視覺數據時（基本上一直都是這樣），我會使用開源庫FiftyOne，這個庫定義了一個強大的Python語法來查詢計算機視覺數據。它有點像計算機視覺數據的非結構化世界的SQL，它允許我以編程方式過濾、排序和語義切片由圖像、視頻甚至3D點云組成的數據集。

幾個月前，隨著ChatGPT熱潮的全面展開，我在OpenAI的網站上看到了一個將自然語言輸入轉換為SQL查詢的示例應用程序。雖然這個應用程序是非常基礎性的，而且計算機視覺數據要復雜得多，但它讓我思考這樣一個問題：可以對圖像和視頻數據集做類似的事情嗎？換句話說：

我們能否利用大型語言模型（LLM）的多功能性，將自然語言查詢轉換為非結構化計算機視覺數據集的過濾視圖？

答案是：是的，我們可以！

最近，我們Voxel51的團隊將LLM的一般語言和推理能力與FiftyOne的查詢語言相結合，構建了VoxelGPT：一款開源人工智能助手，讓您無需編寫一行代碼即可全面查詢計算機視覺數據集！

我們使用langchain、tiktoken和fiftyone開發成功這個工具。你可以在https://gpt.fiftyone.ai/這個網站上免費試用此工具！

這篇文章將向你介紹如何構建一個特定領域LLM應用程序，其中涉及提示工程、軟件工程以及大量的嘗試和錯誤調試等完整過程。

的確，在整個過程中，我們多次碰壁，擔心這項任務不可行。如果你正在嘗試并努力構建一個LLM驅動的應用程序，我希望這篇文章能給你帶來突破自我設定障礙所需的靈感！

本文的目錄結構如下：

• 類似SQL的圖像和視頻查詢
• 定義總體任務
• 給出模型上下文
• 生成和利用示例
• 分解問題
• 投入實際應用

查詢語言

VoxelGPT使用自然語言查詢圖像數據集（圖片由作者提供）

在我們深入研究如何使用LLM生成查詢之前，有必要花點時間先來描述一下我們希望負責模型翻譯任務的查詢語言。以下僅是您需要的一些基本信息。有關這方面內容更全面的概述，請參閱《FiftyOne用戶指南》。如果您已經熟悉該語言，請隨時跳到下一節。

• 數據集（Dataset）：是SQL中的表或Panda中的DataFrame的計算機視覺模擬。它包含與媒體文件集合相關的所有信息。
• 樣本（Sample）：類似于數據表中的一行，樣本是數據集的原子元素。每個樣本都有一個文件路徑，指向一個媒體文件，并存儲與該數據段相關的所有其他信息。
• 字段（Field）：字段類似于數據表中的列，因為它定義了樣本的屬性（例如，圖像寬度、高度和文件路徑）。但是，字段是靈活的，因為它們可以包含其他字段（請參見下面的標簽）。
• 標簽（Label）：標簽是一個存儲語義基礎真相或預測信息的字段。例如，對象檢測存儲在檢測標簽字段中，分類存儲在分類標簽字段中。

與SQL或Pandas一樣，您可以使用查詢操作過濾數據。例如，您可能希望在數據表中查詢以下內容：

列“A”中條目大于0.5的所有行。

然而，盡管數據表本身適用于數字切片和過濾，但非結構化計算機視覺數據本身適用于語義切片，例如：

在至少3次非“狗”地面實況檢測的圖像中檢索具有大邊界框的高置信度“狗”預測。

簡言之，對非結構化數據進行語義切片需要更大的靈活性。

為了實現這一級別的靈活性，FiftyOne定義了一組ViewStage方法，這些方法封裝了允許的查詢操作，如過濾、匹配、選擇、排序和排除。這些方法大致類似于SQL中的SELECT、WHERE和ORDER BY，但由于查詢的空間要大得多，所以方法要多得多，而且這些方法中的每一種都有許多用例。有興趣的讀者請參閱此視圖備忘單進行全面討論。

通過按順序組合多個ViewStage操作，可以獲得數據集的任意子集，稱為DatasetView。

以下是查詢語言在操作中的樣子：給定一個名為my_dataset的數據集，如果我們想在包含“cat”的10個隨機圖像的“predictions”標簽字段中（在其“ground_truth”標簽字段）獲得所有“dog”檢測，那么我們可以使用以下查詢：

view = my_dataset.match(
 F("ground_truth.detections.label").contains(["cat"])
 ).filter_labels(
 "predictions", 
 F("label") == "dog"
 ).take(10)

其中，match（）僅限于“ground_truth”檢測字段中有“cat”的圖像，然后filter_labels（）篩選“predictions”字段，僅檢索“dog”檢測，最后take（）隨機選擇一個子集。

定義任務

當我們開始這段旅程時，我們不知道LLM有什么可能。早在2022年12月，我就玩過ChatGPT，甚至寫了一篇文章《計算機視覺中的隧道視覺：ChatGPT能看到嗎？》探討過聊天機器人對計算機視覺概念的理解。當時，令人印象深刻的是，通用語言模型可以為基本的圖像處理任務編寫基本正確的Python代碼，但在計算機視覺應用程序中使用GPT生成的代碼（無需人工驗證）的想法似乎有些牽強。

在看到了文本轉換成SQL的例子，并閱讀了據報道GPT-4以優異的成績通過了BAR（以及其他考試）后，我決定再次嘗試GPT for CV。我要求GPT-4為幾個簡單的查詢生成Python代碼；最終，我對它的響應感到驚喜。盡管GPT-4開箱即用結果的準確性還有很多不足之處，但是，考慮到我沒有輸入任何關于FiftyOne庫的信息；因此，這樣的結果還是可以理解的。盡管如此，這項工作的前景十分誘人。

要求一致性

當我們嘗試提示技術時（我們稍后會討論），如果我們想將其納入更大的工程管道中，我們首先需要明確地進行任務定義。

由于問題場景的復雜性，GPT模型的響應在不同提示的格式上有很大差異。

以下只是兩個簡單的例子，我們將很快對此進行分析：

提示1：

英文提示：Your task is to convert input natural language queries into Python code to generate ViewStages for the computer vision library FiftyOne. Here is your first natural language query: “Images that only contain dogs”.Give me the FiftyOne code.

中文含義：您的任務是將輸入的自然語言查詢轉換為Python代碼，為計算機視覺庫FiftyOne生成ViewStages。這是你的第一個自然語言查詢：“只包含狗的圖像”。請給我使用FiftyOne庫相關編程代碼。

回復1：

英文回復：Sure, here’s the FiftyOne code that generates a ViewStage for images that only contain dogs:

中文含義：當然，下面是FiftyOne代碼，它為只包含狗的圖像生成ViewStage：

import fiftyone as fo
import fiftyone.zoo as foz

# Load the dataset
dataset = foz.load_zoo_dataset(
 "open-images-v6",
 split="validation",
 label_types=["detections"],
 classes=["Dog"],
)

# Create a view stage that filters out images without any dog detections
view_stage = fo.ViewStage("detections", fo.FilterField("detections", "label", "Dog"))

# Apply the view stage to the dataset
dataset = dataset.add_stage(view_stage)

# View the dataset
session = fo.launch_app(dataset)

此代碼加載Open Images v6驗證數據集，其中僅包含狗的“detections”標簽類型。然后，它創建了一個視圖，過濾掉任何沒有檢測到狗的圖像。最后，將視圖應用于數據集，并在FiftyOne應用程序中啟動。

提示2：

英文提示如下：

Your task is to convert input natural language queries into Python code to generate ViewStages for the machine learning library FiftyOne. Here is your first natural language query: “most unique images with a false positive detection”. Give me the FiftyOne code.

中文含義：您的任務是將輸入的自然語言查詢轉換為Python代碼，為機器學習庫FiftyOne生成ViewStages。這是你的第一個自然語言查詢：“大多數具有假陽性檢測的獨特圖像”。請給我使用FiftyOne庫相關編程代碼。

回復2：

英文回復：Sure, here’s the FiftyOne code to generate ViewStages for the natural language query “most unique images with a false positive detection” using the FiftyOne library in Python:

中文含義：當然，以下是使用Python中的FiftyOne庫為自然語言查詢“具有假陽性檢測的最獨特圖像”生成ViewStages的FiftyOne代碼：

import fiftyone as fo
import fiftyone.zoo as foz

# Load your dataset
dataset = fo.load_dataset("your_dataset_name")

# Define your false positive detection model
model = foz.load_zoo_model("your_model_name")

# Define your pipeline
pipeline = [
 {"$set": {"predictions": {"$predict": model}}},
 {"$match": {"predictions.mistakes.false_positive": True}},
 {"$group": {"_id": "$filepath"}},
 {"$count": "num_images"},
 {"$sort": {"num_images": -1}},
]

# Run your pipeline and display the results in a view stage
view = dataset.aggregate(pipeline).limit(10).display()

在這段代碼中，我們首先加載FiftyOne庫和任何必要的依賴項。然后，我們使用fo.load_dataset（）加載您的數據集。

接下來，我們使用foz.load_zoo_mode（）定義您的假陽性檢測模型。此函數從FiftyOne 動物園模型Zoo加載一個預先訓練的模型，其中包括一系列最先進的計算機視覺模型。

之后，我們使用$set、$match、$group、$count和$sort等聚合命令來定義我們的管道。管道首先使用$set向數據集中包含模型預測的每個樣本添加一個字段。然后，我們使用$match對樣本進行過濾，以便僅包括那些檢測為假陽性的樣本。

接下來，我們使用$group根據樣本的文件路徑對其進行分組，并使用$count計算每組中的圖像數量。最后，我們使用$sort按照圖像數量的降序對組進行排序。

最后，我們在您的數據集上運行管道，并使用limit（）將結果限制為假陽性檢測最多的前10張圖像。然后，我們使用display（）在視圖中顯示結果。

盡管這兩個例子的提示結構相同，但有關的回答在幾個關鍵方面有所不同。例如，響應1試圖通過將ViewStage添加到數據集中來創建DatasetView。響應2定義并應用了一個MongoDB聚合管道，然后是limit（）方法（應用limit這一步），將視圖限制為10個樣本，以及一個不存在的display（）方法。此外，當響應1加載到實際數據集（Open Images V6）中時，響應2實際上是模板代碼，因為需要填寫“your_dataset_name”和“your_model_name”。

歸納來看，這些例子還突出了以下問題：

1. 模塊代碼：一些響應包含用于導入模塊、實例化數據集（和模型）和可視化視圖（sessinotallow=fo.lonch_app（dataset））的代碼。
2. 解釋性文本：在許多情況下，包括教育背景下，該模型解釋其“推理”的事實是積極的。然而，如果我們想代表用戶執行查詢，那么這段解釋性文本就成了障礙。有些查詢甚至會產生多個按文本劃分的代碼塊。

我們真正想要的是LLM用可以復制并粘貼到Python進程中的代碼來響應，而不需要所有額外的負擔。作為提示模型的第一次嘗試，我開始將以下文本作為我希望它翻譯的任何自然語言查詢的前綴：

Your task is to convert input natural language queries into Python code to generate ViewStages for the computer vision library FiftyOne.

Here are some rules:

- Avoid all header code like importing packages, and all footer code like saving the dataset or launching the FiftyOne App.

- Just give me the final Python code, no intermediate code snippets or explanation.

- always assume the dataset is stored in the Python variable `dataset`

- you can use the following ViewStages to generate your response, in any combination: exclude, exclude_by, exclude_fields, exclude_frames, …

至關重要的是，我定義了一個任務，并制定了規則，指導模型允許和不允許做什么。

注意：隨著回復的格式更加統一，我正是從ChatGPT聊天界面通過OpenAI的API使用GPT-4。

限制范圍

我們的團隊還決定，至少在一開始，我們會限制我們要求LLM做的事情的范圍。雖然FiftyOne查詢語言本身就很豐富，但要求預先訓練的模型在沒有任何微調的情況下完成任意復雜的任務會讓人失望。從簡單開始，不斷增加復雜性。

對于這個實驗，我們施加了以下界限：

• 只是圖像和視頻：不要期望LLM查詢3D點云或分組數據集。
• 忽略變化無常的ViewStages：大多數ViewStages都遵循相同的基本規則，但也有少數操作例外。Concat是唯一接收第二個DatasetView的ViewStages；Mongo使用MongoDB聚合語法；GeoNear有一個查詢參數，它接受一個fiftyne.utils.geojson.geo_within（）對象；GeoWithin需要一個2D陣列來定義“內部”所適用的區域。我們決定忽略Concat、Mongo和GeoWithin，并支持除查詢參數之外的所有GeoNear用法。
• 堅持兩個階段：雖然模型可以組成任意數量的階段，但在我見過的大多數工作流中，一個或兩個ViewStage足以創建所需的DatasetView。本文中我們這個項目的目標不是使讀者“陷入困境”，而是為計算機視覺從業者打造一些有用的產品。

提供上下文

VoxelGPT使用自然語言查詢圖像數據集（圖片由作者提供）

除了給模型一個明確的“任務”并提供明確的指令外，我們發現還可以通過向模型提供更多關于FiftyOne的查詢語言如何工作的信息來提高性能。如果沒有這些信息，LLM只能是盲目操作，胡亂在黑暗的大數據世界中抓取。

例如，在提示2中，當我要求提供假陽性預測時，響應試圖用predictions.mistakes.false_ppositive引用這些假陽性。就ChatGPT而言，這似乎是存儲和訪問假陽性信息的合理方式。

該模型不知道在FiftyOne中，檢測預測的真實性/虛假性是用dataset.evalate_detections（）來評估的，在運行所述評估后，您可以通過匹配eval_fp>0來檢索所有具有假陽性的圖像，其中：

images_with_fp = dataset.match(F("eval_fp")>0)

我試圖通過提供其他規則來澄清這項任務，例如：

- When a user asks for the most "unique" images, they are referring to the "uniqueness" field stored on samples.

- When a user asks for the most "wrong" or "mistaken" images, they are referring to the "mistakenness" field stored on samples.

- If a user doesn't specify a label field, e.g. "predictions" or "ground_truth" to which to apply certain operations, assume they mean "ground_truth" if a ground_truth field exists on the data.

我還提供了有關標簽類型的信息：

- Object detection bounding boxes are in [top-left-x, top-left-y, width, height] format, all relative to the image width and height, in the range [0, 1]

- possible label types include Classification, Classifications, Detection, Detections, Segmentation, Keypoint, Regression, and Polylines

此外，雖然通過向模型提供允許的視圖階段列表，我能夠促使它使用它們，但它并不知道：

• 當給定的階段（stage）相關時，或
• 如何以正確的語法來使用階段

為了填補這一空白，我想向LLM提供有關每個視圖階段的信息。為此，我編寫了代碼來循環瀏覽視圖階段（可以使用fiftyone.list_view_stages（）列出），存儲文檔字符串，然后將文檔字符串的文本拆分為描述和輸入/參數。

然而，我很快就遇到了一個問題：上下文長度。

通過OpenAI API使用基本的GPT-4模型，我已經遇到了8192令牌上下文長度的問題。這是在添加示例或任何關于數據集本身的信息之前！

OpenAI確實提供了一個帶有32768個令牌上下文的GPT-4模型，理論上我本可以使用它，但粗略的計算讓我相信這可能會變得十分昂貴。如果我們填寫整個32k代幣上下文，考慮到OpenAI的定價，每個查詢大約需要2美元！

相反，我們的團隊重新考察了我們使用的方法，并采取了以下措施：

• 切換到GPT-3.5
• 最小化令牌計數
• 對輸入信息更加挑剔

切換到GPT-3.5

沒有免費午餐這回事——這確實導致了性能的略微下降，至少在最初是這樣。在項目的過程中，我們能夠通過及時的工程恢復并遠遠超過這一點！在我們的案例中，付出的努力值得節省成本。在其他情況下，可能不會。

最小化令牌計數

隨著上下文長度成為限制因素，我采用了以下簡單技巧：使用ChatGPT優化提示！

一次一個ViewStage，我獲取原始描述和輸入列表，并將這些信息輸入ChatGPT，同時提示LLM在保留所有語義信息的同時盡量減少該文本的令牌計數。使用tiktoken計算原始版本和壓縮版本中的代幣，我能夠將代幣數量減少約30%。

更具選擇性

雖然為模型提供上下文很好，但根據手頭的任務，某些信息比其他信息更有幫助。如果模型只需要生成一個涉及兩個ViewStage的Python查詢，那么它可能不會從其他ViewStage所接受的輸入信息中受益匪淺。

我們知道我們需要一種根據輸入的自然語言查詢來選擇相關信息的方法。然而，這并不像對描述和輸入參數進行相似性搜索那么簡單，因為前者的語言通常與后者截然不同。我們需要一種將輸入和信息選擇聯系起來的方法。

事實證明，這種聯系就是一個例子。

示例

生成示例

如果您曾經使用過ChatGPT或另一個LLM，您可能已經親身體驗過如何為模型提供哪怕只是一個相關的示例也能顯著提高性能。

作為開始，我提供了10個完全合成的示例，并通過在任務規則和輸入提示中的ViewStage描述下面添加這些示例，最后將這些示例傳遞給GPT-3.5：

以下是A、B形式的輸入輸出對的幾個示例：

A) "Filepath starts with '/Users'"

B) `dataset.match(F("filepath").starts_with("/Users"))`

A) "Predictions with confidence > 0.95"

B) `dataset.filter_labels("predictions", F("confidence") > 0.95)`

…………

僅通過這10個例子，模型的響應質量就有了顯著的提高，因此我們的團隊決定對此進行系統化處理。

1. 首先，我們梳理了我們的文檔，找到了通過ViewStages組合創建的視圖的任何和所有的示例。
2. 然后，我們瀏覽了ViewStages列表并添加了示例，以便盡可能全面地涵蓋用法語法。為此，我們確保每個參數或關鍵字至少有一個示例，為模型提供一個可遵循的模式。
3. 在介紹了用法語法的情況下，我們改變了示例中字段和類的名稱，這樣模型就不會對與階段相關的名稱產生任何錯誤的假設。例如，我們不希望模型僅僅因為match_labels（）的所有示例碰巧都包含一個“person”類，就將person類與match_labels（）方法強關聯。

選擇類似示例

在這個示例生成過程的最后，我們已經有了數百個示例，遠遠超出了上下文長度。幸運的是，這些示例包含（作為輸入的）自然語言查詢，我們可以直接將其與用戶輸入的自然語言查詢進行比較。

為了進行比較，我們使用OpenAI的text-embedding-ada–002模型預先計算了這些示例查詢的嵌入。在運行時，用戶的查詢嵌入了相同的模型，并選擇了具有最相似的自然語言查詢（按余弦距離）的示例。最初，我們使用ChromaDB來構建內存中的向量數據庫。然而，考慮到我們處理的是數百或數千個向量，而不是數十萬或數百萬個向量，實際上切換到精確的向量搜索更有意義（加上我們的依賴性有限）。

管理提示相關的這些示例和組件變得越來越困難，所以正是在這一點上，我們開始使用LangChain的提示模塊。最初，我們可以使用他們的相似性ExampleSelector來選擇最相關的示例，但最終我們不得不編寫一個自定義的ExampleSelecter，這樣我們就可以更好地控制預過濾。

篩選合適的示例

在計算機視覺查詢語言中，查詢的適當語法可能取決于數據集中樣本的媒體類型：例如，有時需要將視頻與圖像區別對待。我們決定只給出給定數據集語法正確的例子，而不是通過給出看似沖突的例子來混淆模型，或者通過強迫模型根據媒體類型進行推斷來使任務復雜化。在向量搜索的上下文中，這被稱為預過濾。

這個想法非常有效，以至于我們最終將同樣的考慮應用于數據集的其他功能。在某些情況下，差異僅僅是語法上的——在查詢標簽時，訪問Detections標簽的語法與Classification標簽的語法不同。其他過濾器更具策略性：有時我們不想讓模型知道查詢語言的某個特性。

例如，我們不想給出使用它無法訪問的計算的有關LLM示例。如果沒有為特定數據集構建文本相似性索引，那么將搜索最佳視覺匹配的模型示例提供給自然語言查詢是沒有意義的。同樣，如果數據集沒有任何評估運行，那么查詢真陽性和假陽性將產生錯誤或無效結果。

您可以在GitHub存儲庫的view_stage_example_selector.py文件中看到完整的示例預過濾管道。

基于示例選擇上下文信息

對于給定的自然語言查詢，我們使用ExampleSelector選擇的示例來決定在上下文中提供哪些附加信息。

特別是，我們統計這些選定示例中每個ViewStage的出現次數，確定五個最頻繁的“ViewStage”，并在提示中添加關于這些ViewStage輸入參數的描述和信息作為上下文。這樣做的理由是，如果一個階段經常出現在類似的查詢中，那么它很可能（但不能保證）與該查詢相關。

如果它不相關，那么描述將幫助模型確定它不相關。如果相關，那么有關輸入參數的信息將幫助模型生成語法正確的ViewStage操作。

分而治之

VoxelGPT使用自然語言查詢圖像數據集（圖片由作者提供）

到目前為止，我們一直專注于將盡可能多的相關信息——而且只是相關信息——壓縮到一個提示中。但這種方法已經到了極限。

即使沒有考慮到每個數據集都有自己的字段和類名稱這一事實，可能的Python查詢空間也太大了。

為了取得進展，我們需要把問題分解成更小的部分。從最近開發的方法中獲得靈感，包括思想鏈提示和選擇推理提示，我們將生成數據集視圖的問題分為四個不同的選擇子問題：

1. 算法
2. 算法的運行
3. 相關字段
4. 相關類名

然后，我們將這些選擇“鏈接”鏈接在一起，并在DatasetView推斷的最后提示中將它們的輸出傳遞給模型。

對于這些子任務中的每一個，都適用相同的一致性和簡單性原則。我們試圖盡可能地從現有示例中回收利用自然語言查詢，但強調要簡化每個選擇任務的所有輸入和輸出的格式。對一個鏈接來說，最簡單的表達對另一個鏈接可能不是最簡單的！

算法

在FiftyOne中，數據集上的計算產生的信息被存儲為“運行”（run）。這包括計算，如唯一性（uniqueness），它測量每個圖像相對于數據集中其他圖像的唯一性，以及硬度（hardness），它量化模型在嘗試學習該樣本時將經歷的困難。它還包括相似性（similarity）的計算，包括為與每個樣本相關的嵌入生成向量索引，甚至包括我們之前談到的評估計算。

每個計算都會生成不同類型的結果對象，該對象具有自己的API。此外，ViewStages和這些計算之間沒有任何一一對應的關系。

讓我們以唯一性（uniqueness）為例作簡單討論。唯一性計算結果存儲在每張圖像的浮點值字段（默認為“uniqueness”）中。這意味著根據情況，您可能需要按唯一性排序：

view = dataset.sort_by("uniqueness")

檢索唯一性高于特定閾值的樣本：

from fiftyone import ViewField as F
view = dataset.match(F("uniqueness") > 0.8)

甚至只是顯示唯一性字段：

view = dataset.select_fields("uniqueness")

在這個選擇步驟中，我們讓LLM預測哪些可能的計算可能與用戶的自然語言查詢相關。此任務的示例如下：

Query: "most unique images with a false positive"
Algorithms used: ["uniqueness", "evaluation"]

算法的運行

一旦確定了潛在的相關計算算法，我們就要求LLM選擇每次計算的最合適運行。這一點至關重要，因為某些計算可以在具有不同配置的同一數據集上多次運行，而ViewStage可能只有在正確的“運行”下才有意義。

相似性運行就是一個很好的例子。假設您在數據上測試兩個模型（InceptionV3和CLIP），并在數據集上為每個模型生成了向量相似性索引。當使用SortBySimilarity視圖階段時，哪些圖像被確定為與哪些其他圖像最相似，這在很大程度上取決于嵌入模型，因此以下兩個查詢需要生成不同的結果：

## query A:
"show me the 10 most similar images to image 1 with CLIP"

## query B:
"show me the 10 most similar images to image 1 with InceptionV3"

這種運行選擇過程是為每種類型的計算單獨處理的，因為每種計算都需要一組修改后的任務規則和示例。

相關字段

鏈中的這個鏈接涉及識別與自然語言查詢相關的、與計算運行無關的所有字段名。例如，并非所有具有預測的數據集都以“predictions”的名稱存儲這些標簽。根據個人、數據集和應用程序的不同，預測可能存儲在名為“pred”、“resnet”、“fine-tuned”、“predictions_05_16_2023”或完全其他的字段中。

此任務的示例包括查詢、數據集中所有字段的名稱和類型以及相關字段的名稱：

Query: "Exclude model2 predictions from all samples"
Available fields: "[id: string, filepath: string, tags: list, ground_truth: Detections, model1_predictions: Detections, model2_predictions: Detections, model3_predictions: Detections]"
Required fields: "[model2_predictions]"

相關類名

對于分類和檢測等標簽字段，將自然語言查詢轉換為Python代碼需要使用數據集中實際類的名稱。為了實現這一點，我讓GPT-3.5為輸入查詢中的標簽類執行命名實體識別。

在查詢“samples with at least one cow prediction and no horses”（至少有一個奶牛預測而沒有馬的樣本）中，模型的工作是識別“馬”（horse）和“牛”（cow）。然后將這些識別的名稱與前一步中選擇的標簽字段的類名進行比較——首先區分大小寫，然后不區分大小寫。

如果在數據集中的命名實體和類名之間沒有找到匹配，我們就回到語義匹配：“"people" → "person", "table" → "dining table", and "animal" → [“cat”, “dog", “horse", …]。

每當匹配不相同時，我們使用匹配類的名稱來更新傳遞到最后推理步驟的查詢：

query: "20 random images with a table"
## becomes:
query: "20 random images with a dining table"

ViewStage推理

一旦做出了所有這些選擇，類似的示例、相關描述和相關數據集信息（選定的算法運行、字段和類）將與（可能修改的）查詢一起傳遞到模型中。

我們沒有像最初那樣指示模型以dataset.view1（）.view2（）…viewn（）等的形式向我返回代碼，而是不再搜索數據集部分，要求模型以列表的形式返回ViewStages。當時，我很驚訝地看到這樣的操作居然提高了性能。事后看來，這樣安排符合這樣一種觀點，即你把任務分解得越多，LLM就能做得越好。

實際應用

創建一個基于LLM技術的程序是一件很酷的事情，但將相同的內核變成LLM技術支持的應用程序更酷得多。以下是我們開發此應用程序的簡要概述。

單元測試

當我們將其從原理驗證轉變為穩健的工程系統時，我們使用單元測試來對管道進行壓力測試并確定薄弱環節。鏈中鏈接的模塊化特征意味著，每個步驟都可以單獨進行單元測試、驗證和迭代，而無需運行整個鏈。

這樣的技術會導致更快的改進，因為一個提示工程團隊中的不同個人或團隊可以并行處理鏈中的不同環節。此外，它還降低了成本，因為理論上，您只需要運行LLM推理的單個步驟即可優化鏈中的單個環節。

評估LLM生成的代碼

我們使用Python的eval（）函數將GPT-3.5的響應轉換為DatasetView。然后，我們設置FiftyOne應用程序會話的狀態以顯示視圖。

輸入驗證

垃圾輸入→垃圾輸出。為了避免這種情況，我們運行驗證以確保用戶的自然語言查詢是合理的。

首先，我們使用OpenAI的審核端點。然后，我們將任何提示分類為以下四種情況之一：

1.明智而完整：提示可以合理地翻譯成用于查詢數據集的Python代碼。

All images with dog detections（檢測到狗的所有圖像）。

2.明智但不完整：提示是合理的，但如果沒有其他信息，就無法轉換為DatasetView。例如，如果我們有兩個模型對我們的數據進行了預測，那么以下僅引用“my model（我的模型）”的提示是不夠的：

Retrieve my model’s incorrect predictions（檢索我的模型中的錯誤預測）。

3.超出范圍：我們正在構建一個應用程序，將查詢的視圖生成為計算機視覺數據集。雖然底層GPT-3.5模型是通用LLM，但我們的應用程序不應變成一個數據集附近斷開連接的ChatGPT會話。以下提示應該被取消：

Explain quantum computing like I’m five（像我是五歲孩子一樣解釋量子計算）。

4.不明智：給定一個隨機字符串，嘗試生成數據集的視圖是沒有意義的——從哪里開始？！

Azlsakjdbiayervbg。

在嘗試將用戶的輸入查詢轉換為一系列視圖階段之前，我們將輸入與驗證說明和示例一起傳遞到模型中。根據響應，我們要么提示用戶提供更多信息或更合理的查詢，要么繼續數據集視圖生成管道。

總結

VoxelGPT正在運行（視頻由作者提供）

一個簡單的想法導致產生了一個瘋狂的想法，而這段旅程將這個瘋狂的想法帶到了生活中。憑借提示工程、一些真正的軟件工程技術和一系列的技術黑魔法，我們的小團隊創建了一個LLM驅動的應用程序，將自然語言查詢轉換為計算機視覺數據集的過濾視圖。

要點很簡單：定義任務，用規則指導，限制范圍，簡化，選擇統一性，分解問題，并保持相關性。

當我們把所有的部分放在一起時，它看起來是這樣的：

1. 驗證查詢
2. 查找類似的示例
3. 檢索相關文檔
4. 識別潛在的算法/計算
5. 選擇最有可能運行的算法
6. 確定在查詢中訪問/使用哪些字段（屬性）
7. 推斷每個標簽字段的類名
8. 生成用于查詢的視圖階段列表
9. 組合視圖階段并將篩選后的視圖返回到數據集中
10. 成功

需要說明的是，VoxelGPT遠非一款完美的應用程序，但這從來都不是目標。每一步都有改進的空間，更不用說更多的例子了！您還可以將此作為構建計算機視覺任務的AutoGPT風格委托器的基礎來使用。

最后，歡迎對VoxelGPT提供您的任何貢獻。它是免費和開源的！

譯者介紹

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

原文標題：How I Turned ChatGPT into an SQL-Like Translator for Image and Video Datasets，作者：Jacob Marks