向量儲存管理員與影片專家實作

– 13 分鐘閱讀

在現今混合人工智慧與人類智慧的時代，自動化影片內容的生成、註解和標記變得至關重要。本文將探討如何利用向量儲存管理員和影片專家 AI 代理程式，構建一個自動化管道，將原始影片輸入轉換成結構化、資訊豐富且易於存取的影片內容。此管道分為三個主要階段：首先，生成器代理根據文字創意生成影片內容，並由註解者代理進行描述；接著，向量儲存管理員將生成的註解和後設資料組織並嵌入到可搜尋的向量儲存中，以 Pinecone 作為向量資料函式庫，並使用僅 CPU 的環境進行最佳化；最後，影片專家代理則負責根據使用者輸入增強和標記影片內容，並進行效能評估和指標計算。透過整合 OpenAI GPT-4 等先進的生成式 AI 模型，我們可以實作更精確、高效的影片內容管理。

向量儲存管理員的架構與實作

向量儲存管理員（Vector Store Administrator）AI 代理程式負責執行我們在第六章中實作的任務。本章的新穎之處在於，所有用於 RAG 的資料都是 AI 生成的。讓我們開啟 GitHub 儲存函式庫中的 Pipeline_2_The_Vector_Store_Administrator.ipynb 筆記本。

向量儲存管理員的工作流程

向量儲存管理員的工作流程分為四個步驟，如下圖所示：

  graph LR
    A[處理影片評論] --> B[分塊和嵌入資料集]
    B --> C[建立Pinecone索引]
    C --> D[查詢向量儲存]

圖表翻譯： 此圖表呈現了向量儲存管理員的工作流程，包括處理影片評論、分塊和嵌入資料集、建立 Pinecone 索引以及查詢向量儲存等四個主要步驟。

  1. 處理影片評論：向量儲存管理員會載入並準備評論以進行分塊，就像第六章的「擴充套件 Pinecone 索引（向量儲存）」部分一樣。由於我們一次處理一個影片，因此係統會刪除已處理的檔案，以保持磁碟空間的穩定。
  2. 分塊和嵌入資料集：資料集的欄位名稱（‘ID’、‘FrameNumber’、‘Comment’、‘FileName’）已經由註解員 AI 代理程式在 Pipeline 1 中準備好了。程式使用與第六章「分塊和嵌入資料集」部分相同的功能來分塊和嵌入資料集。
  3. Pinecone 索引：建立 Pinecone 索引並上傳資料，就像第六章的「建立 Pinecone 索引」和「上傳資料」部分一樣。
  4. 查詢向量儲存：這遵循與第六章相同的流程。但是，在這種情況下，檢索是混合的，使用 Pinecone 向量儲存和單獨的檔案系統來儲存影片和影片幀。

查詢 Pinecone 索引

在 GitHub 的筆記本中，步驟 4：查詢 Pinecone 索引實作了函式，以找到與使用者輸入相匹配的評論，並追溯到影片的幀。這導致了影片來源和幀的顯示。我們可以從我們想要的位置顯示影片和幀。

程式碼實作

k = 1  # 結果數量
query_text = "Find a basketball player that is scoring with a dunk."
query_embedding = get_embedding(query_text, model=embedding_model)

內容解密：

  • k 變數定義了我們要檢索的結果數量。
  • query_text 變數定義了查詢文字，這是一個相當困難的查詢。
  • get_embedding 函式用於將查詢文字嵌入到向量空間中，以便與資料集進行相似度搜尋。
query_results = index.query(vector=query_embedding, top_k=k, include_metadata=True)
for match in query_results['matches']:
    print(f"ID: {match['id']}, Score: {match['score']}")
    metadata = match['metadata']
    text = metadata.get('text', "No text metadata available.")
    frame_number = metadata.get('frame_number', "No frame number available.")
    file_name = metadata.get('file_name', "No file name available.")
    print(f"Text: {text}")
    print(f"Frame Number: {frame_number}")
    print(f"File Name: {file_name}")

