Giới thiệu

Khi lần đầu tiên tôi đọc bài viết "Xây dựng và Tối ưu hóa Hệ thống RAG Đa tác nhân với DSPy và GEPA" của Isaac Kargar, tôi đã bị ấn tượng bởi tính thực tiễn và sự cụ thể của hướng dẫn này. Bài viết dẫn dắt người đọc qua việc sử dụng DSPy để xây dựng các tác nhân (subagents) chuyên biệt trong các lĩnh vực khác nhau (ví dụ: tiểu đường, COPD), tối ưu hóa chúng với GEPA (một bộ tối ưu hóa tiến hóa phản hồi), và sau đó lắp ráp một tác nhân chính. Trong công việc gần đây của tôi liên quan đến việc xây dựng các pipeline RAG (Tạo ra thông tin Tăng cường Tìm kiếm), việc áp dụng nhiều bài học từ bài viết này đã cải thiện đáng kể độ chính xác và tính ổn định.

Trong bài viết này, tôi sẽ chia sẻ kinh nghiệm của mình khi tái hiện và mở rộng một số phần của công việc đó, những cạm bẫy mà tôi gặp phải, cùng với những điều mới mẻ trong lĩnh vực nghiên cứu tính đến cuối năm 2025. Nếu bạn đang có kế hoạch xây dựng hệ thống RAG đa tác nhân, tôi tin rằng bạn sẽ tìm thấy một số điểm đáng chú ý trong những gì tôi chia sẻ dưới đây.

Tóm tắt: Cài đặt DSPy + GEPA

Đầu tiên, hãy cùng ôn lại một chút để thiết lập bối cảnh:

DSPy là một framework khai báo để kết hợp các module LM, công cụ, tác nhân, v.v. Nó cho phép bạn viết các "module" (subagents, công cụ bọc, module ReAct, v.v.) có cấu trúc hơn thay vì chỉ đơn thuần là kỹ thuật prompt.
GEPA (Bộ tối ưu hóa Prompt Genetic-Pareto) là một bộ tối ưu hóa chính trong DSPy. Nó sử dụng các ý tưởng tiến hóa và phản hồi phản xạ (thông qua một "LM phản xạ" mạnh hơn) để phát triển các thành phần prompt. Nó vượt trội hoặc cạnh tranh với các bộ tối ưu hóa prompt cũ hơn và các phương pháp dựa trên RL trong nhiều ngữ cảnh.

Trong hướng dẫn của Kargar, hai subagents được xây dựng: một chuyên về bệnh tiểu đường và một về COPD; mỗi subagent có công cụ tìm kiếm vector riêng cho các tài liệu đặc thù về bệnh. Mô hình ReAct được sử dụng. Sau đó, mỗi tác nhân được tối ưu hóa (thông qua GEPA) bằng cách sử dụng một tập dữ liệu các cặp QA, và cuối cùng, một tác nhân chính điều phối giữa các subagents. Hướng dẫn cho thấy sự gia tăng đáng kể trong các chỉ số đánh giá sau khi sử dụng GEPA.

Những gì tôi đã thử: Mở rộng / Điều chỉnh

Trong các thử nghiệm gần đây, tôi đã theo một kiến trúc tương tự, nhưng trong một lĩnh vực mới (các tài liệu pháp lý + hướng dẫn quy định). Dưới đây là những điều tôi đã thử và bài học tôi đã học được:

1. Cài đặt Công cụ Tìm kiếm Đặc thù

Việc xây dựng các công cụ tìm kiếm vector mạnh mẽ là rất quan trọng. Trong trường hợp ban đầu, các tài liệu về bệnh lý được cấu trúc tốt và khá sạch sẽ. Trong lĩnh vực của tôi, các văn bản pháp lý thường nhiễu, có các tham chiếu chéo và các thuật ngữ mơ hồ. Tôi nhận thấy rằng:
- Mô hình nhúng tốt hơn (được tinh chỉnh hoặc thích ứng với miền) dẫn đến cải thiện cách mà subagent truy xuất các tài liệu liên quan.
- Sử dụng lọc metadata (ví dụ: ngày tháng, thẩm quyền) trước hoặc trong quá trình truy xuất giúp giảm thiểu nhiễu.

2. Thiết kế Prompt & Hướng dẫn cho Subagents ReAct

Các hướng dẫn được đưa ra cho các tác nhân (những gì họ có và công cụ nào họ có) và cấu trúc "suy nghĩ / lựa chọn công cụ" của họ có tác động rất lớn đến hành vi. Trong công việc của Kargar, mẫu của tác nhân ReAct bao gồm các marker next_thought, next_tool_name, next_tool_args, finish markers, v.v.
Trong các thử nghiệm của tôi, tôi phát hiện rằng:
- Việc làm rõ những gì được coi là một "cuộc gọi công cụ tốt" là rất hữu ích. Ví dụ: yêu cầu tác nhân "giải thích tại sao bạn chọn công cụ này" (hoặc bao gồm một bước lý luận) đôi khi giúp tránh được các tìm kiếm vô dụng hoặc thừa thãi.
- Cung cấp một vài ví dụ (ngay cả khi là giả lập) trong quá trình tối ưu hóa prompt giúp GEPA nhanh chóng hiểu cách mà các truy vấn nên ánh xạ đến việc truy xuất hoặc hoàn thành. Tuy nhiên, quá nhiều ví dụ có thể "quá tải" prompt và làm chậm suy luận hoặc giảm khả năng tổng quát.

