GPT-4o Mini là mô hình mới nhất và hiệu quả nhất về chi phí từ OpenAI, và đây là một trong những mô hình có hiệu suất tốt nhất trong phạm vi giá cả của nó. Tuy nhiên, câu hỏi vẫn còn: mô hình này có tốt cho việc tạo ra các tác nhân, đặc biệt là các tác nhân Retrieval-Augmented Generation (RAG) không?

Trong phần này, chúng tôi sẽ khám phá hiệu suất của GPT-4o Mini so với mô hình Anthropic Cloud 3.5 Sonnet, một lựa chọn phổ biến cho RAG có tính chất tác nhân. Chúng tôi sẽ sử dụng một tập dữ liệu thực tế, tập dữ liệu nhúng Airbnb từ MongoDB, để kiểm tra khả năng của các mô hình này.

Tập dữ liệu chứa các cột siêu dữ liệu khác nhau, và chúng tôi sẽ tiền xử lý dữ liệu để tạo đầu vào phù hợp cho đường ống RAG. Chúng tôi sẽ sử dụng Llama Index để thiết lập triển khai RAG, tận dụng khả năng tác nhân của nó.

Để bắt đầu, trước tiên chúng ta cần thiết lập các thư viện và biến môi trường cần thiết. Chúng tôi sẽ cài đặt các gói cần thiết, bao gồm Llama Index, OpenAI và ChromaDB.

Tiếp theo, chúng tôi sẽ cấu hình các biến môi trường, bao gồm khóa API OpenAI và token Hugging Face (nếu cần).

Chúng tôi sau đó sẽ thiết lập mô hình LLM (Language Model) và mô hình nhúng. Đối với LLM, chúng tôi sẽ sử dụng mô hình GPT-4 OM Mini. Đối với các nhúng, chúng tôi sẽ sử dụng mô hình nhúng văn bản nhỏ OpenAI TextEmbedding3, cho phép chúng tôi tùy chỉnh kích thước nhúng để giảm chi phí tính toán và lưu trữ.

Sau khi thiết lập các mô hình, chúng tôi sẽ chuyển sang việc tải và xử lý dữ liệu. Chúng tôi sẽ sử dụng tập dữ liệu nhúng Airbnb từ MongoDB, tập trung vào 2.000 điểm dữ liệu ban đầu để giữ thời gian xử lý và chi phí ở mức quản lý được.

Để nhúng tập dữ liệu Airbnb, trước tiên chúng tôi chuyển đổi tập dữ liệu thành một danh sách các tài liệu JSON. Sau đó, chúng tôi tạo một mẫu siêu dữ liệu bao gồm các thông tin quan trọng như tên danh mục Airbnb, tóm tắt, quy tắc nhà, loại tài sản, loại phòng, loại phòng ngủ, số phòng ngủ và số giường. Siêu dữ liệu này được thêm vào văn bản sẽ được nhúng.

Tiếp theo, chúng tôi chia văn bản thành các đoạn có 5.000 ký tự để đảm bảo rằng mỗi vector nhúng có thể nắm bắt được thông tin liên quan. Sau đó, chúng tôi tính toán các nhúng bằng cách sử dụng mô hình nhúng văn bản nhỏ OpenAI TextEmbedding3, cho phép chúng tôi tùy chỉnh kích thước nhúng để giảm chi phí tính toán và lưu trữ.

Sau khi tính toán các nhúng, chúng tôi lưu trữ chúng trong một vector store ChromaDB, sẽ phục vụ như cơ sở kiến thức cho tác nhân của chúng tôi. Chúng tôi tạo một QueryEngineToolClass sẽ cung cấp cho tác nhân quyền truy cập vào vector store, cho phép nó truy xuất các đoạn văn bản liên quan nhất dựa trên truy vấn của người dùng.

Để tạo tác nhân worker, trước tiên chúng tôi định nghĩa các công cụ sẽ có sẵn cho tác nhân. Trong trường hợp này, chúng tôi sử dụng lớp QueryEngineToolV2 từ Llama Index, cung cấp quyền truy cập vào vector store mà chúng tôi đã tạo trước đó.

