Hãy tiếp tục chủ đề lớn về thiết kế các hệ thống AI, những khía cạnh nào của thế giới trước khi có AI mà chúng ta nên bắt chước và những khía cạnh nào chúng ta nên xử lý khác đi. Như trong last post, tôi sẽ giới thiệu một số lập luận khá quen thuộc với những người tạo ra các hệ thống máy tính, trong trường hợp này là sự kết hợp giữa các cân nhắc kỹ thuật và xã hội. Thật vậy, một phần quan trọng để phân phối các sản phẩm công nghệ hiệu quả không chỉ là viết code tốt mà còn là hiểu các yêu cầu và phản hồi lại chúng với các bên liên quan chính. Tôi sẽ cố gắng đưa ra một trường hợp liên quan cho một góc nhìn bức tranh lớn hơn về cách chúng ta nên cấu hình lại thế giới của mình để tận dụng AI.

Hardware-Software Codesign

Chúng ta có lẽ đều quen thuộc với sự khác biệt giữa computer hardware và software. Hardware là những thứ vật lý có thiết kế thay đổi tương đối ít thường xuyên, và software là các instruction thay đổi nhanh chóng được load vào hardware. Trong trường hợp programmable hardware như một CPU hoặc GPU, dịch vụ chính mà mỗi thế hệ cung cấp là chạy các program bằng một machine language cụ thể. Nếu bạn muốn sử dụng software machine language mới nhất và tốt nhất, nhưng tất cả những gì bạn có là một phần programmable hardware đi sau vài thế hệ, bạn đã gặp vận xui. Chúng ta có thể có được một trực giác bằng cách tương tự như con người nói các ngôn ngữ tự nhiên. Bất kỳ bên nào “ly khai” khỏi một ngôn ngữ chung đều phá hỏng mọi thứ, nhưng nếu cả hai bên thay đổi ngôn ngữ cùng một lúc, chúng ta sẽ ổn thôi.

Hãy xem xét các quy trình xã hội dẫn dắt hardware và software tiến hóa theo thời gian. Thông thường các sản phẩm hardware và software được sản xuất bởi các đội ngũ khác nhau, cho dù chúng ta đang nói về sản phẩm thương mại hay open source. Tất cả chúng ta có lẽ đều đã trải qua việc làm việc trong các đội ngũ có mục tiêu tương đối hẹp. Các incentive được thiết lập xung quanh việc thành công trong ranh giới tự nhiên của một dự án. Những người cải tiến một phần mềm software package rất hào hứng khi thấy user đón nhận các tính năng mới, và nếu các tính năng đó phụ thuộc vào chức năng hardware mới vốn đang là tưởng tượng vào thời điểm hiện tại, thì tháng sau sẽ không có nhiều happy user như vậy, điều này có thể đồng nghĩa với việc startup xây dựng software package đó thất bại trong vòng gọi vốn tiếp theo. Tương tự, các engineer đằng sau hardware chỉ có thể chắc chắn rằng họ đã làm tốt công việc bằng cách chạy nhiều software program, và khi các engineer nói trên thêm một tính năng mới vào hardware, đó là một trở ngại thực sự nếu không có sẵn một cơ sở software hiện tại sử dụng tính năng đó làm test case. Kết quả là, chế độ tiến hóa điển hình nhất trong một hệ sinh thái hardware-software là sự cải tiến khiêm tốn lặp đi lặp lại bởi từng đội ngũ tại một thời điểm, mỗi lần theo một cách nào đó không yêu cầu công việc tương ứng từ phía bên kia. Trong thế giới CPU, biểu hiện của vấn đề này là các nhà thiết kế hardware đã chú trọng quá mức vào các SPEC benchmark, các chương trình được tiêu chuẩn hóa mà mọi người được cho là có thể chạy nhanh chóng, đồng thời các nhà thiết kế programming-language có thể muốn đổi mới với các tính năng cơ bản mới nhưng lại thấy mình bị bỏ qua bởi các nhà thiết kế hardware, những người có thể thăng tiến sự nghiệp tốt hơn bằng cách tăng tốc các chương trình cũ kỹ đó.

