Phát Triển AI Dựa Trên Đặc Tả: Quản Lý Hướng Dẫn Tác Nhân Trước Khi Triển Khai

Phát triển AI dựa trên đặc tả mang lại cho các nhóm một cách tốt hơn để làm việc với các tác nhân mã hóa AI: viết ý định trước, giữ nó hiển thị, và làm cho tác nhân hoạt động dựa trên một đặc tả bền vững thay vì một lời nhắc tạm thời.

Sự thay đổi đó quan trọng vì mã do tác nhân viết chỉ đáng tin cậy khi các hướng dẫn phía sau nó đáng tin cậy. Khi các đặc tả mơ hồ, lỗi thời, bị trùng lặp hoặc bị ẩn trong lịch sử trò chuyện, các nhóm mất khả năng xem xét những gì tác nhân được yêu cầu làm. Khi các đặc tả được cấu trúc và phiên bản hóa, chúng trở thành một hiện vật kỹ thuật thực sự.

ShareAI không phải là một khung tác nhân mã hóa hoặc trình xây dựng ứng dụng. Nó phù hợp ở giai đoạn sau trong quy trình sản xuất: khi một ứng dụng hoặc quy trình làm việc tác nhân cần truy cập mô hình, định tuyến, chuyển đổi dự phòng, hiển thị trên thị trường, và theo dõi sử dụng thông qua một API. Nhưng cùng một kỷ luật vận hành được áp dụng. Các nhóm quản lý lời nhắc, đặc tả, tuyến mô hình, và sử dụng từ đầu sẽ dễ dàng hơn nhiều trong việc mở rộng các tính năng AI.

Phát triển AI dựa trên đặc tả bắt đầu với ý định bền vững

Ý tưởng thực tế rất đơn giản: trước khi một tác nhân viết mã, nhóm viết ra những gì nên đúng. Điều đó có thể bao gồm vấn đề của người dùng, tiêu chí chấp nhận, ràng buộc, mục tiêu không đạt được, quy tắc dữ liệu, ranh giới bảo mật, và kỳ vọng kiểm tra.

Mã nguồn mở của GitHub Bộ công cụ đặc tả là một ví dụ về hướng đi này. Nó coi các đặc tả là hiện vật trung tâm có thể hướng dẫn kế hoạch, nhiệm vụ, và triển khai. Bài học sâu sắc hơn không gắn liền với một công cụ: một tác nhân cần một nguồn sự thật mà con người có thể kiểm tra.

Đối với các nhóm sản phẩm, nguồn sự thật đó nên đủ gọn để mô hình có thể theo dõi và đủ cụ thể để người đánh giá có thể đánh giá.

Tại sao lịch sử lời nhắc không đủ

Lịch sử lời nhắc có vẻ tiện lợi khi một người đang thử nghiệm. Nó trở nên không hiệu quả khi một nhóm cần hiểu tại sao một tính năng hoạt động theo một cách nhất định.

Nếu bản ghi duy nhất của ý định nằm trong trò chuyện, người đánh giá phải tái tạo quyết định từ các hướng dẫn rải rác. Nếu đặc tả nằm trong kho lưu trữ, vé, hoặc tài liệu sản phẩm, nhóm có thể xem xét nó trước khi triển khai và so sánh đầu ra với nó sau khi triển khai.

Đây là nơi phát triển AI dựa trên đặc tả trở thành quản trị thay vì sân khấu quy trình. Đặc tả nên trả lời những gì tác nhân được phép thay đổi, những gì nó nên tránh, ý nghĩa của thành công, và các kiểm tra hoặc đánh giá nào được yêu cầu trước khi thay đổi được triển khai.

Giữ hướng dẫn cho tác nhân gọn nhẹ

Nhiều hướng dẫn hơn không tự động làm cho các tác nhân an toàn hơn. Các tệp hướng dẫn dài thường che giấu mâu thuẫn. Chúng cũng có thể đẩy các quy tắc quan trọng nhất ra khỏi ngữ cảnh hoạt động.

Một bộ hướng dẫn tốt phân biệt ba điều: điều mà tác nhân đang cố gắng đạt được, lý do công việc quan trọng, và cách cơ sở mã mong đợi thay đổi được thực hiện. Giữ các quy tắc toàn cầu ngắn gọn. Đặt chi tiết cụ thể theo lĩnh vực gần với tính năng. Chỉ sử dụng ví dụ khi chúng làm rõ một mẫu thực tế.

Đối với các sản phẩm AI, điều này bao gồm các quy tắc định tuyến mô hình. Một đặc tả cho một tính năng AI hướng tới khách hàng nên nêu rõ liệu tính năng có cần độ trễ thấp, chi phí thấp, lý luận mạnh mẽ, chuyển đổi dự phòng, ưu tiên khu vực, hay giới hạn sử dụng hay không. Những lựa chọn đó ảnh hưởng đến tuyến API cũng như mã ứng dụng.

Kết nối Đặc tả với Truy cập và Sử dụng Mô hình

Đặc tả không nên kết thúc ở việc tạo mã. Khi tính năng chạy, nhóm vẫn cần biết tuyến mô hình nào nó sử dụng, mẫu sử dụng dự kiến là gì, và cách chi phí hoặc chất lượng sẽ được xem xét.

ShareAI giúp các nhóm truy cập hơn 150+ mô hình thông qua một API, so sánh tín hiệu thị trường, và lập kế hoạch tuyến dựa trên lựa chọn mô hình, giá cả, độ trễ, khả dụng, và độ tin cậy. Các nhà phát triển có thể bắt đầu với tài liệu ShareAI, so sánh các tùy chọn trong thị trường mô hình, và kiểm tra yêu cầu trong Sân chơi.