內容解密：

  • index.query 函式用於執行相似度搜尋，檢索與查詢向量最相似的 k 個結果。
  • query_results 變數包含了查詢結果，包括匹配的 ID、相似度得分和後設資料。
  • 程式碼遍歷了查詢結果，並列印了每個匹配的 ID、相似度得分、評論文字、幀編號和檔案名稱。

管道3：影片專家

OpenAI GPT-4o影片專家的角色是分析由註解者OpenAI LLM代理產生的評論，指出認知失調（描述中不一致的部分），重寫評論並提供標籤。影片專家的工作流程，如下圖所示，也包含了第七章「使用Wikipedia API和LlamaIndex建立可擴充套件的根據知識圖譜的RAG」中計算和顯示指標部分的程式碼。

影片專家的任務

註解者的角色僅僅是描述它所看到的內容。影片專家則需要確保描述有意義，並為影片新增標籤，以便將來在資料集中進行分類別。

圖10.10：影片專家自動動態描述和標籤的工作流程

  1. 連線Pinecone索引：如同管道2中所述的Pinecone索引連線。本次不是插入資料，而是連線到向量儲存。
  2. 定義RAG函式：利用在管道1和管道2中構建的直接函式。
  3. 查詢向量儲存：與管道2中所述的查詢Pinecone索引相同。
  4. 檢索增強生成：最終確定影片專家GPT-4o的主要角色，即分析和改進向量儲存查詢回應。這最後一步包括評估和指標函式。

有多種策略可以用於實作本章探討的影片製作案例，但影片專家扮演著重要的角色。在GitHub上開啟Pipeline_3_The_Video_Expert.ipynb，並轉到步驟2：定義RAG函式中的增強檢索生成部分。

該函式進行了OpenAI GPT-4o的呼叫，與管道1中的註解者類別似。然而，這次LLM的角色有很大不同：

{
  "role": "system",
  "content": "您將獲得從影片中提取的影像幀的評論："
}

對GPT-4o的指令是：

  • 您將獲得從影片中提取的影像幀的評論：這指示LLM分析AI生成的評論。註解者保持中立，描述它所看到的幀。影片專家的角色不同：它需要分析和增強評論。
  1. 指出認知失調：這指示模型找出評論中的矛盾或不一致之處，這些可能源於AI生成影片的方式（影片中的邏輯缺失）。
  2. 以邏輯和吸引人的方式重寫評論：這指示影片專家代理將評論從技術描述改寫為吸引人的描述。
  3. 為該影像提供標籤，例如籃球、足球或其他標籤：這指示模型提供標籤以便將來使用。

在GitHub上的步驟3：查詢向量儲存，重現了對籃球運動員扣籃的查詢和輸出，如管道2所述，並提供了對應的影片和幀。

輸出結果是：

ID=f104138b-0be8-4f4c-bf99-86d0eb34f7ee
score=0.866193652
text=In this image, there is a person who appears to be in the process of dunking a basketball.
frame_number=191
file_name=basketball3.mp4

內容解密：

此輸出包含了由OpenAI LLM（註解者代理）生成的評論、幀編號、對應的影片檔案名稱以及檢索時間。這些資訊可以用於顯示相關的影片和幀。

提供的評論似乎是可以接受的。但是，讓我們看看GPT-4o對它的看法。在GitHub上的步驟4：檢索增強生成部分，將輸出作為使用者提示提交給影片專家代理：

prompt = text
response_content = get_openai_response(prompt)
print(response_content)

輸出提供了影片專家的見解：

  1. 認知失調：
    • 評論多餘地描述了扣籃的動作。
    • 提到“扣籃”一詞疊加在影像上。
    • 對晴朗天空和現代建築的背景細節描述。
  2. 重寫評論：
    • 將提供一個更具邏輯和吸引力的評論版本。
  graph LR;
    A[開始] --> B[連線Pinecone索引];
    B --> C[定義RAG函式];
    C --> D[查詢向量儲存];
    D --> E[檢索增強生成];
    E --> F[輸出結果];