Chúng ta có thể thấy rằng phải mất rất nhiều bước để đạt được điểm lý tưởng ở góc trên bên phải của biểu đồ (mang tính cách điệu cao!). Hai trục đại diện cho các cảm quan mơ hồ về việc cải thiện chất lượng, tương ứng cho hardware và software. Chúng chủ yếu cần được cải thiện độc lập, không có nhiều sự trợ giúp từ bên kia. Tuy nhiên, đôi khi một bên “vô tình” giới thiệu một tính năng mới hóa ra lại đóng vai trò quyết định cho việc cho phép đổi mới ở phía bên kia. Với đủ nhiều sự cố ngẫu nhiên như vậy tích lũy theo thời gian, chúng ta có thể đủ may mắn để hội tụ về thiết kế tổng thể lý tưởng.

Hãy tưởng tượng bằng cách nào đó có đủ không gian thở cho các hardware và software engineer tự nhốt mình trong phòng họp trong một tháng. Mục tiêu của họ là thiết kế toàn bộ hệ sinh thái một cách toàn diện (holistically). Đối với bất kỳ ý tưởng tính năng tuyệt vời nào, việc nó đòi hỏi quá nhiều thay đổi từ các phần khác của hệ thống sẽ không còn là một lý do hợp lệ nữa. Đội ngũ thực hiện một công việc đầy tính thẩm mỹ mà chúng tôi gọi trong ngành là hardware-software codesign.

Tiếp tục diễn giải lỏng lẻo của chúng ta về các biểu đồ này, một mũi tên dài đó có thể mất nhiều thời gian hơn đáng kể để mang lại bất kỳ kết quả nào, so với bất kỳ mũi tên ngắn hơn nhiều nào trong biểu đồ trước. Tuy nhiên, khi chúng ta kiểm tra lại sau khoảng thời gian cần thiết cho vài bước của phương pháp tăng dần (incremental), chúng ta có thể thấy rằng chúng ta đã đạt được một hệ thống thống nhất hoạt động tốt hơn nhiều cho tất cả mọi người.

Cuộc cách mạng AI hiện tại thực sự phụ thuộc vào những bước nhảy vọt tương đối lớn của loại hình codesign này. Nvidia là công ty dẫn đầu thị trường về GPU, vốn thúc đẩy sự trỗi dậy của deep learning. Không còn nghi ngờ gì nữa, Nvidia xuất sắc trong việc tạo ra hardware để chạy loại khối lượng công việc này. Tuy nhiên, người ta thường tin rằng lợi thế trung tâm thực sự giúp Nvidia thống trị thị trường là framework lập trình CUDA của họ. Các chương trình CUDA thường được nhúng bên trong các programming language cũ hơn như C++, so với việc nó vẫn mang một sắc thái của sự tăng dần (incrementality). Tuy nhiên, nó đã giới thiệu một phong cách parallel programming dễ chịu hơn, nơi nhiều thứ diễn ra cùng một lúc trong một software program; và CUDA chỉ tương thích với phần cứng Nvidia, thúc đẩy các programmer chỉ mua sản phẩm từ Nvidia nếu họ là người hâm mộ CUDA.

Với việc CUDA và GPU được phát triển tại cùng một công ty (Nvidia), việc điều phối các đội ngũ để thực hiện codesign là khả thi. Việc phát triển CUDA sẽ khó khăn nếu không có sự hợp tác từ các GPU engineer để thêm các tính năng mà code CUDA sau khi được compile muốn gọi. Ngược lại, việc đưa cho một programmer một GPU mới toanh sáng bóng và nói rằng nó có những tính năng sáng tạo nhất là điều rất tốt; nhưng nếu programmer đó không thể tìm ra cách viết code để sử dụng các tính năng đó thì không có lợi ích gì, và các CUDA tool có thể tự động hóa việc generate mã máy (machine code) cần thiết, giúp programmer tránh khỏi việc phải tìm hiểu các chi tiết mới tẻ nhạt.

