Tại sao các kỹ sư AI giỏi nhất đang trở thành những người hoài nghi toàn thời gian

Kỹ năng khác biệt không còn là xây dựng nhanh hơn nữa – mà là biết chính xác những gì không nên tin. Có một phiên bản của “kỹ sư AI” mà thị trường việc làm vẫn quảng cáo: một người có thể kết nối một mô hình, viết một lời nhắc (prompt) khéo léo, thiết lập một quy trình RAG (Retrieval Augmented Generation) và triển khai. Phiên bản đó đã và đang bị thương mại hóa. Các framework hiện thực hiện hầu hết các kết nối. Các mẫu lời nhắc chỉ cách một tìm kiếm trên Google. Khung sườn mà trước đây một kỹ sư lành nghề mất một tuần để xây dựng, giờ đây một người có năng lực chỉ mất một buổi chiều. Các kỹ sư đang vượt lên dẫn trước hiện nay không phải là những người xây dựng nhanh nhất. Họ là những người ít tin tưởng nhất. Không phải theo nghĩa hoài nghi, không có gì hiệu quả. Mà theo một nghĩa cụ thể, có kỷ luật: họ đã ngừng chấp nhận các con số điểm chuẩn, tuyên bố của nhà cung cấp, video trình diễn và đầu ra tự tin của chính mô hình của họ một cách hiển nhiên. Họ đã biến sự nghi ngờ thành một phương pháp làm việc thay vì một đặc điểm tính cách. Hãy gọi đúng tên của nó – sự hoài nghi chuyên nghiệp đã lặng lẽ trở thành một kỹ năng kỹ thuật cốt lõi, và hầu hết các nhóm vẫn chưa cập nhật việc tuyển dụng hoặc văn hóa của họ để phản ánh điều đó. Công việc đã thay đổi dưới tên gọi Vài năm trước, nút thắt cổ chai trong kỹ thuật AI là khả năng. Liệu mô hình có thể thực hiện được công việc đó không? Câu hỏi đó phần lớn đã được trả lời. Nút thắt cổ chai ngày nay là hiệu chỉnh độ tin cậy – biết chính xác mức độ tin tưởng vào một hệ thống mà, theo thiết kế, được xây dựng để nghe có vẻ thuyết phục dù đúng hay sai. Đó là một bộ kỹ năng hoàn toàn khác. Xây dựng một quy trình là một vấn đề xây dựng. Quyết định xem đầu ra của quy trình có thể được tin cậy trong sản xuất, ở quy mô lớn, trong các trường hợp ngoại lệ mà không ai kiểm tra, là một vấn đề nhận thức luận. Các kỹ sư giỏi nhất mà tôi từng thấy hoạt động theo cách này đã thực sự trở thành những người hoài nghi nội bộ: những người có đóng góp chính không phải là viết tích hợp, mà là quyết định những gì không nên tin về nó. Sự hoài nghi thực sự trông như thế nào trong công việc hàng ngày Điều này không trừu tượng. Nó thể hiện dưới dạng các thói quen cụ thể, có thể lặp lại, phân biệt các kỹ sư AI cấp cao với các kỹ sư chỉ có “AI” trong chức danh công việc của họ. Họ thẩm vấn các điểm chuẩn trước khi trích dẫn chúng. Một mô hình đứng đầu bảng xếp hạng hầu như không cho bạn biết gì về cách nó sẽ hoạt động trên miền cụ thể của bạn, phân phối dữ liệu cụ thể của bạn, các trường hợp ngoại lệ cụ thể của bạn. Các kỹ sư hoài nghi hỏi điểm chuẩn thực sự đo lường điều gì, liệu tập đánh giá có thể trùng lặp với dữ liệu đào tạo một cách hợp lý hay không, và liệu nhiệm vụ có giống với khối lượng công việc sản xuất của họ hay không – trước khi họ để một con số điểm chuẩn ảnh hưởng đến một quyết định kiến trúc duy nhất. Họ coi các bản trình diễn là tiếp thị, không phải bằng chứng. Một bản trình diễn được trau chuốt được tối ưu hóa cho một con đường đã được diễn tập. Các kỹ sư hoài nghi giả định rằng các con đường không được diễn tập là nơi hệ thống bị lỗi, và họ cố tình tìm kiếm những con đường đó, trước khi khách hàng tìm thấy chúng trước. Họ không tin tưởng vào bộ đánh giá của chính mình cũng như mô hình. Đây là điều mà hầu hết các nhóm bỏ qua hoàn toàn. Một bộ đánh giá được viết bởi cùng một nhóm đã xây dựng tính năng có xu hướng kiểm tra các lỗi mà nhóm đó đã dự đoán – và vẫn mù quáng trước những lỗi mà họ không dự đoán. Các kỹ sư hoài nghi định kỳ yêu cầu một người ngoài, hoặc một quy trình đối kháng, cố gắng phá vỡ các đánh giá của chính họ, không chỉ mô hình của họ. Họ tách biệt “mô hình nói vậy” khỏi “nó là sự thật”. Cách diễn đạt tự tin và cách diễn đạt chính xác được tạo ra bởi cùng một cơ chế và không tương quan theo cách mà trực giác của chúng ta giả định. Các kỹ sư đã nội hóa điều này ngừng đọc sự trôi chảy như một thước đo độ chính xác – một thói quen đáng ngạc nhiên là khó bỏ sau khi bạn đã dành thời gian. nhiều tháng nói chuyện với một hệ thống không bao giờ tỏ ra không chắc chắn. Họ hỏi điều gì sẽ xảy ra khi nhà cung cấp thay đổi một thứ gì đó. Hành vi của mô hình không tĩnh. Một bản cập nhật phiên bản âm thầm, một lời nhắc hệ thống được cập nhật lặng lẽ ở phía nhà cung cấp, một điểm cuối không dùng nữa – bất kỳ điều nào trong số này đều có thể làm thay đổi đầu ra theo những cách không bao giờ xuất hiện trong nhật ký thay đổi. Các kỹ sư hoài nghi xây dựng hệ thống giám sát sự trôi dạt, không chỉ giám sát thời gian hoạt động. Mô hình được đặt tên: Rửa điểm chuẩn Có một chế độ lỗi cụ thể đáng được gọi tên, bởi vì nó ở khắp mọi nơi và hiếm khi được chỉ ra trực tiếp: rửa điểm chuẩn – thực hành trích dẫn một điểm tổng hợp ấn tượng như thể nó chứng nhận độ tin cậy trong thế giới thực, trong khi điểm chuẩn và nhiệm vụ sản xuất chỉ có sự tương đồng bề mặt. Điều này xảy ra ở cấp độ nhà cung cấp, khi các trang tiếp thị dẫn đầu với bảng xếp hạng không nói lên điều gì về việc sử dụng công cụ, sự suy giảm ngữ cảnh dài hoặc tính xác thực theo miền cụ thể. Điều này cũng xảy ra ở cấp độ nhóm, khi một điểm đánh giá nội bộ được báo cáo lên trên là “chúng tôi đạt độ chính xác 94%” mà không ai hỏi 94% của cái gì, được đo như thế nào, so với phân phối nào của các truy vấn người dùng thực. Các kỹ sư hoài nghi là những người ngăn chặn việc rửa điểm chuẩn ngay từ đầu – trong chính nhóm của họ, trước khi nó đạt đến quyết định lộ trình. Một đường ống tin cậy, không phải đường ống xây dựng Hầu hết các nhóm đều có một đường ống xây dựng rõ ràng: nhắc nhở, truy xuất, tạo, đầu ra. Ít nhóm có một đường ống tin cậy rõ ràng song song với nó – chuỗi các kiểm tra mà một tuyên bố phải vượt qua trước khi nó được phép ảnh hưởng đến một quyết định. Tuyên bố (điểm chuẩn, kết quả demo, đầu ra mô hình) │ ▼ Kiểm tra nguồn ── Ai đã tạo ra cái này, và động cơ của họ là gì? │ ▼ Kiểm tra phân phối ── Dữ liệu thử nghiệm có giống với lưu lượng truy cập thực của chúng ta không? │ ▼ Kiểm tra đối kháng ── Có ai đã cố gắng phá vỡ cái này chưa? │ ▼ Kiểm tra trôi dạt ── Điều này có còn đúng vào tháng tới, trên một phiên bản mới không? │ ▼ Được phép đưa ra quyết định sản xuất Bỏ qua một giai đoạn, và bạn không hiệu quả – bạn chỉ đang chuyển lỗi xuống hạ nguồn, đến một điểm mà nó tốn kém hơn và dễ thấy hơn. Ngây thơ so với Hoài nghi, song song Không có điều nào trong số này làm cho kỹ sư hoài nghi chậm hơn theo mặc định. Nó làm cho họ chậm hơn một lần, sớm, và nhanh hơn đáng kể sau đó – bởi vì họ không phải là người gỡ lỗi một sự cố sản xuất mà một kiểm tra đối kháng năm phút đã có thể phát hiện trong quá trình xem xét. Đây không phải là sự hoài nghi – đây là một mối quan hệ khác với sự tự tin Có một phiên bản của tư thế này biến thành “không có gì hoạt động, đừng bận tâm”