Consilium- Khi Nhiều LLM Cộng Tác
Bài viết này thảo luận về Consilium, một phương pháp tiếp cận trong đó nhiều LLM hợp tác để cải thiện hiệu suất.
- 11 min read
Consilium: Khi Nhiều LLM Cộng Tác
Hãy hình dung: bốn chuyên gia AI ngồi quanh một bàn poker, tranh luận về những quyết định khó khăn nhất của bạn trong thời gian thực. Đó chính xác là những gì Consilium, nền tảng đa LLM mà tôi đã xây dựng trong Gradio Agents & MCP Hackathon, thực hiện. Nó cho phép các mô hình AI thảo luận về các câu hỏi phức tạp và đạt được sự đồng thuận thông qua tranh luận có cấu trúc.
Nền tảng này hoạt động cả dưới dạng giao diện Gradio trực quan và máy chủ MCP (Model Context Protocol) tích hợp trực tiếp với các ứng dụng như Cline (Claude Desktop gặp sự cố vì không thể điều chỉnh thời gian chờ). Ý tưởng cốt lõi luôn là về việc LLM đạt được sự đồng thuận thông qua thảo luận; đó là nơi tên gọi Consilium xuất phát. Sau đó, các chế độ quyết định khác như bỏ phiếu đa số và lựa chọn xếp hạng đã được thêm vào để làm cho sự cộng tác trở nên tinh vi hơn.
Từ Ý Tưởng Đến Kiến Trúc
Đây không phải là ý tưởng hackathon ban đầu của tôi. Ban đầu, tôi muốn xây dựng một máy chủ MCP đơn giản để nói chuyện với các dự án của tôi trong RevenueCat. Nhưng tôi đã xem xét lại khi nhận ra rằng một nền tảng đa LLM, nơi các mô hình này thảo luận về các câu hỏi và trả lại các câu trả lời có lý lẽ tốt sẽ hấp dẫn hơn nhiều.
Thời điểm hóa ra lại hoàn hảo. Ngay sau cuộc thi hackathon, Microsoft đã công bố AI Diagnostic Orchestrator (MAI-DxO) của họ, về cơ bản là một hội đồng bác sĩ AI với các vai trò khác nhau như “Dr. Challenger Agent” chẩn đoán bệnh nhân lặp đi lặp lại. Trong thiết lập của họ với OpenAI o3, họ đã giải quyết chính xác 85,5% các trường hợp chuẩn y chẩn đoán y tế, trong khi các bác sĩ thực hành chỉ đạt được độ chính xác 20%. Điều này xác nhận chính xác những gì Consilium chứng minh: nhiều quan điểm AI cộng tác có thể vượt trội hơn đáng kể so với phân tích riêng lẻ.
Sau khi quyết định ý tưởng, tôi cần một thứ gì đó vừa hoạt động như một máy chủ MCP vừa là một bản demo không gian Hugging Face hấp dẫn. Ban đầu, tôi đã cân nhắc sử dụng thành phần Gradio Chat tiêu chuẩn, nhưng tôi muốn bài dự thi của mình nổi bật. Ý tưởng là đặt các LLM quanh một chiếc bàn trong phòng họp với các bong bóng thoại, điều này sẽ nắm bắt cuộc thảo luận hợp tác đồng thời làm cho nó trở nên hấp dẫn về mặt hình ảnh. Vì tôi không thể tạo kiểu cho một chiếc bàn tiêu chuẩn một cách độc đáo để nó thực sự được công nhận là một chiếc bàn, nên tôi đã chọn một bàn tròn theo phong cách poker. Cách tiếp cận này cũng cho phép tôi gửi đến hai đường đua hackathon bằng cách xây dựng một thành phần Gradio tùy chỉnh và máy chủ MCP.
Xây Dựng Nền Tảng Trực Quan
Thành phần Gradio tùy chỉnh đã trở thành trung tâm của bài dự thi; bàn tròn theo phong cách poker, nơi những người tham gia ngồi và hiển thị các bong bóng thoại hiển thị phản hồi, trạng thái suy nghĩ và các hoạt động nghiên cứu của họ đã ngay lập tức thu hút sự chú ý của bất kỳ ai ghé thăm không gian. Quá trình phát triển thành phần diễn ra cực kỳ suôn sẻ nhờ trải nghiệm nhà phát triển tuyệt vời của Gradio, mặc dù tôi đã gặp phải một khoảng trống tài liệu xung quanh việc xuất bản PyPI, điều này đã dẫn đến đóng góp đầu tiên của tôi cho dự án Gradio.
# Tích hợp thành phần trực quan
roundtable = consilium_roundtable(
label="AI Expert Roundtable",
label_icon="https://huggingface.co/front/assets/huggingface_logo-noborder.svg",
value=json.dumps({
"participants": [],
"messages": [],
"currentSpeaker": None,
"thinking": [],
"showBubbles": [],
"avatarImages": avatar_images
})
)
Thiết kế trực quan đã chứng tỏ sự mạnh mẽ trong suốt cuộc thi hackathon; sau khi triển khai ban đầu, chỉ các tính năng như hình đại diện do người dùng xác định và văn bản bàn trung tâm được thêm vào, trong khi mô hình tương tác cốt lõi vẫn không thay đổi.
Nếu bạn quan tâm đến việc tạo thành phần Gradio tùy chỉnh của riêng mình, bạn nên xem Custom Components in 5 minutes và vâng, tiêu đề không nói dối; nó thực sự chỉ mất 5 phút cho thiết lập cơ bản.
Quản Lý Trạng Thái Phiên
Bàn tròn trực quan duy trì trạng thái thông qua một hệ thống từ điển dựa trên phiên, trong đó mỗi người dùng nhận được bộ nhớ trạng thái cô lập thông qua user_sessions[session_id]. Đối tượng trạng thái cốt lõi theo dõi các mảng participants, messages, currentSpeaker, thinking và showBubbles được cập nhật thông qua các lệnh gọi lại update_visual_state(). Khi các mô hình đang suy nghĩ, nói hoặc nghiên cứu đang được thực hiện, công cụ sẽ đẩy các bản cập nhật trạng thái tăng dần lên giao diện người dùng bằng cách thêm vào mảng tin nhắn và chuyển đổi trạng thái diễn giả/suy nghĩ, tạo ra luồng hình ảnh thời gian thực mà không cần các máy trạng thái phức tạp - chỉ các đột biến trạng thái JSON trực tiếp được đồng bộ hóa giữa xử lý phụ trợ và kết xuất giao diện người dùng.
Làm Cho LLM Thực Sự Thảo Luận
Trong khi triển khai, tôi nhận ra rằng không có cuộc thảo luận thực sự nào xảy ra giữa các LLM vì chúng thiếu các vai trò rõ ràng. Chúng nhận được toàn bộ ngữ cảnh của các cuộc thảo luận đang diễn ra nhưng không biết cách tham gia một cách có ý nghĩa. Tôi đã giới thiệu các vai trò khác biệt để tạo ra các động lực tranh luận hiệu quả và sau một vài chỉnh sửa, chúng đã kết thúc như thế này:
self.roles = {
'standard': "Provide expert analysis with clear reasoning and evidence.",
'expert_advocate': "You are a PASSIONATE EXPERT advocating for your specialized position. Present compelling evidence with conviction.",
'critical_analyst': "You are a RIGOROUS CRITIC. Identify flaws, risks, and weaknesses in arguments with analytical precision.",
'strategic_advisor': "You are a STRATEGIC ADVISOR. Focus on practical implementation, real-world constraints, and actionable insights.",
'research_specialist': "You are a RESEARCH EXPERT with deep domain knowledge. Provide authoritative analysis and evidence-based insights.",
'innovation_catalyst': "You are an INNOVATION EXPERT. Challenge conventional thinking and propose breakthrough approaches."
}
Điều này đã giải quyết vấn đề thảo luận nhưng lại đặt ra một câu hỏi mới: làm thế nào để xác định sự đồng thuận hoặc xác định lập luận mạnh nhất? Tôi đã triển khai một hệ thống nhà phân tích chính, nơi người dùng chọn một LLM để tổng hợp kết quả cuối cùng và đánh giá xem có đạt được sự đồng thuận hay không.
Tôi cũng muốn người dùng kiểm soát cấu trúc giao tiếp. Ngoài chia sẻ toàn bộ ngữ cảnh mặc định, tôi đã thêm hai chế độ thay thế:
- Vòng tròn: Mỗi LLM chỉ nhận được phản hồi của người tham gia trước đó
- Ngôi sao: Tất cả các tin nhắn đều truyền qua nhà phân tích chính với vai trò là người điều phối trung tâm
Cuối cùng, các cuộc thảo luận cần các điểm cuối. Tôi đã triển khai các vòng có thể định cấu hình (1-5), với thử nghiệm cho thấy rằng nhiều vòng hơn làm tăng khả năng đạt được sự đồng thuận (mặc dù với chi phí tính toán cao hơn).
Lựa Chọn LLM và Tích Hợp Nghiên Cứu
Lựa chọn mô hình hiện tại bao gồm Mistral Large, DeepSeek-R1, Meta-Llama-3.3-70B và QwQ-32B. Mặc dù các mô hình đáng chú ý như Claude Sonnet và o3 của OpenAI không có mặt, nhưng điều này phản ánh tính khả dụng tín dụng của hackathon và các cân nhắc về giải thưởng của nhà tài trợ hơn là những hạn chế kỹ thuật.
self.models = {
'mistral': {
'name': 'Mistral Large',
'api_key': mistral_key,
'available': bool(mistral_key)
},
'sambanova_deepseek': {
'name': 'DeepSeek-R1',
'api_key': sambanova_key,
'available': bool(sambanova_key)
}
...
}
Đối với các mô hình hỗ trợ gọi hàm, tôi đã tích hợp một tác nhân nghiên cứu chuyên dụng, xuất hiện như một người tham gia bàn tròn khác. Thay vì cấp cho các mô hình quyền truy cập web trực tiếp, cách tiếp cận tác nhân này cung cấp sự rõ ràng trực quan về tính khả dụng tài nguyên bên ngoài và đảm bảo khả năng truy cập nhất quán trên tất cả các mô hình gọi hàm.
def handle_function_calls(self, completion, original_prompt: str, calling_model: str) -> str:
"""UNIFIED function call handler with enhanced research capabilities"""
message = completion.choices[0].message
# If no function calls, return regular response
if not hasattr(message, 'tool_calls') or not message.tool_calls:
return message.content
# Process each function call
for tool_call in message.tool_calls:
function_name = tool_call.function.name
arguments = json.loads(tool_call.function.arguments)
# Execute research and show progress
result = self._execute_research_function(function_name, arguments, calling_model_name)
Tác nhân nghiên cứu truy cập năm nguồn: Tìm kiếm trên web, Wikipedia, arXiv, GitHub và SEC EDGAR. Tôi đã xây dựng các công cụ này trên một kiến trúc lớp cơ sở có thể mở rộng để mở rộng trong tương lai trong khi tập trung vào các tài nguyên có thể nhúng miễn phí.
class BaseTool(ABC):
"""Base class for all research tools"""
def __init__(self, name: str, description: str):
self.name = name
self.description = description
self.last_request_time = 0
self.rate_limit_delay = 1.0
@abstractmethod
def search(self, query: str, **kwargs) -> str:
"""Main search method - implemented by subclasses"""
pass
def score_research_quality(self, research_result: str, source: str = "web") -> Dict[str, float]:
"""Score research based on recency, authority, specificity, relevance"""
quality_score = {
"recency": self._check_recency(research_result),
"authority": self._check_authority(research_result, source),
"specificity": self._check_specificity(research_result),
"relevance": self._check_relevance(research_result)
}
return quality_score
Vì các hoạt động nghiên cứu có thể tốn nhiều thời gian, các bong bóng thoại hiển thị các chỉ báo tiến trình và ước tính thời gian để duy trì sự tương tác của người dùng trong các tác vụ nghiên cứu dài hơn.
Khám Phá Giao Thức Sàn Mở
Sau cuộc thi hackathon, Deborah Dahl đã giới thiệu cho tôi về Open Floor Protocol, giao thức này hoàn toàn phù hợp với cách tiếp cận bàn tròn. Giao thức này cung cấp định dạng tin nhắn JSON tiêu chuẩn để giao tiếp giữa các tác nhân đa nền tảng. Điểm khác biệt chính của nó so với các giao thức tác nhân với tác nhân khác là tất cả các tác nhân đều duy trì nhận thức về cuộc trò chuyện liên tục giống như ngồi cùng bàn. Một tính năng khác mà tôi chưa thấy với các giao thức khác là người quản lý sàn có thể mời và loại bỏ các tác nhân khỏi sàn và các tác nhân một cách linh hoạt.
Các mẫu tương tác của giao thức ánh xạ trực tiếp vào kiến trúc của Consilium:
- Ủy quyền: Chuyển giao quyền kiểm soát giữa các tác nhân
- Kênh: Truyền tin nhắn mà không cần sửa đổi
- Hòa giải: Điều phối đằng sau hậu trường
- Điều phối: Nhiều tác nhân cộng tác
Tôi hiện đang tích hợp hỗ trợ Open Floor Protocol để cho phép người dùng thêm bất kỳ tác nhân tuân thủ OFP nào vào các cuộc thảo luận bàn tròn của họ. Bạn có thể theo dõi quá trình phát triển này tại: https://huggingface.co/spaces/azettl/consilium_ofp
Những Bài Học Kinh Nghiệm và Hàm Ý Tương Lai
Cuộc thi hackathon đã giới thiệu cho tôi nghiên cứu tranh luận đa tác nhân mà trước đây tôi chưa từng gặp, bao gồm các nghiên cứu nền tảng như Encouraging Divergent Thinking in Large Language Models through Multi-Agent Debate. Trải nghiệm cộng đồng thật đáng chú ý; tất cả những người tham gia tích cực hỗ trợ lẫn nhau thông qua phản hồi và cộng tác trên Discord. Việc thấy thành phần bàn tròn của tôi được tích hợp vào một dự án hackathon khác là một trong những điểm nổi bật của tôi khi làm việc trên Consilium.
Tôi sẽ tiếp tục làm việc trên Consilium và với việc mở rộng lựa chọn mô hình, tích hợp Open Floor Protocol và các vai trò tác nhân có thể định cấu hình, nền tảng có thể hỗ trợ hầu như bất kỳ kịch bản tranh luận đa tác nhân nào có thể tưởng tượng được.
Việc xây dựng Consilium đã củng cố niềm tin của tôi rằng tương lai của AI không chỉ nằm ở các mô hình riêng lẻ mạnh mẽ hơn mà còn ở các hệ thống cho phép cộng tác AI hiệu quả. Khi các mô hình ngôn ngữ nhỏ chuyên dụng trở nên hiệu quả hơn và thân thiện với tài nguyên, tôi tin rằng các bàn tròn SLM dành riêng cho nhiệm vụ với các tác nhân nghiên cứu chuyên dụng có thể cung cấp các lựa chọn thay thế hấp dẫn cho các mô hình ngôn ngữ lớn đa năng cho nhiều trường hợp sử dụng.
Link bài viết gốc
- Tags:
- Ai
- July 17, 2025
- Huggingface.co