Điểm mấu chốt chung là chúng ta nên đấu tranh chống lại cái nhìn hạn hẹp của mình về những gì tạo nên một thiết kế tốt cho một sản phẩm cụ thể, đôi khi lùi lại để nghĩ về bức tranh lớn và đầu tư vào các bản sửa đổi chậm hơn vốn sửa đổi nhiều phần chính cùng một lúc.

Autonomous Vehicles

Một trong những ứng dụng AI đầu tiên của thế kỷ 21 có “yếu tố bất ngờ” đáng kể là autonomous vehicles, bắt đầu với DARPA Grand Challenge và phát triển đến việc triển khai rộng rãi ngày nay của các xe Waymo mà bạn có thể gọi bằng ứng dụng di động. Bản thân tôi cũng đang cổ vũ cho những chiếc xe đó đến thành phố của tôi, nhưng tôi muốn gợi ý những bước tiếp theo tiềm năng thậm chí còn thú vị hơn, và tôi sẽ sử dụng phép ẩn dụ về codesign để lập luận cho trường hợp của mình.

Các con đường có thể là môi trường phức tạp để điều hướng an toàn. Ngay cả khi một xe tự hành (autonomous car) xử lý an toàn 99% kịch bản, các tai nạn khủng khiếp trong 1% còn lại sẽ phá hỏng việc áp dụng. Để cụ thể, tôi sẽ lấy ví dụ về một kịch bản hiếm gặp nhưng liên quan đến an toàn là chạm trán một đàn gà tây băng qua đường, điều mà mọi autonomous car cần lập kế hoạch đối phó ở Vùng Boston. (Một số độc giả sẽ cho rằng tôi đang đùa, nhưng không, tôi đang mô tả bầu không khí giống như đi săn của chúng tôi một cách trung thực.) Có vẻ như chúng ta có một thách thức AI cực kỳ khó để train phần mềm biết cách đối phó an toàn với tất cả các kịch bản này mà các tài xế con người coi là đương nhiên.

Quan điểm chính thống ngày nay nói rằng, chấp nhận thử thách! Chúng ta sẽ liên tục tối ưu hóa hiệu năng (performance-optimize) cho AI hardware và software của mình, để nó có thể thực thi các logic ngày càng phức tạp để đối phó với các kịch bản lái xe. Quan trọng hơn nữa (và là trung tâm của quan điểm chính thống), chúng ta sẽ tiếp tục thu thập ngày càng nhiều training data, được sử dụng để tạo ra phần mềm thông minh thế hệ tiếp theo. Xe tự hành (autonomous car) sẽ mắc lỗi, nhưng mọi lỗi lầm đều đóng góp vào việc tránh lặp lại chính nó trong thế hệ tiếp theo.

Waymo và các đối thủ cạnh tranh của họ đã chứng minh rằng cách tiếp cận này hoạt động khá tốt, mặc dù với chi phí kỹ thuật (engineering cost) khá cao. Khi chúng ta đọc về việc các công ty công nghệ xây dựng các data center với tốc độ chóng mặt, đó là để xây dựng năng lượng tính toán (compute power) nhằm hỗ trợ loại training này. Nếu mọi thứ khác đều tương đương, sẽ tốt hơn nếu chúng ta không cần phải xử lý hàng đống dữ liệu lái xe để train phần mềm tự hành tốt hơn.

Tôi cũng nên nói rõ rằng tôi sắp tham gia vào một số buổi brainstorm nơi chúng ta không đi sâu vào chi tiết về cách các xã hội đưa ra quyết định về cơ sở hạ tầng. Đó là tinh thần của codesign, tưởng tượng các cơ hội từ những thay đổi phối hợp, nhưng chỉ riêng việc viện dẫn codesign không giúp ích gì cho chúng ta về mặt chính trị trong việc thu hút mọi người tham gia. Các engineer đằng sau autonomous car đang làm rất tốt việc đối phó với các khía cạnh của cơ sở hạ tầng giao thông vốn dĩ dường như khó sửa đổi ngày nay. Chúng ta chỉ nên sẵn sàng nắm bắt các cơ hội nhìn về phía trước.

