Xây dựng bộ đánh giá trước khi xây dựng tính năng

Tính năng được phát hành. Mô hình rất tốt. Và lần đầu tiên nó làm sai điều gì đó trước mặt khách hàng, không ai có thể cho bạn biết nó đang tốt lên hay tệ đi. Đó là điều xảy ra khi bộ đánh giá đến sau tính năng. Và thường thì nó chẳng bao giờ đến.

Đây là khuôn mẫu mà tôi liên tục thấy. Các đội xây một tính năng AI vì mô hình demo tốt. Bản demo chính là toàn bộ thanh chất lượng. Tính năng được đưa lên production, và mọi quyết định về nó sau đó đều dựa trên cảm giác — nó có cảm thấy tốt hơn không, nhà cung cấp có nói mô hình mới tốt hơn không, có khách hàng nào phàn nàn không? Cả đội đang lái một chiếc máy bay không có đồng hồ đo, và chiếc máy bay đó chính là mô hình — thành phần duy nhất thay đổi mà không cần hỏi ai.

Cách khắc phục thì ngược với trực giác: hãy xây bộ đánh giá trước khi xây tính năng. Bộ đánh giá là nền móng, không phải bước cuối cùng.

Bộ đánh giá thực chất là gì

Bộ đánh giá là một bộ kiểm thử dành cho AI. Một tập hợp các đầu vào với đầu ra đã biết là đúng, chạy lên mô hình, chấm điểm theo tần suất mô hình trả lời đúng. Nó có cùng hình dạng với một bộ kiểm thử cho code — một tập hợp các ca phải vượt qua — chỉ khác một điểm: đầu ra là mơ hồ. Câu trả lời có thể đúng theo nhiều cách, nên việc chấm điểm phải dựa trên phán đoán, nghĩa là bộ đánh giá một phần là kiểm thử, một phần là thang điểm.

Bộ này gồm ba phần. Bộ vàng: vài trăm ca, được tuyển chọn thủ công, bao phủ các kịch bản quan trọng và các trường hợp ngoại lệ, mỗi ca có một đáp án đã biết là đúng. Bộ hồi quy: các ca từng bắt được lỗi thật trong quá khứ, được giữ mãi mãi, để một bản sửa không bao giờ âm thầm phá vỡ lại. Và các thang điểm: định nghĩa về thế nào là "tốt" cho từng loại nhiệm vụ, được viết ra, để việc chấm điểm không còn là cảm hứng nhất thời.

Đó là toàn bộ bộ đánh giá. Nó không có gì xa lạ. Nó là phiên bản AI của điều mà các đội phần mềm đã làm trong bốn mươi năm, và bỏ qua nó cũng giống như quyết định phát hành code mà không có kiểm thử — nó chạy cho đến khi không chạy nữa, và cái giá phải trả sẽ lộ ra sau.

Bộ đánh giá chính là bộ kiểm thử của bạn. Mô hình chính là code của bạn. Và giống như code, mô hình thay đổi mà không báo trước — bộ đánh giá chính là cách bạn phát hiện ra điều đó.

Vì sao nó phải đến trước

Bộ đánh giá đến trước vì nó thay đổi mọi quyết định theo sau.

Xây bộ đánh giá trước tính năng, và tính năng sẽ được xây dựng dựa trên một mục tiêu. Bạn có thể thử hai mô hình và chọn cái đạt điểm cao hơn trên các ca của bạn thay vì cái demo tốt hơn. Bạn có thể tinh chỉnh các lời nhắc theo thang điểm thay vì theo cảm giác. Bạn có thể nói không với một mô hình "tuyệt vời" nhưng trượt các trường hợp ngoại lệ của bạn. Bộ đánh giá biến việc chọn mô hình từ một cuộc thi demo thành một phép đo.

Xây bộ đánh giá sau tính năng, và bạn nhận được phiên bản hồi tố của tất cả những điều đó. Mô hình đã được chọn, các lời nhắc đã được viết, tính năng đã nằm trước mặt người dùng. Bộ đánh giá đến muộn chỉ có thể ghi lại những sai lầm mà nó được tạo ra để bắt. Nó có thể nói cho bạn biết mô hình tệ. Nó không thể cho bạn biết lẽ ra nên chọn cái nào.