圖表翻譯： 此圖示展示了影片專家的工作流程，從連線Pinecone索引到輸出結果的整個過程。

下載並顯示影片

根據檔案名稱下載影片：

print(file_name)
directory = "Chapter10/videos"
filename = file_name
download(directory, file_name)

然後，使用標準的Python函式顯示它：

def display_video(file_name):
    with open(file_name, 'rb') as file:
        video_data = file.read()
    video_url = b64encode(video_data).decode()
    html = f'''
    <video width="640" height="480" controls>
    <source src="data:video/mp4;base64,{video_url}" type="video/mp4">
    Your browser does not support the video tag.
    </video>
    '''
    return HTML(html)

display_video(file_name)

內容解密：

此段程式碼首先下載指定的影片檔案，然後使用Python函式將其顯示在頁面上。涉及到的步驟包括開啟檔案、讀取資料、將影片資料編碼為base64格式，並建立一個HTML字串以嵌入影片。

顯示相關幀

file_name_root = file_name.split('.')[0]
frame = f"{file_name_root}_{frame_number}.jpg"
directory = '/content/'
file_path = os.path.join(directory, frame)

if os.path.exists(file_path):
    file_size = os.path.getsize(file_path)
    print(f"File '{frame}' exists. Size: {file_size} bytes.")
    if file_size > 1000:
        display(Image(filename=file_path))
    else:
        print("The file size is less than or equal to the logical value.")
else:
    print(f"File '{frame}' does not exist in the specified directory.")

內容解密：

此段程式碼檢查指定的幀檔案是否存在，如果存在且大小合理，則顯示該影像。涉及到的步驟包括檢查檔案路徑、取得檔案大小，並根據大小決定是否顯示影像。

自動化影片生成與標註系統的開發與評估

前言

本章探討了結合人類智慧與人工智慧（AI）技術的混合時代，重點在於建立一個自動化流程來生成、註解和標記影片。透過整合先進的生成式AI模型，我們展示瞭如何構建一個自動化管道，將原始影片輸入轉換為結構化、資訊豐富且易於存取的影片內容。

自動化影片生成管道的建立

管道1：生成器與註解者

我們的旅程始於管道1中的生成器代理（Generator agent），它負責根據文字創意生成影片內容。可以看出，影片生成過程將透過無縫整合創意和描述性增強生成代理繼續擴充套件。

管道2：向量儲存管理員

在管道2中，我們專注於將生成的註解和後設資料組織並嵌入到可搜尋的向量儲存中。在這個管道中，我們強調了使用僅CPU而無GPU來最佳化構建可擴充套件的影片內容函式庫的過程。

管道3：影片專家

最後，在管道3中，我們引入了專家AI代理（Expert AI agent），這是一個設計用來根據使用者輸入增強和標記影片內容的影片專家。我們還實施了評估方法和指標計算。

系統評估與效能分析

評估過程包括執行十個範例，每個範例包含使用者提示、向量儲存查詢傳回的註解、以及由GPT-4o模型（影片專家）增強的註解。每個範例還包含與第7章相同的評估過程。

評估指標

我們使用多種指標來分析系統的效能，包括：

  • 準確性（Accuracy）：平均得分為0.65，表明仍有改進空間。
  • 餘弦相似度（Cosine Similarity）：用於衡量人類反饋註解與AI生成註解之間的相似度。

程式碼解析

# 人類反饋卡片註解
text1 = "This image shows soccer players on a field dribbling an"

# 提取由影片專家重寫的註解
text2 = extract_rewritten_comment(response_content)

# 顯示人類註解和AI重寫的註解
print(f"Human Feedback Comment: {text1}")
print(f"Rewritten Comment: {text2}")