Đối với Người Xây dựng, đặc tả cũng có thể mô tả kỳ vọng kiếm tiền. Nếu một tính năng AI sẽ tạo ra mức sử dụng rất biến đổi giữa các khách hàng, Người Xây dựng có thể định tuyến suy luận đó thông qua ShareAI, đặt một biên lợi nhuận hoặc phụ phí, để khách hàng trả tiền cho ShareAI cho việc sử dụng, và nhận thanh toán hàng tháng dựa trên thu nhập được tạo ra.

Danh sách Kiểm tra Đặc tả Thực tế cho Công việc của Tác nhân AI

• Xác định kết quả người dùng và kết quả kinh doanh.
• Đặt tên bề mặt ứng dụng, quy trình làm việc, hoặc tác nhân sẽ gọi mô hình.
• Liệt kê các ràng buộc cứng, mục tiêu không đạt được, và ranh giới dữ liệu.
• Nêu tiêu chí chấp nhận bằng ngôn ngữ có thể kiểm tra được.
• Xác định các tệp, API, hoặc công cụ mà tác nhân có thể thay đổi.
• Chọn các yêu cầu về tuyến mô hình: chi phí, tốc độ, chất lượng, khả dụng, hoặc dự phòng.
• Quyết định cách đo lường việc sử dụng sau khi ra mắt.
• Đối với việc kiếm tiền từ Builder, xác định liệu có áp dụng biên lợi nhuận hoặc phụ phí cho suy luận định tuyến hay không.

Mục tiêu không phải là làm chậm đội nhóm. Mục tiêu là làm cho việc phát triển hỗ trợ AI đủ khả năng kiểm tra để tốc độ không biến thành việc làm lại.

Câu hỏi thường gặp

Phát triển AI dựa trên đặc tả là gì?

Phát triển AI dựa trên đặc tả là một quy trình làm việc nơi các đội nhóm viết các yêu cầu có cấu trúc và tiêu chí chấp nhận trước khi các tác nhân AI tạo hoặc sửa đổi mã.

Tại sao phát triển AI dựa trên đặc tả lại hữu ích?

Nó làm cho ý định có thể kiểm tra được. Các đội nhóm có thể kiểm tra đặc tả, đánh giá việc triển khai dựa trên nó, và tránh dựa vào lịch sử nhắc lệnh rời rạc.

Đặc tả có giống như nhắc lệnh không?

Không. Nhắc lệnh thường là một hướng dẫn một lần. Đặc tả là một tài liệu bền vững có thể được phiên bản hóa, kiểm tra, thử nghiệm, và tái sử dụng qua các lần chạy của tác nhân.

ShareAI có cung cấp công cụ phát triển dựa trên đặc tả không?

Không. ShareAI là một thị trường và API AI, không phải là một khung phát triển. Nó giúp các đội nhóm định tuyến lưu lượng mô hình, so sánh mô hình, quản lý việc sử dụng, và hỗ trợ kiếm tiền từ Builder khi lưu lượng AI chạy qua ShareAI.

Làm thế nào để viết hướng dẫn cho tác nhân AI?

Giữ chúng ngắn gọn, có cấu trúc, và cụ thể. Tách biệt các quy tắc toàn cầu khỏi ngữ cảnh cụ thể của tính năng, và tránh nhồi nhét mọi trường hợp ngoại lệ vào một tệp hướng dẫn dài.

Một đặc tả tính năng AI nên bao gồm những gì?

Bao gồm kết quả của người dùng, tiêu chí chấp nhận, giới hạn dữ liệu, các thay đổi được phép, kỳ vọng về tuyến mô hình, kiểm tra chất lượng và cách đo lường việc sử dụng.

Tuyến mô hình phù hợp như thế nào trong một đặc tả?

Đặc tả nên nêu rõ liệu tính năng có cần độ trễ thấp, chi phí thấp hơn, lý luận mạnh mẽ hơn, tuyến dự phòng, ưu tiên khu vực hay yêu cầu tính sẵn sàng nghiêm ngặt hay không.

Các Nhà xây dựng có thể kiếm tiền từ các tính năng AI được tạo bằng các tác nhân mã hóa không?

Có, nếu Nhà xây dựng sở hữu ứng dụng và định tuyến suy luận AI thông qua ShareAI. Nhà xây dựng có thể cấu hình một khoản chênh lệch hoặc phụ phí và nhận thanh toán hàng tháng từ việc sử dụng được tạo ra.

Khi nào một nhóm nên sử dụng ShareAI Playground?

Sử dụng Playground khi so sánh hành vi mô hình trước khi chọn một tuyến cho một tính năng AI, quy trình làm việc của tác nhân hoặc tích hợp API sản xuất.

Sai lầm lớn nhất trong phát triển AI dựa trên đặc tả là gì?

Sai lầm lớn nhất là để đặc tả lệch khỏi hành vi sản xuất. Xem xét, phiên bản và cập nhật đặc tả khi sản phẩm, tuyến mô hình hoặc tiêu chí chấp nhận thay đổi.

Các nhóm chuẩn bị tính năng AI sản xuất có thể sử dụng Hướng dẫn bắt đầu nhanh API ShareAI để kết nối quyền truy cập mô hình, định tuyến và khả năng hiển thị sử dụng với tính năng mà họ đang đặc tả.