Lý do khác để nó đến trước: bộ đánh giá là cách cả đội học được "tốt" nghĩa là gì. Viết bộ vàng buộc cuộc đối thoại phải diễn ra — các trường hợp ngoại lệ là gì, một câu trả lời sai trông như thế nào, cái giá của từng loại lỗi là bao nhiêu. Cuộc đối thoại đó chính là đặc tả thực sự của tính năng. Các đội viết bộ đánh giá trước sẽ khám phá ra yêu cầu trước khi xây dựng. Các đội bỏ qua nó sẽ khám phá ra yêu cầu sau sự cố.

Bộ đánh giá khả thi tối thiểu

Sự phản đối luôn giống nhau: xây một bộ đánh giá nghe như một dự án lớn, trong khi tính năng phải được phát hành. Bộ đánh giá khả thi tối thiểu trả lời điều đó. Nó là năm mươi ca cộng một cuối tuần.

Năm mươi ca, được tuyển chọn trong một buổi chiều cùng người phụ trách lĩnh vực: mười yêu cầu phổ biến nhất, mười cái khó nhất, mười cái nguy hiểm nhất, mười cái trông giống nhau nhưng cần đáp án khác nhau, và mười cái từng làm hỏng các hệ thống tương tự trước đây. Một cuối tuần để chạy chúng, chấm điểm và viết ra thang điểm. Đó là hạt giống. Bộ đánh giá phát triển từ đó — mỗi lỗi production trở thành một ca hồi quy, mỗi loại nhiệm vụ mới có bộ vàng riêng, mỗi lần nâng cấp mô hình đều được chấm điểm so với toàn bộ.

Bộ đánh giá năm mươi ca sẽ không bắt được mọi thứ. Nó sẽ bắt được những vấn đề lớn, nó sẽ buộc cuộc đối thoại về đặc tả phải diễn ra, và nó sẽ cho bạn một con số để theo dõi. Một đội có năm mươi ca và một thang điểm tốt hơn vô hạn lần so với một đội có bản demo tuyệt vời mà không có gì khác.

Quy tắc giúp nó tồn tại

Bộ đánh giá chết theo cùng cách mà mọi bộ kiểm thử chết: khi nó ngừng được sử dụng. Quy tắc giữ cho nó sống rất đơn giản — không có thay đổi mô hình nào được phát hành mà không chạy qua bộ đánh giá. Phiên bản mô hình mới, lời nhắc mới, nhiệt độ mới, bất cứ thứ gì mới: chạy bộ đánh giá, so sánh điểm số, và chỉ phát hành nếu tốt hơn hoặc bằng. Đó là toàn bộ kỷ luật, và nó cũng là kỷ luật giúp các bài kiểm thử trong phần mềm luôn trung thực.

Tính năng bạn đang xây lúc này sẽ được duy trì bởi bộ đánh giá bạn xây trong tuần này. Mô hình sẽ thay đổi, nhà cung cấp sẽ cập nhật, dữ liệu sẽ trôi dạt, và mỗi khoảnh khắc đó đều là một quyết định mà bộ đánh giá giúp bạn trả lời được. Hãy xây nó trước, giữ nó nhỏ gọn, và biến nó thành cổng kiểm soát. Bản demo cho bạn biết mô hình có thể làm nhiệm vụ đó. Bộ đánh giá cho bạn biết liệu tháng sau, sau khi mọi thứ đã đổi thay, nó có còn làm được hay không.

Xây bộ đánh giá trước tính năng. Năm mươi ca, một cuối tuần, và một quy tắc rằng không có điểm số thì không có gì được phát hành. Đó là toàn bộ thực hành, và nó là sự khác biệt giữa AI mà bạn tin tưởng và AI mà bạn chỉ biết hy vọng.

Nghĩ rằng lập luận này phù hợp với sự kiện của bạn? Hãy kể cho tôi về khán phòng — lịch trình có chọn lọc.