3. Tinh chỉnh GEPA

GEPA có một số thông số có thể điều chỉnh. Từ những gì tài liệu cho thấy:
- Bạn có thể chọn chế độ tự động (nhẹ / vừa / nặng), cài đặt max_full_evals, reflection_lm, chiến lược lựa chọn ứng viên, v.v.
- Lựa chọn reflection LM là rất quan trọng: một mô hình mạnh mẽ hơn cung cấp phản hồi hữu ích hơn, nhưng cũng tốn kém hơn.
Trong lĩnh vực của tôi, việc sử dụng một reflection LM nhỏ hơn (để tiết kiệm chi phí) đôi khi tạo ra phản hồi quá chung chung; nhưng việc sử dụng một mô hình lớn hơn đôi khi đã khắc phục điều đó. Tuy nhiên, có một điểm mà lợi ích giảm dần.

4. Tối ưu hóa Chung vs Pipeline

Một điều mà hướng dẫn của Kargar thực hiện là tối ưu hóa các subagents riêng biệt, sau đó là tác nhân chính. Trong công việc của tôi, tôi nhận thấy rằng việc tối ưu hóa pipeline một cách toàn diện (tác nhân chính + subagents cùng nhau, với các câu hỏi hỗn hợp buộc phải phối hợp) đôi khi để lại các chế độ thất bại ẩn. Ví dụ, các subagents có thể hoạt động tốt riêng lẻ, nhưng tác nhân chính không thể quyết định đúng đắn nên sử dụng cái nào trong các truy vấn trừu tượng hoặc mơ hồ.
Vì vậy, tôi khuyên bạn nên bao gồm các tập dữ liệu "hỗn hợp / chung" trong quá trình tối ưu hóa, không chỉ là các truy vấn "thuần túy" của miền, để đánh giá tác nhân chính. Kargar làm điều gì đó tương tự khi kết hợp các tập dữ liệu phụ.

Những điều mới / Nghiên cứu liên quan gần đây (giữa năm 2025)

Để biết lĩnh vực này đang đi về đâu, dưới đây là một vài công trình và xu hướng gần đây liên quan chặt chẽ. Một số xác nhận các phần của cách tiếp cận DSPy+GEPA; những cái khác gợi ý những điều mở rộng hoặc những điều cần chú ý:

MAO-ARAG: Tổ chức Đa tác nhân cho RAG Thích ứng (Tháng 8 năm 2025). Công trình này giới thiệu một tác nhân lập kế hoạch chọn lựa giữa các tác nhân thực thi (như cải tiến truy vấn, chọn tài liệu, tạo nội dung) tùy thuộc vào truy vấn, cân bằng chất lượng và chi phí. Điều này tương tự về mặt tinh thần với việc có một tác nhân chính; cho thấy rằng khả năng thích ứng (quyết định luồng công việc động theo từng truy vấn) mang lại sự cân bằng tốt.
Maestro: Tối ưu hóa Đồ thị và Cấu hình Chung cho Tác nhân AI Đáng tin cậy (Tháng 9 năm 2025). Maestro không chỉ dừng lại ở việc tối ưu hóa prompt: nó tìm kiếm cả cách mà các module được kết nối (cấu trúc đồ thị) và cách mỗi module được cấu hình. Trong các bài kiểm tra tiêu chuẩn, nó cải thiện GEPA hoặc GEPA+Merge. Điều này gợi ý rằng bên cạnh việc tối ưu hóa các prompt, việc xem xét lại cấu trúc của đồ thị đa tác nhân của bạn (các tác nhân nào tồn tại, chúng giao tiếp như thế nào) có thể mở khóa những lợi ích thêm nữa.
ReSo: Hệ thống Đa tác nhân dựa trên LLM tự tổ chức theo phần thưởng. Công trình này tập trung vào tính linh hoạt và khả năng mở rộng: cho phép các tác nhân tự tổ chức (chọn trách nhiệm) và tạo ra các tín hiệu phần thưởng chi tiết. Nó chỉ ra một xu hướng đang gia tăng: chuyển từ các hệ thống đa tác nhân được thiết kế thủ công + tinh chỉnh prompt sang các hệ thống có khả năng thích ứng tự động hơn.

Những điều này và nhiều điều khác có nghĩa là trong khi GEPA + DSPy là những công cụ tuyệt vời hiện nay, ranh giới đang chuyển sang cấu trúc chung + luồng công việc động + tín hiệu phản hồi hiệu quả.

Những cạm bẫy và điều cần cẩn thận