# 計算餘弦相似度
similarity_score3 = calculate_cosine_similarity_with_embeddings(text1, text2)
print(f"Cosine Similarity Score with sentence transformer: {similarity_score3}")
scores.append(similarity_score3)

內容解密：

此段程式碼展示瞭如何比較人類反饋與AI生成的註解。首先，我們定義了人類反饋的註解text1和由AI重寫的註解text2。接著，我們使用calculate_cosine_similarity_with_embeddings函式計算兩者之間的餘弦相似度，以評估AI生成內容的品質。

問答題

  1. AI現在可以自動註解和標記影片嗎？ - 是
  2. 影片處理是否涉及將影片分割成幀？ - 是
  3. 本章的程式是否可以建立一部200分鐘的電影？ - 否
  4. 本章的程式是否需要GPU？ - 否
  5. 影片內容的嵌入向量是否儲存在磁碟上？ - 是
  6. 指令碼是否涉及查詢資料函式庫以檢索資料？ - 是
  7. 指令碼中是否有顯示影像的功能？ - 否
  8. 在任何指令碼中，是否有檢查檔案存在和大小的功能是有用的？ - 是
  9. 這些指令碼是否關注多模態資料？ - 是
  10. 是否有任何指令碼提到AI在現實世界場景中的應用？ - 是

第一章：為什麼需要檢索增強生成（RAG）？

  1. RAG的設計目的是為了提高生成式AI模型的準確性嗎？

    • 是的，RAG透過檢索相關資料來增強生成式AI的輸出。

  2. 一個簡單的RAG組態是否依賴於複雜的資料嵌入？

    • 否，簡單的RAG使用基本的關鍵字搜尋，而不依賴於先進的嵌入技術。

  3. 微調是否總是比使用RAG更好？

    • 否，RAG更適合處理動態、實時資料。

  4. RAG是否在實時從外部來源檢索資料以增強回應？

    • 是的，RAG在查詢處理過程中從外部來源提取資料。

  5. RAG只能應用於根據文字的資料嗎？

    • 否，RAG也適用於文字、影像和音訊資料。

  6. RAG中的檢索過程是由使用者還是自動化輸入觸發的？

    • RAG中的檢索過程通常由查詢觸發，該查詢可以來自使用者或自動化系統。

  7. 餘弦相似度和TF-IDF是否都是先進RAG組態中使用的指標？

    • 是的，這兩種方法都用於評估查詢與檔案之間的相關性。

  8. RAG生態系統是否只包含資料收集和生成元件？

    • 否，它還包括儲存、檢索、評估和訓練。

  9. 先進的RAG組態能否處理多模態資料，如影像和音訊？

    • 是的，先進的RAG支援處理結構化和非結構化的多模態資料。

  10. 人類反饋在評估RAG系統中是否無關緊要？

    • 否，人類反饋對於提高RAG系統的準確性和相關性至關重要。

第二章：使用Deep Lake和OpenAI進行RAG嵌入向量儲存

  1. 嵌入技術是否將文字轉換為高維向量以實作在RAG中更快的檢索？

    • 是的，嵌入技術建立能夠捕捉文字語義含義的向量。

  2. 在檢索詳細語義內容時，關鍵字搜尋是否比嵌入技術更有效？

    • 否，嵌入技術比僵化的關鍵字搜尋更具上下文感知能力。

  3. 是否建議將RAG管道分成獨立的元件？

    • 是，這樣可以實作平行開發和更方便的維護。

  4. RAG管道是否只由兩個主要元件組成？

    • 否，管道由三個主要元件組成：資料收集、嵌入和生成。

  5. Activeloop Deep Lake是否能夠同時處理嵌入和向量儲存？

    • 是，它能夠高效地儲存嵌入以實作快速檢索。

  6. 本章中是否使用了OpenAI的text-embedding-3-small模型來生成嵌入？

    • 是，這個模型因其在細節和計算效率之間的平衡而被選中。

  7. 在RAG驅動的系統中，資料嵌入是否可見並且可以直接追溯？

    • 是，與引數模型不同，RAG中的嵌入可以追溯到其來源。

  8. RAG管道能否在不分割成單獨元件的情況下平穩執行？

    • 將RAG管道分成元件可以提高專業化、可擴充套件性和安全性，從而幫助系統平穩執行。雖然較簡單的RAG系統在沒有明確元件分離的情況下仍可能有效運作，但這並非最佳組態。

  9. 是否有必要將大文字分割成較小的部分以進行嵌入和儲存？

    • 是，分割有助於最佳化嵌入並提高查詢效率。

  10. 餘弦相似度指標是否用於評估檢索資訊的相關性？

    • 是，餘弦相似度有助於衡量檢索資料與查詢的匹配程度。

