Đội ngũ AI và Cơ sở hạ tầng của Google đã âm thầm công bố một điều đáng chú ý trong một bài đăng blog mà hầu hết ngành công nghiệp đã lướt qua: tốc độ di chuyển các mô hình machine learning sản xuất từ TensorFlow sang JAX nhanh gấp sáu lần, ở quy mô liên quan đến hàng nghìn dòng mã, hàng trăm lớp và các phụ thuộc chạy sâu qua nhiều tệp. Sundar Pichai đã đề cập đến nó trên sân khấu tại Google Cloud Next. Con số đó đã trở thành tiêu đề. Kiến trúc bên dưới nó mới là câu chuyện thực sự, và nó cũng chính là kiến trúc đằng sau mọi cuộc di chuyển tác nhân quy mô lớn đáng tin cậy đang diễn ra ngay bây giờ, cho dù bầy đàn là 8 tác nhân hay 800 tác nhân.
Đây là chi tiết quan trọng nhất: họ đã thử hướng một tác nhân AI duy nhất vào cơ sở mã trước tiên. Nó đã thất bại. Không phải một phần. Nó mất ngữ cảnh, tưởng tượng ra các API không tồn tại và tạo ra mã không thể biên dịch. Giải pháp không phải là một mô hình thông minh hơn. Đó là một kiến trúc hoàn toàn khác, một kiến trúc hiện có tên gọi: mẫu "nhà máy tối" (dark factory), một cơ sở mã nơi các tác nhân lập kế hoạch, triển khai, kiểm thử và xuất xưởng mã mà không có bất kỳ sự đánh giá nào của con người trong vòng lặp, giống như cách một nhà máy tự động hoàn toàn vận hành máy móc trong bóng tối vì không còn ai để bật đèn nữa.
Bài viết này là sự phân tích hoàn chỉnh về mẫu đó. Không phải phiên bản tiếp thị. Mà là cơ chế thực tế về cách hàng trăm tác nhân di chuyển một cơ sở mã thực mà không cần con người kiểm tra từng thay đổi riêng lẻ, và lý do tại sao thứ làm cho nó an toàn không phải là sự tin tưởng vào mô hình, mà là một kiến trúc được thiết kế đặc biệt để không bao giờ cần sự tin tưởng đó ngay từ đầu.
Tại Sao Một Tác Nhân Đơn Lẻ Thất Bại Ở Quy Mô Lớn
Trước khi nói về kiến trúc, hãy hiểu chính xác lý do tại sao cách tiếp cận ngây thơ lại thất bại, bởi vì mọi quyết định thiết kế trong mẫu hoạt động đều tồn tại để vá một trong những thất bại này.
Một tác nhân duy nhất hướng vào một cơ sở mã lớn trước tiên sẽ gặp phải vấn đề về ngữ cảnh. Ngay cả với một cửa sổ ngữ cảnh rộng rãi, một cơ sở mã với hàng trăm tệp phụ thuộc lẫn nhau, chuỗi gọi sâu và các giả định kế thừa giữa các mô-đun vượt quá những gì bất kỳ phiên làm việc đơn lẻ nào có thể nắm giữ một cách mạch lạc. Tác nhân bắt đầu mạnh mẽ với một vài tệp đầu tiên và suy giảm khi ngữ cảnh làm việc chứa đầy lịch sử tích lũy, nửa liên quan.
Sau đó, nó gặp phải vấn đề về trình tự. Di chuyển mã không phải là một tác vụ song song theo mặc định. Tệp B thường phụ thuộc vào việc tệp A đã được di chuyển, bởi vì chữ ký hàm đã thay đổi, các import đã di chuyển hoặc cấu trúc dữ liệu đã thay đổi hình dạng. Một tác nhân không có bản đồ phụ thuộc rõ ràng hoặc đoán thứ tự, dẫn đến các trạng thái trung gian bị hỏng, hoặc xử lý các tệp theo bất kỳ thứ tự nào chúng được liệt kê, về mặt chức năng cũng giống như đoán.
Sau đó, nó gặp phải vấn đề xác minh, và đây là vấn đề thực sự quan trọng nhất. Một tác nhân di chuyển mã và sau đó tự đánh giá quá trình di chuyển của chính nó cũng giống như đang kiểm tra bài tập về nhà của chính mình với chính xác những điểm mù đã tạo ra bất kỳ sai lầm nào ngay từ đầu. Nếu tác nhân không hiểu rằng một API cụ thể hoạt động khác dưới một phiên bản mới, nó sẽ không phát hiện ra sự hiểu lầm đó khi xem xét lại đầu ra của chính nó, bởi vì cùng một khoảng trống hiểu biết đó hiện diện trong cả hai lần.
Nhóm của Google đã trực tiếp phát hiện ra điều này. Thiết lập một tác nhân duy nhất không thể cân bằng các quy tắc cấu trúc của việc di chuyển với các chi tiết thực thi từng dòng một cách đồng thời. Việc tách hai mối quan tâm này thành các vai trò riêng biệt chính là giải pháp thực sự, và nó cũng chính là giải pháp xuất hiện độc lập trong sách dạy nấu ăn về di chuyển đã được công bố của OpenAI, trong nghiên cứu học thuật về các vòng lặp di chuyển đa tác nhân và trong mọi hệ thống sản xuất thực sự đang chạy ở quy mô này.
Kiến Trúc: Ba Vai Trò, Không Phải Một Người Tổng Quát
Mẫu hoạt động chia công việc thành các vai trò với các công việc thực sự khác nhau, không chỉ là các lời nhắc khác nhau hướng vào cùng một tác nhân tổng quát.
Một Bộ Lập Kế Hoạch (Planner) sử dụng công cụ xác định, không phải phỏng đoán của LLM, để sắp xếp công việc. Đây là chi tiết phân biệt một hệ thống thực sự mở rộng quy mô với một hệ thống trông ấn tượng trong bản demo và sụp đổ trong sản xuất. Bộ Lập Kế Hoạch của Google không yêu cầu LLM tìm ra thứ tự di chuyển thông qua suy luận. Nó sử dụng phân tích tĩnh dựa trên trình biên dịch, cùng loại công cụ xác định đã hỗ trợ phần mềm doanh nghiệp trong nhiều thập kỷ, để xây dựng cây phụ thuộc thực tế và xác định một kế hoạch thực thi bắt đầu từ các nút lá (các tệp không có gì khác phụ thuộc vào) và làm việc hướng lên trên các tệp mà mọi thứ khác đều phụ thuộc vào.
Điều này quan trọng bởi vì sắp xếp thứ tự phụ thuộc không phải là một vấn đề sáng tạo. Đó là một vấn đề cơ học với một câu trả lời đúng, và việc sử dụng LLM để giải quyết một vấn đề đã có sẵn giải pháp xác định chỉ giới thiệu một nguồn lỗi mới ở nơi không cần tồn tại. Nguyên tắc cơ bản: bất cứ nơi nào một vấn đề có câu trả lời thuật toán, hãy sử dụng thuật toán. Dành mô hình ngôn ngữ cho phần nhiệm vụ thực sự đòi hỏi sự phán đoán, đó là chuyển đổi mã thực tế, không phải sắp xếp thứ tự tệp nào đi trước.
Một Tác Nhân Di Chuyển (Migration Agent) (hoặc, trong các hệ thống lớn hơn, hàng trăm tác nhân chạy song song, các phiên bản biệt lập, phạm vi hẹp của cùng một vai trò) thực hiện chuyển đổi mã thực tế. Mỗi phiên bản nhận một nhiệm vụ có phạm vi, lý tưởng là một tệp hoặc một mô-đun được giới hạn chặt chẽ, một bản sao duy nhất và một bản tóm tắt di chuyển rõ ràng mô tả chính xác những gì cần thay đổi và tại sao. Nó kiểm tra mã liên quan, thực hiện các chỉnh sửa và tạo ra một bản vá. Nó không quyết định liệu bản vá của chính nó có đúng hay không. Đó không phải là công việc của nó, và kiến trúc được thiết kế đặc biệt để nó không thể vô tình đảm nhận công việc đó.
Một Lớp Môi Trường và Xác Minh (Environment and Verification layer) xây dựng, chạy và kiểm tra mã đã được di chuyển trong một môi trường biệt lập trước khi bất cứ thứ gì được chấp nhận. Đây là nơi "xong là xong" trở thành một sự thật cơ học thay vì một ý kiến. Cách tiếp cận của Google rất chính xác: ngành công nghiệp trong lịch sử đã đưa ra hai lựa chọn tồi để quyết định khi nào công việc của AI thực sự hoàn thành: đánh giá của con người không thể mở rộng quy mô đến hàng trăm tệp, hoặc tự đánh giá của AI không thể kiểm toán được vì không có hồ sơ về những gì thực sự đã được kiểm tra. Câu trả lời của họ là xác minh toán học, mã xác định xác nhận biên dịch thành công, các bài kiểm tra vượt qua và hành vi khớp với một thông số kỹ thuật đã xác định, thay thế cả hai lựa chọn tồi bằng một lựa chọn thứ ba thực sự có thể kiểm tra được.
Hãy chú ý những gì còn thiếu trong danh sách này: một con người đọc từng diff riêng lẻ trước khi nó được hợp nhất. Đó là toàn bộ mục đích của mẫu nhà máy tối, và nó cũng chính xác là nơi trực giác của hầu hết mọi người về sự an toàn đi sai hướng, bởi vì nó nghe có vẻ như hệ thống chỉ đang tin tưởng các tác nhân nhiều hơn. Ngược lại. Nó đang tin tưởng các tác nhân ít hơn, về mặt cấu trúc, bằng cách thay thế điểm phán đoán duy nhất, "tác nhân có nói cái này hoạt động không," bằng một lớp xác minh mà tác nhân không thể ảnh hưởng hoặc nói vòng vo để vượt qua.
Lớp Cô Lập: Tại Sao Mỗi Tác Nhân Có Sandbox Riêng
Việc chạy hàng trăm tác nhân đồng thời trên cùng một cơ sở mã tạo ra một rủi ro rõ ràng: điều gì xảy ra khi tác nhân 47 đang giữa quá trình chỉnh sửa một tệp mà thay đổi của tác nhân 12 phụ thuộc vào, và chỉnh sửa của tác nhân 12 vừa phá vỡ quá trình biên dịch.
Câu trả lời, nhất quán trong kiến trúc di chuyển đã được công bố của OpenAI và hệ thống sản xuất của Google, là cô lập theo mặc định. Mỗi nhiệm vụ di chuyển chạy trong môi trường sandbox riêng của nó, thường là git worktree riêng của nó, một bản sao hoàn chỉnh, độc lập của kho lưu trữ có liên quan được giới hạn trong một nhiệm vụ đó. Nếu một tác nhân trong sandbox đó phá vỡ thứ gì đó, nó sẽ phá vỡ một bản sao biệt lập, không phải cơ sở mã dùng chung, và chắc chắn không phải công việc đang tiến hành của một tác nhân khác.
Sự cô lập này làm được nhiều hơn là chỉ ngăn ngừa va chạm. Nó làm cho toàn bộ hệ thống có thể song song hóa một cách tầm thường, bởi vì không có trạng thái có thể thay đổi dùng chung để hàng trăm tác nhân đồng thời giẫm lên. Tác nhân 1 đến tác nhân 800 có thể thực sự chạy cùng một lúc, mỗi tác nhân trong một môi trường sạch chỉ chứa các tệp và ngữ cảnh liên quan đến nhiệm vụ cụ thể của nó, với rủi ro bằng không về việc ảo giác của một tác nhân làm ô nhiễm công việc chính xác của tác nhân khác.
Dây nịt (harness), lớp điều phối quyết định nhiệm vụ nào đi đến sandbox nào và điều gì xảy ra với bản vá kết quả, ở bên ngoài mọi sandbox riêng lẻ. Đây là một lựa chọn kiến trúc cụ thể và quan trọng: quy trình đáng tin cậy có quyền truy cập vào bí mật, công cụ bên ngoài và kho lưu trữ thực tế sống riêng biệt với môi trường thực thi không đáng tin cậy nơi mã do AI tạo ra thực sự chạy. Sandbox nhận chính xác những gì nó cần cho một nhiệm vụ duy nhất của nó, không hơn. Quy trình máy chủ không bao giờ chạy mã được tạo trực tiếp với các quyền nâng cao của chính nó. Sự tách biệt này là những gì làm cho nó an toàn để cho phép mã của tác nhân thực thi, vì một sai lầm hoặc thậm chí là một cuộc tấn công tiêm lời nhắc đối nghịch bên trong sandbox không có đường dẫn đến bất cứ thứ gì bên ngoài nó.
Vòng Lặp Chính Nó: Lập Kế Hoạch, Thực Thi, Xác Minh, Tinh Chỉnh
Loại bỏ quy mô và các công cụ cụ thể, và vòng lặp thực tế chạy bên dưới tất cả những điều này có bốn giai đoạn, lặp lại cho mỗi nhiệm vụ cho đến khi nhiệm vụ đó vượt qua hoặc cạn kiệt ngân sách thử lại của nó.
Giai đoạn một: lập kế hoạch di chuyển. Tác nhân Di chuyển nhận nhiệm vụ có phạm vi của nó, một tệp hoặc mô-đun, thông số kỹ thuật mục tiêu cụ thể (phiên bản ngôn ngữ, thay đổi framework, yêu cầu tương thích API) và tạo ra một chuyển đổi ứng viên. Đây là giai đoạn duy nhất mà suy luận mô hình ngôn ngữ sáng tạo, dựa trên phán đoán đang thực hiện công việc chính, bởi vì quyết định cách dịch chính xác một mẫu cụ thể thành mẫu tương đương của nó trong một framework mới thực sự đòi hỏi sự hiểu biết, không chỉ tra cứu cơ học.
Giai đoạn hai: thiết lập môi trường tự động. Một thành phần riêng biệt, đôi khi được gọi là Tác nhân Môi trường trong tài liệu học thuật về mẫu này, tự động xây dựng một môi trường xây dựng và thời gian chạy cho mã đã được di chuyển, xử lý việc giải quyết phụ thuộc và cấu hình để bản vá ứng viên thực sự có thể được biên dịch và chạy trong các điều kiện thực tế thay vì được đánh giá một cách trừu tượng.
Giai đoạn ba: xác nhận kiểm thử. Mã đã được di chuyển chạy dựa trên bộ kiểm thử thực tế, hoặc dựa trên một bộ tương đương được tạo ra nếu không có bộ kiểm thử nào tồn tại cho mô-đun cụ thể đó. Đây là bước xác minh cơ học, bước tạo ra kết quả đạt hoặc không đạt khách quan thay vì một ấn tượng. Hoặc các bài kiểm tra vượt qua hoặc chúng không, và không có sự mơ hồ nào để một tác nhân nói vòng vo để vượt qua.
Giai đoạn bốn: tinh chỉnh phản hồi. Khi thất bại, các lỗi kiểm thử cụ thể và nhật ký chẩn đoán được định tuyến trở lại Tác nhân Di chuyển như đầu vào sửa chữa có mục tiêu, không phải là một "cái này không hoạt động, thử lại" mơ hồ. Tác nhân sở hữu bản vá tinh chỉnh logic cụ thể và ánh xạ phụ thuộc của nó dựa trên bằng chứng cụ thể về những gì đã hỏng, không phải là một lần thử lại chung chung từ đầu.
Chu kỳ bốn giai đoạn này lặp lại cho mỗi nhiệm vụ, với một giới hạn xác định. Một phiên bản hoạt động, đã được ghi chép lại của mẫu vòng lặp chính xác này chỉ định một điều kiện dừng như "không có tệp nào khớp với mẫu cũ nữa" cùng với số lần lặp tối đa cứng, trong một ví dụ đã được công bố, 200 lần lặp, sau đó hệ thống tự động dừng lại thay vì chạy vô thời hạn trên một nhiệm vụ không hội tụ.
Giới hạn đó cực kỳ quan trọng ở quy mô lớn. Nếu không có nó, một nhiệm vụ không thể hoàn thành về mặt cấu trúc, bởi vì bản thân thông số kỹ thuật không rõ ràng hoặc mẫu mục tiêu thực sự không có một tương đương rõ ràng, sẽ đốt cháy tài nguyên mãi mãi thay vì nổi lên như một thất bại cụ thể, có giới hạn mà con người thực sự có thể xem xét và giải quyết.
Tại Sao Đánh Giá Của Con Người Không Mở Rộng Quy Mô, Và Điều Gì Thay Thế Nó
Cần phải chính xác về lý do tại sao "không có con người đánh giá từng cái" thực sự là thiết kế an toàn hơn ở đây, không phải là một góc bị cắt.
Nghiên cứu so sánh đánh giá mã của tác nhân AI với đánh giá mã của con người đã tìm thấy một điều cụ thể và hữu ích: các nhận xét đánh giá do AI tạo ra dài gần gấp bảy lần mỗi dòng mã so với đánh giá của con người và tập trung gần như hoàn toàn vào cải tiến mã và phát hiện lỗi, trong khi đánh giá của con người tự nhiên lan rộng sang những thứ hoàn toàn khác, xây dựng sự hiểu biết chung, chuyển giao kiến thức, giao tiếp xã hội giữa các đồng đội. Sự qua lại trong đánh giá của con người thay đổi rất nhiều tùy thuộc vào loại phản hồi. Tương tác đánh giá AI-với-AI đồng nhất và cơ học hơn nhiều bất kể điều gì đang được gắn cờ.
Đọc đúng điều đó và nó nói lên một điều quan trọng: đánh giá của con người và xác minh của AI giỏi ở những thứ khác nhau về mặt cấu trúc. Yêu cầu một con người đánh giá 800 diff riêng lẻ với tốc độ và khối lượng mà một bầy tác nhân tạo ra không phải là một nâng cấp an toàn, đó là một nút thắt cổ chai tạo ra sự chấp thuận đóng dấu cao su, bởi vì không con người nào có thể duy trì sự giám sát thực sự trên khối lượng đó. Sự an toàn thực tế trong mẫu nhà máy tối không đến từ việc loại bỏ xác minh. Nó đến từ việc thay thế một loại xác minh, sự chú ý của con người chậm chạp, mệt mỏi, không nhất quán trải rộng trên hàng trăm diff lặp đi lặp lại, bằng một loại khác có thể mở rộng quy mô: xác nhận xây dựng và kiểm thử xác định tạo ra sự chặt chẽ chính xác trên diff 1 và diff 800, với không mệt mỏi về sự chú ý.
Đây cũng chính xác là lý do tại sao giai đoạn Bộ Lập Kế Hoạch sử dụng phân tích tĩnh dựa trên trình biên dịch thay vì phán đoán của LLM để sắp xếp thứ tự. Bất cứ nơi nào trong hệ thống, một kiểm tra xác định có thể thay thế một cuộc gọi phán đoán, nó nên làm như vậy, bởi vì các kiểm tra xác định là phần duy nhất của kiến trúc này thực sự có thể kiểm toán được sau đó. Bạn có thể phát lại chính xác những gì một trình phân tích tĩnh đã tìm thấy. Bạn không thể phát lại đầy đủ lý do tại sao một mô hình ngôn ngữ "cảm thấy" một thứ tự di chuyển cụ thể là đúng.
Những Gì Vẫn Cần Một Con Người, Và Ranh Giới Ở Đâu
Mẫu này không phải là "loại bỏ hoàn toàn con người và hy vọng." Mọi phiên bản đáng tin cậy đã được công bố của nó, hệ thống sản xuất của Google, nghiên cứu Môi trường-trong-Vòng lặp học thuật, sách dạy nấu ăn của riêng OpenAI, đều vẽ một ranh giới rõ ràng cho nơi phán đoán của con người vẫn là bắt buộc.
Phát hiện nhất quán từ một nghiên cứu định lượng về các cuộc di chuyển thư viện do tác nhân điều khiển: các tác nhân đáng tin cậy đạt được phạm vi di chuyển cao, xác định chính xác những thay đổi API nào là cần thiết, nhưng đặc biệt gặp khó khăn trong việc bảo toàn hành vi ứng dụng tổng thể trong các trường hợp phức tạp hơn, nơi một cuộc di chuyển thành công đòi hỏi sự hiểu biết về ý định, không chỉ khớp mẫu cú pháp. Khuyến nghị trực tiếp từ phát hiện đó là một điểm kiểm tra con người trong vòng lặp dành riêng cho tập hợp con các tệp mà xác minh xác định gắn cờ là rủi ro cao hoặc độ tin cậy thấp, không phải cho toàn bộ lô.
Trong thực tế, điều này tạo ra một hệ thống phân cấp. Các tệp mà phân tích phụ thuộc tĩnh phân loại là nhỏ, biệt lập tốt và đơn giản về mặt cấu trúc, phần lớn của bất kỳ cuộc di chuyển thực tế nào, chảy qua vòng lặp tự động hoàn toàn mà không có sự can thiệp nào của con người ngoài cổng xây dựng và kiểm thử xác định. Các tệp được gắn cờ là phức tạp, kết nối sâu sắc hoặc chạm vào logic quan trọng của doanh nghiệp được định tuyến đến một hàng đợi để đánh giá thực tế của con người trước khi hợp nhất, ngay cả bên trong một hệ thống tự động hoàn toàn.
Cách tiếp cận phân cấp này là phiên bản thực tế của "800 tác nhân, không con người nào đánh giá từng cái." Không phải là không có con người bao giờ nhìn vào bất cứ thứ gì. Đó là hệ thống được kiến trúc đặc biệt để định tuyến 95% công việc cơ học, rủi ro thấp thông qua tự động hóa hoàn toàn, trong khi tập trung nguồn lực khan hiếm, phán đoán thực sự của con người, chỉ vào một phần nhỏ các trường hợp mà nó thực sự thêm giá trị mà xác minh xác định không thể sao chép.
Xây Dựng Điều Này Cho Cơ Sở Mã Của Riêng Bạn
Mẫu này mở rộng quy mô xuống một cách sạch sẽ như khi nó mở rộng quy mô lên. Bốn vai trò tương tự áp dụng cho dù bạn đang chạy 800 tác nhân song song chống lại một cơ sở mã sản xuất lớn hay một số ít các nhiệm vụ di chuyển tuần tự chống lại một kho lưu trữ duy nhất.
Bắt đầu với Bộ Lập Kế Hoạch, và chống lại sự thôi thúc biến nó thành một LLM. Nếu quá trình di chuyển của bạn có bất kỳ loại cấu trúc phụ thuộc nào, import tệp, giao diện dùng chung, thứ tự xây dựng, hãy sử dụng công cụ phân tích tĩnh thực tế phù hợp với ngôn ngữ của bạn để xây dựng biểu đồ phụ thuộc đó một cách cơ học. Quyết định duy nhất này là quyết định có đòn bẩy cao nhất trong toàn bộ hệ thống, bởi vì mọi giai đoạn hạ nguồn đều kế thừa bất kỳ sai lầm sắp xếp thứ tự nào mà Bộ Lập Kế Hoạch mắc phải.
Phạm vi của mọi nhiệm vụ riêng lẻ càng hẹp càng tốt mà biểu đồ phụ thuộc cho phép. Một tệp, một mô-đun, một đơn vị thay đổi được giới hạn rõ ràng, với một bản tóm tắt rõ ràng mô tả chính xác những gì cần xảy ra và tại sao. Chống lại việc kết hợp nhiều thay đổi không liên quan vào một nhiệm vụ chỉ vì hiệu quả, bởi vì phạm vi hẹp là những gì làm cho phán đoán đạt hoặc không đạt của giai đoạn xác minh trở nên rõ ràng.
Cô lập việc thực thi của mọi nhiệm vụ. Một git worktree mới cho mỗi nhiệm vụ ở mức tối thiểu, một môi trường sandbox đầy đủ nếu bạn đang chạy cái này ở bất kỳ quy mô thực tế nào. Đây không phải là chi phí cơ sở hạ tầng tùy chọn. Đó là thứ làm cho việc song song hóa an toàn và làm cho sai lầm của một tác nhân duy nhất được chứa đựng thay vì lây lan.
Xây dựng xác minh xác định trước khi bạn xây dựng bất cứ thứ gì khác. Thành công biên dịch, tỷ lệ vượt qua bộ kiểm thử, kiểm tra tương đương hành vi nơi bạn có thể xây dựng chúng. Đây là thành phần thay thế "tác nhân có nói nó hoạt động không" bằng "nó có thực sự hoạt động không," và nó là thành phần duy nhất mà hầu hết các nỗ lực di chuyển tự xây dựng bỏ qua hoàn toàn, đó chính xác là lý do tại sao những nỗ lực đó thất bại ở bất kỳ quy mô có ý nghĩa nào.
Giới hạn vòng lặp thử lại một cách rõ ràng, với một con số, không phải một cảm giác. Xác định "nhiệm vụ này bị kẹt" trông như thế nào trước khi bạn chạy bất cứ thứ gì, và tự động định tuyến các nhiệm vụ bị kẹt đến một hàng đợi của con người thay vì để chúng tiêu thụ tài nguyên vô thời hạn hoặc, tệ hơn, âm thầm báo cáo thành công giả.
Bài Học Thực Sự Dưới Con Số Tiêu Đề
Dù con số thực tế chạy trong bất kỳ cuộc di chuyển quy mô lớn cụ thể nào, 800 tác nhân hay 80 hay 8.000, con số tiêu đề là phần ít thú vị nhất của câu chuyện. Phần thú vị là không có tác nhân nào trong số đó được tin tưởng riêng lẻ để quyết định liệu công việc của chính chúng có đúng hay không, và toàn bộ hệ thống được thiết kế xoay quanh sự không tin tưởng đó thay vì bất chấp nó.
Một nhà máy tối không chạy trong bóng tối vì không có ai theo dõi. Nó chạy trong bóng tối bởi vì việc theo dõi đã được chuyển hoàn toàn vào bên trong máy móc, vào các kiểm tra của trình biên dịch và bộ kiểm thử và biểu đồ phụ thuộc tạo ra cùng một câu trả lời chặt chẽ mọi lần, trên tệp một và tệp tám trăm, không mệt mỏi và không có sự không nhất quán đến từ việc yêu cầu một con người thực hiện cùng một cuộc gọi phán đoán lặp đi lặp lại hàng nghìn lần liên tiếp.
Đó là mẫu thực tế đằng sau mọi phiên bản của điều này đang hoạt động trong sản xuất ngay bây giờ. Không phải là sự tin tưởng táo bạo hơn vào các mô hình lớn hơn. Mà là một sự từ chối có kỷ luật hơn để cho bất kỳ thành phần đơn lẻ nào, con người hay AI, trở thành người phán xét duy nhất cho công việc của chính nó.
Theo dõi @cyrilxbt để biết thêm nội dung về AI