Từ công việc thực tế của tôi (và đọc) tôi muốn chia sẻ những điều đã khiến tôi gặp khó khăn (để bạn không lặp lại):

Quá khớp với tập dữ liệu prompt: Nếu tập hợp đánh giá hoặc phát triển của bạn quá giống nhau hoặc hẹp, GEPA tối ưu hóa các prompt hoạt động tốt ở đó nhưng thất bại trong việc sử dụng thực tế bên ngoài.
Chi phí & độ trễ: Sử dụng các LM phản xạ lớn, nhiều lần đánh giá hoàn chỉnh, hoặc chế độ ngân sách nặng của GEPA có thể khiến pipeline trở nên tốn kém. Ngoài ra, kích thước prompt lớn (do nhiều ví dụ hoặc mô tả công cụ lớn) làm chậm quá trình suy luận.
Chất lượng theo dõi & phản hồi: GEPA phụ thuộc vào những dấu vết phong phú (những gì tác nhân đã làm từng bước), và các chỉ số phản hồi có ý nghĩa. Nếu những điều này yếu (ví dụ: chỉ số chính xác vô hướng), bộ tối ưu hóa có thể đưa ra các cải tiến "an toàn" nhưng tối thiểu thay vì giải quyết các chế độ thất bại thực sự.
Giới hạn của cấu trúc đồ thị: Nếu kiến trúc của hệ thống của bạn (các tác nhân nào, công cụ nào, cái gì được cho phép) quá bị ràng buộc, việc tối ưu hóa prompt một mình có thể không khắc phục được các vấn đề. Ví dụ, giả sử tác nhân chính chỉ có thể gọi subagent A hoặc B nhưng đôi khi điều cần thiết là một loại subagent mới; không có kỹ thuật nào cho việc điều chỉnh prompt sẽ giúp.

Khuyến nghị / Thực hành tốt nhất

Tổng hợp tất cả lại, đây là những khuyến nghị của tôi nếu bạn đang xây dựng các hệ thống RAG đa tác nhân và sử dụng DSPy+GEPA (hoặc có kế hoạch sử dụng):

Bắt đầu với tính mô-đun: thiết kế các subagents xung quanh miền hoặc chức năng ngay từ đầu, với các giao diện công cụ rõ ràng.
Chuẩn bị dữ liệu huấn luyện / phát triển đa dạng: bao gồm cả các truy vấn "thuần túy miền", các truy vấn chéo miền hoặc mơ hồ và các truy vấn hỗn hợp thử thách phối hợp.
Chọn một LM phản xạ đủ mạnh cho GEPA, cân bằng với chi phí. Có thể bắt đầu với chế độ nhẹ, sau đó chuyển sang chế độ nặng hơn khi bạn có một cơ sở.
Lặp lại cấu trúc với cấu hình: đừng giả định rằng đồ thị tác nhân ban đầu của bạn là "đúng" mãi mãi; khám phá các luồng công việc hoặc đồ thị module khác nhau, có thể được truyền cảm hứng từ các công cụ mới hơn như Maestro.
Sử dụng các chỉ số có thể giải thích / phản hồi mà vượt ra ngoài độ chính xác: ví dụ: đánh giá xem tác nhân đã chọn đúng công cụ hay chưa, liệu các truy xuất có liên quan hay không, liệu các bước lý luận có hợp lý hay không. Những điều này giúp bước phản xạ của GEPA.
Giám sát khả năng tổng quát: thử nghiệm trên các truy vấn ngoài miền hoặc của người dùng thực tế để đảm bảo rằng các cải tiến không chỉ là khớp quá mức với tập dữ liệu của bạn.

Kết luận

Hành trình của tôi khi làm việc với những ý tưởng trong bài viết "Xây dựng và Tối ưu hóa Hệ thống RAG Đa tác nhân với DSPy và GEPA" đã củng cố rằng thiết kế prompt có cấu trúc + các vòng phản hồi của bộ tối ưu hóa là rất mạnh mẽ. GEPA, đặc biệt, dường như đạt được điểm ngọt ngào: hiệu quả hơn về mẫu và thường đáng tin cậy hơn so với kỹ thuật prompt ngây thơ hoặc thậm chí một số phương pháp RL, trong khi DSPy cung cấp cho bạn cấu trúc để xây dựng các tác nhân theo cách mô-đun và dễ bảo trì.
Khi lĩnh vực này tiến về phía trước - với các công trình như MAO-ARAG và Maestro - tôi mong rằng các hệ thống sẽ trở nên tốt hơn trong việc thích ứng luồng công việc một cách động, tối ưu hóa cả cấu trúc và các prompt, và thực hiện điều này với ít sự can thiệp của con người hơn. Nếu bạn đang tìm kiếm để khám phá hoặc thử nghiệm sâu hơn, tôi cũng đã tài liệu hóa một phần pipeline của mình (các thí nghiệm trong lĩnh vực pháp lý) chi tiết hơn tại iacommunidad.com - hãy thoải mái kiểm tra nhé.

Bài học và Thực hành Xây dựng Hệ thống RAG Đa tác nhân với DSPy và GEPA