第三章：使用LlamaIndex、Deep Lake和OpenAI構建根據索引的RAG

  1. 索引是否能夠提高檢索增強生成式AI的精確度和速度？

    • 是，索引使檢索更快、更準確。

  2. 索引能否為RAG輸出提供可追溯性？

    • 是，索引允許追溯到確切的資料來源。

  3. 對於大型資料集，根據索引的搜尋是否比根據向量的搜尋更慢？

    • 否，根據索引的搜尋更快，並針對大型資料集進行了最佳化。

  4. LlamaIndex是否能夠與Deep Lake和OpenAI無縫整合？

    • 是，LlamaIndex、Deep Lake和OpenAI協同工作良好。

  5. 樹、列表、向量和關鍵字索引是否為唯一的索引型別？

    • 否，這些是常見型別，但還存在其他型別的索引。

  6. 關鍵字索引是否依賴於語義理解來檢索資料？

    • 否，它根據關鍵字而不是語義來檢索資料。

  7. LlamaIndex是否能夠自動處理分塊和嵌入？

    • 是，LlamaIndex自動執行這些過程，以便更輕鬆地進行資料管理。

  8. 後設資料增強對於確保RAG生成輸出的可追溯性是否至關重要？

    • 是，後設資料有助於追溯到生成內容的來源。

  9. 是否可以輕鬆地將實時更新應用於根據索引的搜尋系統？

    • 索引通常需要重新索引以進行更新。然而，一些現代索引系統已被設計為能夠更有效地處理實時或近實時的更新。

  10. 本章中是否使用餘弦相似度作為評估查詢準確性的指標？

    • 是，餘弦相似度有助於評估查詢結果的相關性。

第四章：用於無人機技術的多模態模組化RAG

  1. 多模態模組化RAG是否能夠處理不同型別的資料，如文字和影像？

    • 是，它能夠處理多種資料型別，如文字和影像。

  2. 無人機是否僅用於農業監測和航空攝影？

    • 否，無人機還用於救援、交通和基礎設施檢查等領域。

  3. 本章中使用的Deep Lake VisDrone資料集是否僅用於文字資料？

    • 否，它包含標記的無人機影像，而不僅僅是文字。

  4. 是否可以在無人機影像上新增邊界框以識別卡車和行人等物體？

    • 是，邊界框用於標記影像中的物體。

  5. 模組化系統是否能夠同時檢索文字和影像資料以回應查詢？

    • 是，它能夠從文字和影像資料集中檢索並生成回應。

  6. 是否需要構建向量索引來查詢多模態VisDrone資料集？

    • 是，為了高效地檢索多模態資料，需要建立向量索引。

  7. 檢索到的影像是否在沒有新增任何標籤或邊界框的情況下進行處理？

    • 否，影像經過帶有標籤和邊界框的處理。

  8. 多模態模組化RAG效能指標是否僅根據文字回應？

    • 否，它還評估影像分析的準確性。

  9. 本章中描述的多模態系統是否只能處理與無人機相關的資料？

    • 否，它可以適應其他行業和領域。

  10. 在多模態RAG中，評估影像是否與評估文字一樣容易？

    • 否，影像評估更為複雜，需要專門的指標。
玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。