Tôi đang lập luận rằng vấn đề của chúng ta là giả định rằng môi trường lái xe vẫn giữ nguyên, và chúng ta chỉ bắt đầu đưa vào ngày càng nhiều autonomous car. Điều gì sẽ xảy ra nếu chúng ta đơn giản hóa đáng kể, theo một số cách, môi trường mà các phương tiện đi qua, đồng thời khiến nó phức tạp hơn theo một số cách vốn sẽ thách thức các tài xế con người? Cụ thể, điều gì sẽ xảy ra nếu chúng ta chuyển sang một lưới đường ray kiểu xe lửa, tách biệt vật lý với không gian nơi con người (và gà tây) có quyền tự do đi lại? Việc đưa các autonomous car vào môi trường lái xe ngày nay là một thách thức, và việc đưa các tài xế con người vào mạng lưới đường ray giả định của chúng ta là rủi ro, nhưng chúng ta có thể tiếp cận bài toán này theo kiểu codesign và thực hiện cả hai bước di chuyển cùng một lúc. (Cách tiếp cận này lần đầu tiên được đề xuất vào những năm 1950 dưới tiêu đề personal rapid transit, và mặc dù nó đã không thành công, nhưng có vẻ đáng xem xét liệu những cải tiến công nghệ trong thời gian qua có làm thay đổi tính khả thi hay không.)

Tất nhiên, có rất nhiều ví dụ trước đây về việc tạo ra môi trường đơn giản hóa cho các phương tiện. Một mạng lưới tàu điện ngầm là một ví dụ tốt, với các biện pháp bảo vệ vật lý để giữ cho mọi người không chạy vào đường hầm. Các mạng lưới tàu hỏa trên mặt đất thậm chí còn lâu đời hơn là một ví dụ ít cực đoan hơn, nơi người đi bộ hoặc người lái xe dễ dàng đi lạc vào đường ray. Các phần của mạng lưới đường bộ hiện tại của chúng ta thậm chí có thể được biến thành một hệ thống theo tinh thần đó, nơi, chẳng hạn, con người đi bộ trong đó là bất hợp pháp. Lợi thế quan trọng của phong cách này là một autonomous vehicle chỉ cần nhận thấy rằng có điều gì đó bất thường đang diễn ra để nó có thể kích hoạt chế độ an toàn thất bại fail-safe như dừng lại an toàn (tại thời điểm đó cảnh sát sẽ ập đến, khôi phục các điều kiện dự kiến, và phạt bất kỳ ai chịu trách nhiệm cho sự gián đoạn). Phương tiện đó không cần phải hiểu các sắc thái của các loại kịch bản bất thường khác nhau (ví dụ: gà tây so với sự trỗi dậy của Cthulhu). Tôi nên đề cập ở đây rằng phần mềm autonomous-vehicle đã được triển khai đã cố gắng xác định các tình huống kỳ lạ và kích hoạt hành vi fail-safe (bạn có nhớ vụ mất điện gần đây ở San Francisco và cách nó làm nhiều xe Waymo sợ hãi đến mức phải gọi về trung tâm để xin phép con người tiếp tục?), nhưng điểm mấu chốt là bài toán phát hiện sẽ trở nên đơn giản hơn nhiều trong các môi trường được xây dựng có mục đích.

Chúng ta thậm chí có thể thiết kế môi trường và các tiêu chuẩn cho chính các phương tiện để đơn giản hóa bài toán thị giác (vision problem) nhiều nhất có thể. Chúng ta muốn giảm thiểu độ phức tạp tính toán (computational complexity) của cả việc giám sát các phương tiện khác và phát hiện khi có điều gì đó không ổn. Ví dụ, các phương tiện có thể được áp dụng các tiêu chuẩn chặt chẽ về màu sắc và hình dạng, đặc biệt là tránh các hình dạng phức tạp.