query_engine_tool = QueryEngineToolV2(
    "Knowledge base",
    "Cung cấp thông tin về các danh mục và đánh giá Airbnb, sử dụng một câu hỏi văn bản đơn giản và chi tiết làm đầu vào cho công cụ.",
    self.vector_store
)
tools = [query_engine_tool]

Tiếp theo, chúng tôi tạo tác nhân worker bằng cách sử dụng lớp FunctionCallingAgentWorker từ Llama Index. Chúng tôi cung cấp danh sách các công cụ và mô hình ngôn ngữ (GPT-4 Mini trong trường hợp này) cho tác nhân worker.

agent_worker = FunctionCallingAgentWorker(
    tools,
    self.llm,
    verbose=True
)
self.agent = agent_worker

Bây giờ, chúng tôi có thể sử dụng hàm chat của tác nhân để tương tác với nó. Chúng tôi có thể cung cấp lời nhắc cho tác nhân, và nó sẽ sử dụng các công cụ để tạo ra một phản hồi.

Trong phần này, chúng tôi so sánh hiệu suất của GPT-4o Mini và Cloud 3.5 Sonnet làm tác nhân trong một luồng công việc RAG (Retrieval Augmented Generation) thực tế bằng cách sử dụng tập dữ liệu nhúng Airbnb từ MongoDB.

Các phát hiện chính là:

1. GPT-4o Mini làm tác nhân: Mặc dù GPT-4o Mini là một mô hình có khả năng, nhưng nó gặp khó khăn với luồng công việc tác nhân. Quá trình suy nghĩ của mô hình không được diễn đạt tốt, và các phản hồi thiếu mức độ chi tiết và chính xác mà người dùng mong đợi từ một tác nhân hiệu quả.

2. Cloud 3.5 Sonnet làm tác nhân: Ngược lại, Cloud 3.5 Sonnet thể hiện hiệu suất vượt trội làm tác nhân. Nó viết lại các lời nhắc một cách hiệu quả, sử dụng công cụ cơ sở kiến thức để thu thập thông tin liên quan, và cung cấp các phản hồi chi tiết và chính xác, ngay cả khi cơ sở kiến thức không có thông tin cụ thể về chủ đề được yêu cầu.

3. Tầm quan trọng của các mô hình LLM mạnh mẽ đối với các luồng công việc tác nhân: So sánh này nhấn mạnh tầm quan trọng của việc sử dụng một mô hình LLM mạnh mẽ và có khả năng hơn, như Cloud 3.5 Sonnet, cho các luồng công việc tác nhân. Khả năng của tác nhân trong việc hiểu ngữ cảnh, viết lại các lời nhắc và tạo ra các phản hồi chất lượng cao là rất quan trọng để hoàn thành nhiệm vụ hiệu quả và tương tác với người dùng.

So sánh giữa GPT-4o Mini và Anthropic's Cloud 3.5 Sonnet cho các nhiệm vụ RAG (Retrieval Augmented Generation) có tính chất tác nhân nhấn mạnh tầm quan trọng của khả năng mô hình khi thiết kế các luồng công việc dựa trên tác nhân. Trong khi GPT-4o Mini là một mô hình có khả năng và hiệu quả về chi phí, nó lại thiếu trong các khía cạnh tác nhân của nhiệm vụ, như được thể hiện qua việc viết lại lời nhắc đơn giản và các phản hồi ít chi tiết hơn của nó.

Ngược lại, mô hình Anthropic Cloud 3.5 Sonnet thể hiện một hành vi tác nhân mạnh mẽ và tinh vi hơn. Nó hiệu quả trong việc viết lại các lời nhắc, thu thập thông tin liên quan từ cơ sở kiến thức và cung cấp các phản hồi chi tiết và sâu sắc, ngay cả khi phải đối mặt với một truy vấn về một địa điểm không có trong tập dữ liệu.

So sánh này nhấn mạnh sự cần thiết phải xem xét cẩn thận khả năng của mô hình khi thiết kế các luồng công việc dựa trên tác nhân. Trong khi GPT-4o Mini có thể phù hợp với một số nhiệm vụ, các ứng dụng tác nhân phức tạp hơn có thể yêu cầu sử dụng một mô hình mạnh mẽ và chuyên biệt hơn, như Anthropic Cloud 3.5 Sonnet, để đạt được mức độ hiệu suất và trải nghiệm người dùng mong muốn.