Cách tôi sử dụng Hội đồng AI để giải quyết các vấn đề kỹ thuật mơ hồ

Một trợ lý AI thì hữu ích. Nhưng không phải lúc nào cũng đủ.

Nếu bạn sử dụng AI để lập trình, bạn sẽ biết mô típ này. Bạn mô tả một vấn đề. Mô hình đề xuất một giải pháp. Trông có vẻ ổn. Bạn triển khai nó. Rồi ba ngày sau, bạn phát hiện ra một lỗi cực lớn. Kiến trúc thất bại ở một điều kiện biên. Nó kết hợp hai thứ lẽ ra phải tách biệt.

Đây không phải là lỗi của mô hình. Đó là lỗi của quy trình. Một mô hình đơn lẻ thiếu khả năng thách thức các giả định của chính nó.

Đối với các tác vụ kỹ thuật phức tạp, bạn cần một Hội đồng AI. Đây không phải là một nền tảng mới. Đó là một quy trình làm việc có cấu trúc, nơi nhiều vai trò AI khác nhau cùng xem xét một đề xuất từ các góc độ khác nhau.

Mục tiêu là biến việc sử dụng AI thành một quy trình kỹ thuật có sự quản trị.

Dưới đây là cách quy trình này hoạt động:

• Problem Statement (Phát biểu vấn đề): Bạn đặt khung cho vấn đề. • Architect Agent (Agent Kiến trúc sư): Một agent dựa trên nguồn dữ liệu tạo ra đề xuất ban đầu. • AI Council (Hội đồng AI): Các vai trò AI khác nhau xem xét đề xuất. • Feedback Synthesis (Tổng hợp phản hồi): Một agent hợp nhất tất cả phản hồi và xác định các xung đột. • Objection Ledger (Sổ ghi chép phản đối): Bạn theo dõi mọi phản đối, mức độ nghiêm trọng và cách giải quyết chúng. • Human Governance (Sự quản trị của con người): Bạn quyết định khi nào nên dừng lại hoặc tiếp tục. • Executor Agent (Agent Thực thi): Một agent riêng biệt triển khai kế hoạch. • Auditor Agent (Agent Kiểm định): Một agent cuối cùng kiểm tra mã nguồn so với đặc tả ban đầu.

Các vai trò trong hội đồng của bạn nên bao gồm:

  • System Thinker (Người tư duy hệ thống): Đánh giá rủi ro và các ranh giới hệ thống.
  • Critical Reviewer (Người đánh giá phản biện): Thách thức các giả định và tìm ra các lỗ hổng.
  • Simplifier (Người đơn giản hóa): Tìm ra những sự phức tạp không cần thiết.
  • Alternatives Reviewer (Người đánh giá các phương án thay thế): Đề xuất các cách tiếp cận khác nhau.

Điều kỳ diệu không nằm ở việc sử dụng nhiều mô hình hơn. Điều kỳ diệu nằm ở việc phân tách vai trò. Khi bạn yêu cầu một AI "xem xét cái này", bạn sẽ nhận được những câu trả lời mơ hồ. Khi bạn yêu cầu một AI "tìm ra ba rủi ro kiến trúc lớn nhất", bạn sẽ nhận được dữ liệu có giá trị thực tiễn.

Bạn cũng phải tách biệt các ngữ cảnh. Agent viết mã không nên là cùng một agent thực hiện kiểm định mã. Điều này ngăn AI lặp lại cùng một điểm mù.

Con người không làm công việc chân tay. Con người nắm giữ các chốt chặn. Bạn quyết định khi nào phản hồi là đủ. Bạn quyết định chấp nhận rủi ro nào. Bạn là quản lý kỹ thuật, không phải công nhân lao động chân tay.

Hãy sử dụng cách này cho các đợt tái cấu trúc rủi ro cao và kiến trúc mơ hồ. Đừng dùng nó cho các lỗi nhỏ nhặt. Chi phí vận hành chỉ xứng đáng khi cái giá của sai lầm là rất lớn.

Source: https://dev.to/j3nnning/how-i-use-ai-councils-to-solve-ambiguous-engineering-problems-4dii

Optional learning community: https://t.me/GyaanSetuAi