Và, như tôi đã đề cập đến các hệ thống giao thông công cộng đã được thiết lập ở trên, tôi nên nhấn mạnh rằng kịch bản này có thể hỗ trợ sự thuận tiện lớn hơn nhiều so với những gì chúng ta quen dùng từ giao thông công cộng. Giả định rằng tất cả các autonomous vehicle được yêu cầu phối hợp qua mạng và có lẽ thậm chí tham gia vào một giao thức định tuyến routing protocol chung. Khi đó, chúng ta không cần làm việc với bất kỳ thứ gì tương tự như một tập hợp nhỏ, cố định các tuyến tàu điện ngầm. Các phương tiện trên đường ray có thể vẽ ra các con đường thích hợp cho người lái của chúng trong khi phối hợp để tránh va chạm. Chúng ta tránh được những sự kém hiệu quả gây khó chịu như một hàng xe dừng trước đèn giao thông, di chuyển lại rất chậm khi đèn thay đổi, vì mỗi tài xế đều có độ trễ thời gian phản ứng từ khi nhận thấy chiếc xe ngay phía trước đã di chuyển về phía trước đủ xa. Với sự phối hợp tập trung trong một kịch bản tương tự, tất cả các autonomous vehicle có thể bắt đầu di chuyển cùng một lúc.

Lợi ích trung tâm của đường ray đối với chúng ta là chúng làm giảm các bậc tự do (reduce degrees of freedom), cho phép mô hình hóa đơn giản hơn bởi các hệ thống thị giác và điều khiển (vision and control systems). Có lẽ chúng ta hoàn toàn không cần xử lý thị giác (vision processing) bởi các phương tiện, và chúng ta chỉ dựa vào các cảm biến trên đường ray cùng với các camera thông minh cố định để theo dõi các tình huống kỳ lạ. (Nhân tiện, có một phần thưởng thú vị mà tôi học được từ cuốn Sustainable Energy – Without the Hot Air, của cố Prof. David J. C. MacKay: rằng việc di chuyển trên đường ray về mặt cơ bản tiết kiệm năng lượng hơn trên đường bộ, vì lốp xe ô tô thông thường trên đường bộ phải đối mặt với lực cản lăn lớn gấp khoảng năm lần so với tàu hỏa chạy bằng thép trên thép.) Tuy nhiên, chúng ta vẫn có thể nhận ra những lợi ích tương tự chỉ bằng cách bao quanh các con đường như chúng ta biết ngày nay, để chúng trở thành (1) môi trường dễ dự đoán hơn với (2) các bài test tương đối dễ dàng khi có điều gì đó khá bất thường xảy ra. Vẫn sẽ còn một yếu tố cybersecurity về những kẻ thù cố gắng tìm cách làm xáo trộn các môi trường đó một cách nguy hiểm mà không bị phát hiện, nhưng rủi ro đó rõ ràng là không lớn hơn so với các autonomous car trên các con đường ngày nay.

Takeaway

Ví dụ này nhằm mục đích minh họa việc bắt gặp một hệ thống có các phần khác nhau, tập trung vào một phần và bài toán điều khiển của nó, nhận thấy rằng nó đại diện cho một bài toán cực kỳ khó đối với AI. Một mặt, chúng ta có thể ăn mừng cơ hội thử thách bản thân và xây dựng AI ngày càng tốt hơn, có khả năng giải quyết tốt hơn những bài toán hóc búa đó. Mặt khác, khi đội lên chiếc mũ codesign của mình, chúng ta có thể tưởng tượng các thay đổi ở cấp độ hệ thống giúp loại bỏ nhu cầu giải quyết các bài toán đó, thay thế chúng bằng những bài toán dễ hơn. Những bài toán dễ hơn sẽ không chỉ giúp chúng ta thiết kế các giải pháp dễ dàng hơn. Chúng cũng dẫn đến các thiết bị vật lý có chi phí thấp hơn và sử dụng ít năng lượng hơn.

Trong bài viết này, chất nền (substrate) mà chúng ta bắt đầu coi là đương nhiên là các con đường không có rào chắn. Tôi sẽ thảo luận trong bài viết tiếp theo về một substrate khác mà chúng ta coi là đương nhiên ở cấp độ thậm chí còn cơ bản hơn, và đó cũng sẽ là một substrate trung tâm hơn đối với sự bùng nổ tiến bộ gần đây về generative AI.