How METR measures Long Tasks and Experienced Open Source Dev Productivity - Joel Becker, METR

• Tốc độ tăng trưởng tài nguyên điện toán (compute) có mối quan hệ nhân quả tỷ lệ thuận với khả năng AI, nghĩa là sự chậm lại trong việc cung cấp compute sẽ dẫn đến sự chậm trễ đáng kể trong phát triển AI.
• Các yếu tố chính hạn chế tăng trưởng compute bao gồm giới hạn vật lý (phần cứng) và đặc biệt là giới hạn chi phí, vì các công ty và quốc gia chỉ có thể chi tiêu một lượng nhất định.
• Mặc dù các đường log-tuyến tính thường là công cụ dự báo hiệu quả cho AI, nhưng năng suất của tác nhân AI có thể bị ảnh hưởng bởi đường cong chữ J trong việc làm quen với công cụ và sự khác biệt giữa nhận thức về năng suất với hiệu quả thực tế.

• Mối quan hệ nhân quả Compute-AI: Có một mối quan hệ nhân quả tỷ lệ thuận giữa tốc độ tăng trưởng tài nguyên điện toán (compute) và tốc độ tăng trưởng "đường chân trời thời gian" của khả năng AI, nơi sự chậm lại của compute sẽ kéo theo sự chậm lại của AI.
• Hạn chế tăng trưởng Compute: Các giới hạn vật lý (phần cứng) và chi phí là những rào cản chính đối với sự tăng trưởng liên tục của tài nguyên điện toán, với giới hạn chi phí được coi là yếu tố ảnh hưởng lớn hơn trong ngắn hạn.
• Dự đoán bằng Log-linear: Các biểu đồ log-tuyến tính đã chứng tỏ là công cụ dự báo đáng tin cậy cho tiến bộ AI qua nhiều bậc độ lớn và được kỳ vọng sẽ tiếp tục như vậy trừ khi có sự gián đoạn đáng kể.
• Thách thức đo lường khả năng AI: "Đường chân trời thời gian" có thể không phải lúc nào cũng là thước đo hữu ích, đặc biệt khi các mô hình hoàn thành tác vụ rất nhanh, và độ tin cậy của AI trở nên quan trọng hơn thời gian truy cập của con người.
• Đường cong chữ J trong chấp nhận AI: Các nhà phát triển thường trải qua "đường cong chữ J" khi áp dụng tác nhân AI, ban đầu chậm lại trước khi đạt được năng suất cao hơn sau vài tháng làm quen với công cụ.
• Đánh giá năng suất không đáng tin cậy: Các ước tính về thời gian hoàn thành tác vụ của con người thường không chính xác; nhà phát triển có thể cảm thấy năng suất hơn khi thực tế họ không nhanh hơn, làm cho việc đo lường hiệu quả AI trở nên phức tạp.
• Ảnh hưởng của kinh nghiệm và Codebase: Kinh nghiệm ban đầu với AI hoặc kích thước codebase lớn không nhất thiết tương quan với mức độ "tăng tốc" từ AI; sự quen thuộc với công cụ và ngữ cảnh dự án (ví dụ: codebase kế thừa vs. mã nguồn mở) là yếu tố quan trọng hơn.
• Nhu cầu tối ưu hóa công cụ AI: Việc học cách yêu cầu AI thực hiện các tác vụ và thu hẹp phạm vi vấn đề là rất quan trọng để tối đa hóa hiệu quả của tác nhân AI, đặc biệt là khi làm việc với các codebase không quen thuộc hoặc phức tạp.

• Compute — Tài nguyên điện toán
• Model — Mô hình
• Time horizon — Đường chân trời thời gian
• Metric / Measure — Số liệu / Thước đo
• Physical / Hardware limitations — Hạn chế vật lý / phần cứng
• AI capability — Khả năng AI
• Log-linear graph — Biểu đồ log-tuyến tính
• Tool — Công cụ
• Agent — Tác nhân
• Pull Request — Pull Request
• J-curve — Đường cong chữ J
• Time estimation — Ước tính thời gian
• Codebase / Code repository / Repo — Cơ sở mã / Kho lưu trữ mã nguồn / Repo
• Acceleration / Speed-up — Tăng tốc
• Large Language Model (LLM) — Mô hình Ngôn ngữ Lớn
• Integrated Development Environment (IDE) — Môi trường phát triển tích hợp (IDE)

Dưới đây là phần biên dịch và sửa đổi của đoạn transcript:

Mối Quan Hệ Giữa Tài Nguyên Điện Toán và Khả Năng AI

Đây là một lập luận rất đơn giản. Nếu bạn nhìn vào sự tiêu thụ tài nguyên điện toán theo thời gian – đây có thể là chi phí Nghiên cứu & Phát triển cho compute, đây có thể là các thử nghiệm, compute để đào tạo mô hình, hoặc bất cứ thứ gì một phòng thí nghiệm cụ thể đang sử dụng – nó trông như thế này, không có gì ngạc nhiên. Nếu bạn có một biểu đồ khác về đường chân trời thời gian logarit, giả sử điều này phù hợp với số liệu/thước đo mà nhiều người trong số các bạn đã thấy trên Twitter theo thời gian, nó trông như vậy.

Giả sử rằng đây không chỉ là một sự trùng hợp ngẫu nhiên, mà những yếu tố này có mối quan hệ nhân quả tỷ lệ thuận, theo nghĩa là nếu tốc độ tăng trưởng compute giảm một nửa, thì tốc độ tăng trưởng đường chân trời thời gian cũng giảm một nửa. Vì mục đích tranh luận, giả sử rằng bắt đầu từ khoảng năm 2028, đường cong compute bắt đầu uốn cong như vậy – điều này sẽ không có sự tăng trưởng nào, và đây sẽ là tốc độ tăng trưởng ban đầu, khoảng một nửa. Khi đó, nếu chúng có mối quan hệ nhân quả, và đặc biệt là tỷ lệ thuận với nhau, bạn sẽ kỳ vọng điều này diễn ra tương tự. Và đối với một cột mốc nào đó mà bạn quan tâm, giả sử ở đây chúng ta có một đường chân trời công việc một tháng, thì sự chậm trễ tiềm ẩn trong khả năng AI là rất lớn.

Các Yếu Tố Hạn Chế Tăng Trưởng Tài Nguyên Điện Toán

Vậy tại sao nhiều người lại cho rằng có thể có sự chậm lại trong tăng trưởng compute? Tôi không phải chuyên gia về những dự báo đó, nhưng tôi nghĩ các lập luận có vẻ khá mạnh mẽ đối với tôi. Một là những hạn chế vật lý mà chúng ta có thể gặp phải, các hạn chế về phần cứng như đã đề cập, hoặc có nhiều yếu tố khác mà Ebok đã báo cáo hôm nay. Họ xem xét tất cả những điều này dường như không gây ảnh hưởng đến năm 2030, nhưng có thể gây ảnh hưởng vào một thời điểm nào đó sau năm 2030.

Tôi nghĩ rằng khả năng lớn hơn là do giới hạn về chi phí. Ví dụ, các công ty công nghệ lớn chỉ có thể chi tiêu một lượng nhất định tại một thời điểm; các quốc gia lớn cũng chỉ có thể chi tiêu một lượng nhất định. Tôi đoán có một số kịch bản mà bạn có thể tiếp tục tăng trưởng, nhưng điều đó dường như tự nhiên ngụ ý một sự chậm lại. Và điểm bổ sung mà bài báo này đang cố gắng đưa ra là, dưới một giả định rất dễ gây tranh cãi nhưng tiêu chuẩn từ kinh tế học, bạn thực sự nên kỳ vọng những yếu tố này có mối quan hệ nhân quả tỷ lệ thuận. Tôi nghĩ cụ thể, bạn nên kỳ vọng chúng có mối quan hệ nhân quả tỷ lệ thuận trong phạm vi hoặc trong khoảng thời gian mà phần mềm và điểm kỳ dị mềm chưa thể xảy ra. Và đó là một điều khác, tôi nghĩ, để xem xét. Nhưng ít nhất trong kịch bản "kinh doanh như bình thường" này, hoặc cho đến khi kịch bản đó không còn phù hợp, tôi nghĩ đây có thể là một mô hình hợp lý và không ngụ ý bất kỳ loại khả năng nào trong tương lai gần.

Dự Đoán Khả Năng AI trong Tương Lai

Tôi hoàn toàn không có kế hoạch gì cho buổi này. Điều đó cũng phù hợp với tôi. Chúng ta không có một tiến bộ công nghệ nào cải thiện đáng kể khả năng so với hiện trạng. Giống như một tiến bộ công nghệ dễ dự đoán hơn, phải không? Vâng, ý tôi là, tất cả các dự đoán, bạn biết đấy, đều giả định không có gì bất ngờ. Vâng, tôi nghĩ rằng đường chân trời thời gian hoặc nói chung trong AI, các đường thẳng trên biểu đồ log-tuyến tính đã là một công cụ dự báo bị đánh giá thấp. Chúng đã hoạt động cực kỳ tốt qua nhiều bậc độ lớn. Tôi nghĩ rằng việc có kỳ vọng mặc định rằng các đường log-tuyến tính sẽ tiếp tục qua, khoảng cùng số bậc độ lớn, trừ khi có một sự gián đoạn đáng kể nào đó trong các yếu tố đầu vào là hợp lý. Vâng, tất nhiên, về mặt tích cực, có thể có điều gì đó khá kịch tính. Software and easy humanities là điều đầu tiên hiện lên trong tâm trí tôi, nhưng, bạn biết đấy, một khoảnh khắc thay đổi mang tính cách mạng khác dường như cũng là một khả năng. Chắc chắn rồi.

Khó Khăn trong Đánh Giá Khả Năng AI

Tất nhiên, một trong những vấn đề với việc kiểm thử điều này sẽ là, giống như, tôi nghĩ hầu hết các bài kiểm thử mà bạn có sẽ, một vài bài kiểm thử sẽ, bạn biết đấy, vượt quá lượng thời gian tối đa có thể mà các bài kiểm thử đó có thể mất tại một thời điểm nào đó. Tập hợp đánh giá. Vâng, vì vậy tôi nghĩ rằng, bạn biết đấy, có một số cách để giải quyết vấn đề này mà chúng tôi đang nghiên cứu. Tôi rất hào hứng khi nói về điều đó. Chúng sẽ cảm thấy khá sơ khai. Nhưng vâng, bạn biết đấy, tôi nghĩ nó đúng. Vì vậy, đó là nếu đường chân trời thời gian đang tăng gấp đôi, bạn biết đấy, cuối cùng bạn sẽ thấy rằng thời gian tăng gấp đôi thực sự, bạn không thể tạo ra các bài kiểm thử đủ dài trong thế giới phát triển. Cũng có thể là chúng ta thực sự đến một điểm mà đường chân trời thời gian không còn là một số liệu/thước đo hữu ích nữa, bởi vì thực ra, bạn biết đấy, bạn muốn thời gian giảm, giống như bạn muốn cùng một kết quả. Tôi không biết. Ồ, nhưng bạn muốn độ tin cậy cao hơn ở một đường chân trời thời gian thấp hơn.

Một điều cần nói về đường chân trời thời gian là có hai khái niệm về thời gian ở đây: giống như một yếu tố thời gian truy cập của con người. Giống như, tôi không thể hiểu được thời gian mà mô hình đang hoạt động, tôi nghĩ bạn nên coi nó xấp xỉ bằng không. Nó không thực sự bằng không. Chúng đang thực hiện các hành động. Chúng phần lớn hoàn thành công việc thành công của mình khá sớm ở mức độ chúng sẽ thành công trong các tác vụ. Vì vậy, tôi đoán rằng sẽ tiếp tục là trường hợp không có quá nhiều nỗ lực bổ sung trong việc khiến các mô hình hoàn thành tác vụ nhanh hơn, mặc dù độ tin cậy thì rất quan trọng, rõ ràng. Vì vậy, hầu hết đó là con người, giống như vòng lặp lặp lại, chứ không phải thời gian dành cho vòng lặp tương tác người-máy. Con người đang làm việc mà không có AI và AI đang làm việc mà không có con người. Vì vậy, con người, tôi đoán, đều là con người. Vì vậy, tôi nghĩ khi bạn nghĩ như một người mới giống như trang web. Vâng, vâng, vâng, vâng. Vâng. Tuyệt. Có bất kỳ câu hỏi nào về công việc của tôi không? Tôi có thể trình bày một số điều sắp tới mà chúng tôi đang hào hứng nếu mọi người cũng hào hứng về những điều đó.

Ảnh Hưởng của Tác Nhân AI đến Năng suất Phát triển

Vâng, tôi đã có một điểm nảy ra trong đầu, giống như việc triển khai. Vâng, một trong những người cố vấn. Vâng, vâng. Vâng. Một điều tôi nghĩ bạn đã đề cập một chút trong bài báo, đó là liệu sự quen thuộc có phải là một yếu tố gây nhiễu hay không. Mặc dù một trong những điều với công cụ... Bạn có công cụ và sau này là yếu tố gây nhiễu. Và tất nhiên, bạn cũng đã đề cập rằng độ bền của công cụ đã thay đổi đáng kể. Nhưng rất nhiều bài thuyết trình thú vị từ Meta tại Hội nghị Thượng đỉnh Kỹ thuật của Ủy ban Phát triển có ở đây. Và họ đã làm điều này. Họ có lẽ là cơ sở hạ tầng tốt nhất để đo lường định lượng trải nghiệm sử dụng công cụ trên thế giới của bất kỳ công ty nào. Và họ có thể cho bạn biết về cơ bản mất bao lâu để tạo một Pull Request. Về cơ bản họ gọi đó là DASA data. Nhưng mất bao nhiêu nỗ lực thực tế, nỗ lực thời gian của con người để tạo một Pull Request? Và điều họ thấy là họ thấy một đường cong chữ J khi họ cấp tác nhân cho mọi người. Và đường cong chữ J đó là, tôi không biết bao lâu, giống như ba tháng hoặc sáu tháng. Và vì vậy, một trong những điều tôi cũng tự hỏi là, sẽ rất thú vị nếu có một ngưỡng về mức độ quen thuộc mà người đó có, giống như cách họ đã sử dụng điều này như công cụ sử dụng chính hàng ngày của họ trong một khoảng thời gian vài tháng. Và nếu có một loại ngưỡng xảy ra khi họ đạt được mức độ quen thuộc trong các nhóm. Vâng.

Độ Chính Xác của Ước Tính Năng Suất

Tôi hoàn toàn đồng ý với việc không chỉ trong trường hợp này, mà trong nhiều trường hợp có liên quan đến kinh tế ngoài kỹ thuật phần mềm, các giải thích về đường cong chữ J là có thật. Tôi nghĩ, vâng. Chắc chắn rồi, không chỉ các nhà phát triển. Thử nghiệm với công cụ. Bạn có xu hướng chậm hơn lần đầu tiên bạn thử nghiệm với công cụ. Nhưng nếu bạn đang làm điều này, bạn có một số khoản đầu tư cần thiết. Sau này, bạn có thể thành thạo hơn với công cụ, hoặc trong trường hợp AI, có lẽ bạn chỉ đơn giản là kỳ vọng các mô hình sẽ trở nên tốt hơn. Và vì vậy, ngay cả khi bạn không trở nên thành thạo hơn, nó sẽ giống như loại điều bạn muốn làm. Những giải thích đó nói chung đều có lý đối với tôi. Tôi có thể đưa ra cho bạn một số lý do tại sao tôi có trường học. Tôi nghĩ một điều cần nói là điều gì đó cần nói? Về cơ bản, chúng tôi đang tiếp tục công việc này, và chúng ta sẽ xem. Một điều khác cần nói là, về mặt định lượng, sự khác biệt giữa cái này và cái kia, rất lớn. Tôi nghĩ, đường cong chữ J đang giải thích bao nhiêu? Tôi nghĩ nó không giải thích nhiều đến vậy.

Để tôi giải thích điều đó. Trở nên thành thạo, bạn vừa tìm thấy trong một số nghiên cứu ở Virginia rằng câu hỏi duy nhất bạn không thể hỏi mọi người trong một cuộc khảo sát là "một tác vụ mất bao lâu?". Bạn có thể hỏi mọi người "bạn cảm thấy năng suất hơn bao nhiêu?" và họ sẽ đưa ra câu trả lời chính xác. Cốt lõi của phản hồi định lượng này: bất cứ ai ước tính lượng thời gian mà một việc mất, họ hầu như luôn sai. Vì vậy, khi tôi chia sẻ điều này với các đồng nghiệp của mình, tôi đã nghĩ, "OK, tôi không ngạc nhiên về điều đó chút nào." Nhưng điều thú vị là mức độ chậm lại là bao nhiêu? Đó là điều ở đó. Vâng, vâng, vâng. Điểm được ghi nhận tốt. Điều đó rất có lý. Tôi cũng vậy. Vì vậy, tôi nghĩ chúng tôi, bất chấp điều này, đã quan tâm đến ước tính thời gian vì chúng tôi quan tâm đến việc cung cấp. Ý tôi là, tôi nghĩ nhận thức về mặt cảm giác, tôi không nghĩ điều đó cũng liên quan đến bạn, bởi vì khía cạnh nhận thức cũng là khía cạnh cao. Vì vậy, các nhà phát triển sẽ nói với bạn rằng họ nhanh hơn khi họ không nhanh. Và tôi nghĩ điều đó đáng để biết. Và ở mức độ mà chúng tôi quan tâm đến việc đo lường khả năng, bản chất thời gian của các vụ nổ khả năng hoặc kiểu tự động hóa Nghiên cứu & Phát triển, một số liệu/thước đo thường được đề xuất để làm điều này chỉ là hỏi các nhà phát triển hoặc nhà nghiên cứu xem họ đã được tăng tốc bao nhiêu. Và chính vì những lý do đã chỉ ra, tôi không đặt nhiều niềm tin vào những ước tính đó. Thật tốt khi thấy điều đó như thế này.

Các Yếu Tố Ảnh Hưởng Đến Hiệu Quả Của Tác Nhân AI

Vâng, một số điều liên quan đến đường cong chữ J khác. Vì vậy, các nhóm thăm dò ý kiến chuyên gia không dự đoán thời gian hoàn thành, họ chỉ dự đoán độ lớn hiệu ứng này của các nhóm thăm dò ý kiến chuyên gia. Họ được cho biết mức độ kinh nghiệm mà các nhà phát triển này có. Và một số nhóm thăm dò ý kiến chuyên gia khi suy nghĩ về cách dân số này có thể khác với các dân số khác, đã chỉ ra các sự thật khác nhau về nghiên cứu, như "những người có kinh nghiệm hơn, tôi kỳ vọng họ sẽ ít được tăng tốc hơn." Hoặc "kho lưu trữ mã nguồn lớn hơn. Tôi nghĩ AI ít có khả năng làm việc trên các kho lưu trữ mã nguồn lớn hơn, tôi kỳ vọng tốc độ tăng tốc sẽ ít hơn." Họ không bao giờ, không bao giờ đề cập đến sự quen thuộc với công cụ. Cảm giác của tôi là họ chia sẻ quan điểm ban đầu, đó là hầu hết các hành động nằm ở việc hiểu được những loại điều mà AI giỏi về điều đó ngay từ đầu. Và tất cả các nhà phát triển này đều có kinh nghiệm với Mô hình Ngôn ngữ Lớn của họ và quy trình làm việc phát triển cốt lõi của họ. Chỉ là người ta nói rằng đó là ba phần tư trong số họ, và tôi hoàn toàn không quen thuộc với khởi đầu của nghiên cứu. Vì vậy, tôi không thấy có nhiều biên độ. Vâng, tôi nghĩ đó là một câu hỏi mở. Tôi cũng đã xem rất nhiều giờ bản ghi màn hình của các nhà phát triển này làm việc. Và tôi chỉ không thấy, tôi nghĩ họ đang thích nghi rất hợp lý, trong một số trường hợp kém hơn tôi và các đồng nghiệp của tôi, trong một số trường hợp tốt hơn. Tôi không thấy những quy trình làm việc tiên tiến mà họ không thực sự thấy. Vâng, và kinh nghiệm của tôi không quá khác biệt. Từ đó, có những lúc tôi bị chậm lại đáng kể. Và có những lúc tôi được tăng tốc. Và mặc dù khi sự quen thuộc của tôi với công cụ tăng lên, tôi chắc chắn không phải tốn nhiều nỗ lực đến thế. Bởi vì tôi học được theo thời gian những gì tôi có thể yêu cầu nó làm và những gì tôi không thể yêu cầu nó làm. Ngoài ra, việc trở nên tốt hơn với nó, giống như hiểu rằng, "OK, bây giờ tôi cần lập kế hoạch, bây giờ tôi sẽ theo dõi." Nhưng đó là lý do tại sao, trước khi bạn đưa ra một quyết định kiến trúc cấp cao, việc chỉ dựa vào 10 cuộc trò chuyện qua loa sẽ khiến mọi thứ đổ bể. Bạn thực sự đang cố gắng suy nghĩ về điều đó. Vâng, vâng, vâng, chính xác. Và cũng như thu hẹp phạm vi xuống một vấn đề nhỏ hơn. Giống như, lúc đầu, tôi sẽ thử những vấn đề quá lớn và tôi không thể xử lý được. Nhưng chỉ để tương lai, nếu bạn có bao giờ làm, ý tôi là, tôi nghĩ điều đó rõ ràng là thực sự khó với kích thước mẫu nhỏ, chỉ 16 người. Nhưng bạn biết đấy, điều đó thật tuyệt. Thật tuyệt.

Ảnh hưởng của AI lên Codebase lạ và Dự án Nguồn mở

Trong tương lai, tôi nghĩ rằng tôi đã cắt bỏ một phần, như cố gắng tìm hiểu xem liệu có một ngưỡng quen thuộc nào đó mà số lượng thay đổi sẽ rất thú vị để xem liệu kết quả đó có khái quát hóa được hay không. Và đó là điều tôi nên nói. Chúng tôi đang thực hiện điều đó. Tôi nghĩ rằng AI đã trở nên tốt hơn trong giai đoạn này, điều này rõ ràng đã làm phức tạp thêm nhiều điều đang diễn ra. Nhưng, vâng, vâng, thật thú vị. Vấn đề là, bản thân các dự án đã được tối ưu hóa rất tốt cho những người mới bắt đầu dự án và tìm cách... bạn biết đấy, chúng vốn là những dự án khó tổ chức tốt để con người tham gia và điều hướng, và nhanh chóng không tồn tại lâu trong hệ sinh thái mã nguồn mở. Vâng, đây là những dự án mã nguồn mở khá trưởng thành. Và chúng hơi khác so với bất kỳ môi trường doanh nghiệp nào, nơi mọi thứ tồn tại vì chúng tạo ra tiền, ngay cả khi chúng khó phát triển. Vì vậy, ngữ cảnh hơi khác. Đây là những điều khác biệt. Vâng, vâng, điều đó thực sự thú vị, Brian, bởi vì trên thực tế, một số repo mà tôi được giúp đỡ nhiều nhất là những repo mà tôi hoàn toàn không quen thuộc, và tôi không có bất kỳ tài liệu nào về chúng. Và chúng tôi giống như, tôi phải tham gia vào cơ sở mã kế thừa đã tồn tại trong nhiều năm và thực hiện một thay đổi. Và nhà phát triển đã tạo ra nó chỉ có thể trả lời một phần câu hỏi của tôi. Vì vậy, trong trường hợp đó, CloudCoast là rất lớn. Vâng, cơ sở mã kế thừa không tồn tại vì chúng hoạt động tốt. Mà là vì chúng tạo ra tiền. Vâng, vâng. Chắc chắn rồi.

Kinh nghiệm AI và Kết quả Nghiên cứu

Vâng, những gì tôi có là, các nhà phát triển có cùng trình độ AI. Từ những gì tôi nghe được, năm đầu tiên có sự khác biệt nào không? Có biểu đồ nào về từng mức độ quen thuộc không? Luôn có một biểu đồ. Luôn có một biểu đồ. Luôn có một biểu đồ. Bạn chỉ cần, bạn đã đếm các câu hỏi tương tự của những người đó, hay có một cái J-shaped? Vâng, đây là một số bằng chứng. Vậy, được rồi, tôi đã chỉ cho bạn một số biểu đồ. Tôi nghĩ kích thước mẫu đủ nhỏ đến mức bạn thực sự không nên tin bất kỳ điều gì trong số đó. Ý tôi là, tôi nghĩ các biểu đồ sẽ không nói lên nhiều, nhưng sau đó tôi không muốn nói rằng đó là bằng chứng mạnh mẽ. Đây không phải là điều gì đó đang diễn ra. Tôi chỉ nghĩ bằng chứng hơi yếu. Điều thực sự thuyết phục tôi là, hãy xem video. Tôi xem các video tôi đang làm việc. Và, bạn biết đấy, thường thì họ sử dụng Cursor tốt hơn tôi. Và tôi nghĩ, tôi đang làm dự án này với bạn bằng cách sử dụng Cursor. Nhưng đây là một số biểu đồ.

Đây là dựa trên việc họ có các loại kinh nghiệm AI khác nhau khi tham gia vào nghiên cứu. Và, về cơ bản, bạn không thấy bất kỳ sự thay đổi nào trong ước tính điểm. Những người đã sử dụng IDE chính trước đây, không có sự khác biệt lớn so với những người không. Sau đó, điều tiếp theo là, bạn có thể nghĩ rằng, có thể, bạn có quan điểm rằng, J-shaped xuất hiện vào thời điểm này, nhưng vẫn, trong nghiên cứu, có một số biến thể về mức độ kinh nghiệm của mọi người với AI bởi vì họ có nhiều vấn đề, sau vấn đề AI đầu tiên, họ có vẻ được tiếp xúc nhiều hơn so với vấn đề AI thứ hai. Vì vậy, bạn có thể thử loại trừ các điểm dữ liệu đó theo thời gian và xem điều gì xuất hiện. Và, họ dường như không trở nên tốt hơn trong việc sử dụng nó theo thời gian. Chà, tôi nghĩ có lẽ có một vấn đề tĩnh. Bạn nghĩ có lẽ có gì? Có lẽ có một vấn đề tĩnh với biểu đồ đó. Giống như, các thanh đó rất, rất rộng. Ồ, ý tôi là, tôi nghĩ, vâng, không có biểu đồ nào trong số đó, tôi nghĩ như tất cả các biểu đồ bên ngoài các biểu đồ chính, tất cả những thứ phụ này, bạn không nên đặt nhiều niềm tin vào. Vâng, vâng, tôi hoàn toàn đồng ý.

Đường cong chữ J và Giải thích Dữ liệu

Được rồi, và sau đó rất nhiều phần chính, vì vậy biểu đồ này là lý do chúng tôi xếp nó vào bằng chứng không rõ ràng, bởi vì chúng tôi thích có những điều chỉ theo các hướng khác nhau. Rất nhiều phần chính của biểu đồ này gợi ý, bạn biết đấy, một cái gì đó, một cái gì đó hình chữ J nói riêng, rằng, bạn biết đấy, cuối cùng, khi mọi người có nhiều kinh nghiệm hơn, họ thực sự trải nghiệm một số sự tăng tốc. Dưới đây là một số vấn đề, thứ nhất, giống như các biểu đồ khác không. Tôi nghĩ điều đó quan trọng cần được đưa vào. Thứ hai, những giờ này được mã hóa rất thận trọng. Ví dụ, một người trong nhóm 30 đến 50 giờ đã sử dụng Cursor làm IDE chính của họ vào năm 2024. Họ đã tự ghi lại trên phần mềm theo dõi thời gian của họ rằng đã dành 140 giờ sử dụng Cursor. Họ đã ước tính thận trọng rằng họ đã dành 50 giờ sử dụng Cursor. Và vì vậy họ đã không dành 30 đến 50 giờ. Đây là một người mà IDE chính của họ là Cursor vào năm ngoái. Và, bạn biết đấy, mọi người đã bình luận về điều này. Họ đã sử dụng Cursor chưa đầy một tuần. Tôi nghĩ đó không phải là một đánh giá rất công bằng. Nếu bạn chuyển nhà phát triển đó từ thanh gần cuối sang thanh cuối cùng, một lần nữa, bạn không nên tin điều này vì thống kê, nhưng nếu bạn chuyển nhà phát triển đó từ ước tính kích thước hiệu ứng gần cuối sang ước tính kích thước hiệu ứng cuối cùng, thì bạn thấy một số sự cân bằng lại, nơi bạn trở lại gần như bằng không trong hai thanh cuối cùng. Vâng, một lần nữa, vì vậy, giống như gần cuối, nếu tôi nghĩ giải thích J-shaped, bạn biết đấy, vẫn còn rất không ổn định. Không phải là không có khả năng nhóm 50 giờ cũng tương tự như vậy, đánh giá thấp thời gian họ đã dành để sử dụng Cursor và thực tế nếu bạn có một thang đo dài hơn, bạn vẫn sẽ thấy điều đó với tôi? Ồ, đó là một điểm thú vị. Điều đó có vẻ hợp lý với tôi. Và sau đó, và sau đó tôi đoán tôi muốn, tôi không chắc đó là đánh giá thấp vì chúng tôi đang sử dụng cách này rất thận trọng. Vâng, vâng. Chắc chắn rồi. Vâng, vâng, tôi nghĩ điều đó có vẻ hợp lý với tôi. Và sau đó để điều này không phải là bằng chứng mạnh mẽ, tôi quay trở lại với ý nghĩ rằng bạn thực sự không nên tin bất kỳ điều nào trong số này. Vâng, tôi biết bạn nghĩ vậy. Nhưng tôi nghĩ điều lớn lao là kích thước mẫu nhỏ và cũng có rất nhiều sai lệch trong tập dữ liệu một cách hiệu quả. Đúng không? Giống như đó là một loại tập dữ liệu nhất định. Nó phụ thuộc vào loại nhà phát triển. Vâng, các nhà phát triển mã nguồn mở và cũng làm việc trên các dự án mã nguồn mở khá trưởng thành. Vâng. Bạn biết đấy, hai điều đó là, bạn biết đấy, làm việc với các nhà phát triển mã nguồn mở trên hai dự án khá trưởng thành này. Điều này có lẽ khá đáng tin cậy. Có thể kích thước mẫu khá nhỏ, nhưng ngoài ra thì khó hơn một chút. Vâng, và nói về điều này. Tôi nghĩ, vâng, nhóm này thực sự kỳ lạ. Nó thực sự thú vị. Nó thú vị vì cùng một lý do mà nó thực sự kỳ lạ. Đúng không?

Hạn chế của Nghiên cứu và Đối tượng Nhà phát triển

Vâng, chúng tôi quan tâm đến việc, một lần nữa, nghiên cứu các hiệu ứng có thể có của AI đối với việc tăng tốc độ hoặc tự động hóa. Nếu có bất kỳ loại nhà phát triển nào không được tăng tốc đáng kể, điều đó có nghĩa là toàn bộ quá trình không được tăng tốc. Vì vậy, thật tò mò khi thấy ngay cả những quần thể đặc biệt kỳ lạ. Bạn có thể tưởng tượng chỉ những cơ sở mã suy luận sản xuất lớn, có thể có hình dạng hơn một chút so với các script thử nghiệm. Vâng. Nhưng, vâng, hoàn toàn không, tôi nghĩ điều đó rất thú vị. Chỉ là rất khó để đưa ra đánh giá như chúng tôi đã làm. Vâng. Vâng, chúng tôi đang thực hiện nghiên cứu lớn này. Và tôi nghĩ, bạn biết đấy, tôi nghĩ, thật không may, rất nhiều nghiên cứu lớn, bao gồm nhiều dự án green field hơn. Và tôi nghĩ nó vẫn sẽ rất khó khăn. Tôi hiểu ý bạn. Vâng. Vì không nhiều lý do, vâng. Mặc dù tôi không cảm thấy kết quả của bạn đặc biệt mâu thuẫn với bất kỳ nghiên cứu độc lập thực tế nào đã được tiến hành. Bạn biết đấy, nghiên cứu mà tôi đã thấy mà tôi sẽ nói là mâu thuẫn với nghiên cứu của bạn là nghiên cứu được tài trợ bởi các model shops hoặc agent shops. Tôi có thể nói gì về điều đó? Tôi thực sự nghĩ rằng hầu hết nghiên cứu được công bố đều liên quan đến các công ty công nghệ lớn. Và tôi nghĩ có những mối lo ngại về phương pháp luận khác mà tôi cũng đã xem xét. Tôi cũng có các tiêu chí phương pháp luận với họ. Tôi biết những người làm việc ở một số nơi đó cũng có những mối lo ngại về phương pháp luận với những gì đã được công bố. Vì vậy, ý tôi là, tôi nghĩ cũng có những mối lo ngại về chúng tôi. Chắc chắn rồi. Chắc chắn rồi, nhưng tôi thực sự cảm thấy như, tôi nhớ có người đã gửi cho tôi bài báo của bạn. Và khi tôi thấy tiêu đề, tôi đã nghĩ, không đời nào. Hãy để tôi làm điều đó. Tôi đã nghĩ, điều đó nghe có vẻ vô lý. Vâng, vâng. Tôi đọc bài báo và tôi nghĩ, ồ, cái này không tệ chút nào. Như vậy. Vâng, một chút. Không, không, không. Tôi không biết. Ít nhất kết luận cấp cao của bạn, vừa trực quan, như từ một người đã đọc nhiều nghiên cứu kỹ thuật phần mềm, và cũng được chứng minh rõ ràng. Tôi nghĩ mọi người, tôi đã phải tranh cãi với họ về vấn đề 16 nhà phát triển, nhưng tôi không nghĩ điều đó thực sự quan trọng trong trường hợp cụ thể đó, bởi vì tôi nghĩ họ thực sự là một tập kiểm soát khá tốt, hoặc ít hơn, đúng không, cho một thí nghiệm bởi vì họ loại bỏ rất nhiều mối lo ngại về tính hợp lệ bằng cách là các chuyên gia. Vì vậy, vâng, họ chắc chắn rằng họ không đại diện cho một số khía cạnh rộng lớn của các nhà phát triển, nhưng họ cũng loại bỏ rất nhiều phương sai và những gì bạn mong đợi từ quần thể. Và họ cho phép bạn có một loại chức năng nhận thức luận kiểu như, hey, hãy cô lập yếu tố đó đi và sau đó điều đó xảy ra với nó. Và đó là điều tôi thích điều đó. Và như chúng tôi đã nghĩ, cách nghiên cứu được tiến hành hoàn toàn đủ để đưa ra kết luận cấp cao mà nó đã đưa ra. Cảm ơn rất nhiều.

Dự án Green Field, Brown Field và Hackathon

Đây là một điều tò mò. Vì vậy, chúng tôi đã công bố điều này vì những lý do tổ chức mà chúng tôi sẽ, nhưng chúng tôi đã tiến hành điều này, những người có vai trò, một số giải thích khác nhau của họ về những gì đang diễn ra ở đây, nhiều trong số đó có rất nhiều giá trị, một số trong đó tôi hoài nghi hơn về cái tự nhiên là dự án brown field so với dự án green field. Vì vậy, chúng tôi đã tổ chức một cuộc hackathon khổng lồ, nơi chúng tôi đã cho một nửa số nhóm sử dụng ARA so với không, bạn biết đấy, green field tối đa hoặc tương tự. Và sau đó chúng tôi có rất nhiều giám khảo chấm điểm cho họ, nhiều điểm giám khảo cho mỗi dự án hoặc tương tự để cố gắng loại bỏ nhiễu đó nhiều hơn. Xem liệu có phải là trường hợp như 50% dưới cùng hoặc tất cả nhóm không được phép AI và ở trên cùng, nhóm được phép AI hoặc tương tự không? Giờ đây, thật không may, nó thậm chí còn nhỏ hơn. Đó là một phần lý do chúng tôi không công bố nó. Vì vậy, tôi nghĩ bằng chứng thực sự khá yếu. Mức độ chồng chéo là rất lớn. Giống như ước tính điểm mà chúng tôi hơi lo lắng khi nói điều này bởi vì, bạn biết đấy, thông qua các loại quy trình đánh giá mà một thứ như thế này phải trải qua. Vì vậy, có thể tôi đã làm sai điều gì đó. Nhưng tôi nghĩ ước tính điểm là cao hơn khoảng bốn điểm phần trăm trên một, xin lỗi, cao hơn bốn điểm phần trăm nếu AI được phép so với nếu không được phép ngoài nhóm kiểm soát của các cô gái. Điều đó giống như, bạn biết đấy, cực kỳ nhiều nhiễu và gây khó khăn cho kết luận, nhưng dường như có thể có hiệu ứng nhỏ, dường như AI chỉ có hiệu ứng nhỏ. Vâng. Vâng.

Nghiên cứu Mâu thuẫn và Vấn đề Phương pháp luận

Vì vậy, trong đầu tôi, tôi đoán đây là một nghiên cứu tốt và cũng tốt cho các nghiên cứu khác mà các bạn đã thực hiện. Vậy bạn đã tìm thấy một mô hình tương tự chưa? Tôi đoán trước tiên, bạn đã khám phá hiệu ứng của AI trong các lĩnh vực khác, và đặc biệt là kỹ thuật phần mềm? Và nếu có, bạn cũng đã tìm thấy kết quả đáng ngạc nhiên này rằng có lẽ không có nhiều sự tăng tốc không? Không, không, không, không. Ý tôi là, không, các hướng mới, những điều mà chúng tôi chưa làm. Vâng, tôi, vâng, chúng tôi quan tâm đến việc hiểu khả năng định tuyến fixal. R&D, viết mã không phải là loại công việc duy nhất diễn ra tại các công ty AI lớn, nhiều công việc khái niệm hơn cũng diễn ra. Tôi sẽ rất vui khi làm việc với các nghiên cứu sinh Tiến sĩ Toán học hoặc các loại nhà phát triển phần mềm rất khác nhau hoặc thực hiện các loại nghiên cứu này bên trong các công ty AI lớn hoặc các công ty công nghệ lớn hoặc tương tự. Tôi nghĩ chúng tôi rất quan tâm đến, không nhất thiết trực tiếp, nhưng tương tự gần gũi với trường hợp công ty AI lớn. Vì vậy, đến mức mà điều gì đó thực sự khác biệt so với điều đó, có lẽ ít quan tâm hơn. Nếu thú vị.

Hướng Nghiên cứu Tương lai

Vậy, vâng, có vẻ như bạn quan tâm đến việc đo lường năng lực cho nghiên cứu toán học và một số nghiên cứu khác. Vâng, tôi muốn nói rằng tôi quan tâm đến việc cái quái gì đang xảy ra trong AI.

Tập trung vào Nghiên cứu AI và Thách thức trong Khoa học Dữ liệu

Và làm thế nào tôi có thể tìm hiểu nhiều nhất về những gì đang diễn ra trong AI? Tôi nghĩ rằng một cái gì đó mang tính khái niệm hơn một chút, một cái gì đó mà ít người đang làm việc, nên sẽ ít xuất hiện hơn trong dữ liệu đào tạo, sẽ giúp tôi xác định rõ hơn sự thật về những gì đang diễn ra trong AI. Ngay cả khi tôi không quan tâm đến nghiên cứu toán học cụ thể, nó vẫn sẽ đưa ra những bài học định tính hữu ích, đó là cảm nhận của tôi. Vâng, ý tôi là, tôi định chọn những lĩnh vực mà tôi nghĩ AI thành công nhất, và tất cả những lĩnh vực mà nó được kỳ vọng sẽ thành công hơn. Nhưng tôi nghĩ những lĩnh vực mà nó đang kém thành công hơn, tôi sẽ chọn có lẽ là khoa học dữ liệu. Đây là một điểm thú vị, ví dụ như làm thế nào các nhà khoa học dữ liệu muốn được AI hỗ trợ ngày nay? Hãy nói rõ hơn về những gì bạn kỳ vọng AI sẽ kém thành công hơn.

Thách thức của Dữ liệu Doanh nghiệp Lớn

Để tôi đưa ra một ví dụ. Tại LinkedIn, có 5.000 bảng có tên 'impressions', phải không? Vậy nếu một nhà phân tích muốn hiểu có bao nhiêu impressions trên một trang, chúng đã đi đâu? Bạn không thể tìm ra điều đó. Ngày nay, không có hệ thống AI nào hiện có mà chúng ta có thể kết nối vào một môi trường doanh nghiệp như vậy và xử lý. Ý tôi là, có hàng nghìn tỷ hàng trong các bảng đó. Vì vậy, điều mà một nhà khoa học dữ liệu cần làm là phân tích một lượng lớn dữ liệu và đưa ra kết luận. Tôi nghe rất nhiều ý kiến về việc xây dựng hệ thống. Mọi người nói về việc tạo SQL. Các mô hình đã giỏi viết SQL hơn nhiều so với trước đây. Nhưng tôi tin rằng tình trạng dữ liệu cơ bản tệ đến mức các nhà khoa học dữ liệu thực tế sẽ nhận được ít giá trị từ AI hơn nhiều so với các kỹ sư phần mềm.

Kiến thức Ngầm và Các Mô hình AI Chuyên biệt

Điều đó rất thú vị. Một quan điểm mà một số người bi quan hơn về tương lai của AI là có quá nhiều kiến thức ngầm (tacit knowledge) được nhúng sâu bên trong các công ty mà bạn sẽ không thể thu thập được từ dữ liệu trong môi trường đào tạo RRL (Reinforcement Learning from Human Feedback) hoặc tương tự. Có lẽ không phải trạng thái tự nhiên là cần có nhiều AI chuyên biệt, ít hơn nhiều so với những năm gần đây khi một AI tổng quát lớn dường như hoạt động hiệu quả hơn. Nhưng tại một thời điểm nào đó trong tương lai, khi dữ liệu bị khóa bên trong các công ty, chúng ta sẽ có sự bùng nổ của nhiều mô hình chuyên biệt hơn, giống như GPT được tinh chỉnh trên dữ liệu của LinkedIn, và vân vân. Tôi có một phản ứng tương tự. Tôi có một phản ứng gần như không tin tưởng. Tôi kiểu như, 'À, khoa học!' Nhưng cũng có rất nhiều sự thật mâu thuẫn. Phổ biến nhất là tất cả các tập dữ liệu này đều chứa các sự thật mâu thuẫn. Ví dụ, tên của trường có thể là 'ngày bắt đầu', nhưng nó chỉ chứa một ngày, ngoại trừ nó chỉ chứa ngày cho đến khoảng tháng 11 năm ngoái. Sau đó, nó sẽ chỉ chứa tháng. Nhưng rồi sau đó, nó có thể chứa số giây mà sự việc đó kết thúc. Và để thực sự truy vấn thành công tập dữ liệu, bạn, nhà phân tích dữ liệu, nhà khoa học dữ liệu, phải biết những ngày cắt đó là gì, mà không được ghi lại ở bất cứ đâu.

Thách thức của Dữ liệu Không Sạch và Kiến thức Ngầm

Mặc dù về mặt lý thuyết, bạn có thể nhập một loạt các câu lệnh SQL mà các nhà phân tích khác đã viết để cố gắng tìm hiểu cách họ đã giải quyết những vấn đề này và tạo ra các báo cáo đó. Nhưng ngày nay, tôi nghĩ rằng, ví dụ, những người – xin lỗi, tôi chỉ là, tôi chưa từng làm việc ở một công ty lớn – mọi người không khắc phục điều này ở nguồn. Ồ không. Vì vậy, tôi cảm thấy bài học tôi học đi học lại là: đặc tả dữ liệu thực sự quan trọng. Thực sự quan trọng. Không, tôi cũng đã làm việc trong phân tích dữ liệu ở các nghiên cứu của mình. Vâng. Và vậy, vấn đề là công việc của họ là tạo ra báo cáo này cho giám đốc điều hành này, đúng không? Chứ không phải đi xây dựng cơ sở hạ tầng để tạo ra báo cáo này. Vâng. Được rồi, không sao. Tôi sống với giấc mơ đó mỗi ngày. Chà, bạn chỉ cần – ngay cả việc phải làm, đúng không – bạn phải xây dựng một hạ tầng cho nó mà phải là một phần của mô tả công việc. Và phần khác là bạn phải khắc phục vấn đề ở nguồn. Tôi vẫn nhớ một cuộc trò chuyện mà ai đó nói rằng 'quá khó để khắc phục nó ở nguồn vì có quá nhiều sự phức tạp của tất cả các hệ thống cung cấp dữ liệu cho nguồn đó.' Và tôi nói, 'Được rồi, đợi một chút. Điều này có nghĩa là quá phức tạp để giải quyết ở nguồn, nhưng bằng cách nào đó, một vấn đề quá lớn để toàn bộ tổ chức giải quyết, lại dễ giải quyết hơn ở khâu hạ nguồn? Thôi nào.' Vâng, điều đó không có ý nghĩa gì cả.

Tiềm năng và Hạn chế của AI trong Khoa học Dữ liệu

Tôi chỉ nghĩ rằng có rất nhiều tiềm năng ở đây, và tôi chưa thấy nhiều nghiên cứu về cách những người làm việc trong lĩnh vực dữ liệu đang trải nghiệm AI. Và điều thú vị về điều đó là ML (Machine Learning) thực tế chủ yếu là công việc dữ liệu. Giống như ML bên ngoài các LLM, phần lớn các kỹ sư ML dành phần lớn thời gian của họ để feature curation (lựa chọn và biến đổi đặc trưng) chứ không phải là đào tạo mô hình trực tiếp thực sự và cố gắng làm sạch dữ liệu xấu cho feature curation. Vì vậy, tiềm năng, ngay cả đối với việc cải thiện ML bằng cách cho phép ML trở thành một nhà khoa học dữ liệu tốt hơn, là rất lớn. Và tôi nghi ngờ rằng, giả thuyết của tôi là, nếu bạn đi sâu vào lĩnh vực này, bạn sẽ phát hiện ra rằng nó rất giỏi trong việc chỉ cho tôi cách viết SQL hoặc cách viết Pandas (hoặc Polars, hoặc bất cứ thứ gì bạn đang sử dụng). Nó chấp nhận được khi làm những việc rất tầm thường và nó thất bại hoàn toàn ở tất cả các nhiệm vụ phức tạp. Nó thất bại hoàn toàn trong mọi kịch bản phức tạp. Tôi thậm chí không biết. Tôi thậm chí không thấy benchmark nào về nó. Bạn có thể cho tôi một ví dụ về một nhiệm vụ phức tạp không?

Ví dụ Nhiệm vụ Phức tạp: Các Chỉ số Triển khai

Chắc chắn. Giả sử một nhiệm vụ phức tạp là: xác định P90 (phân vị thứ 90) về thời gian giữa các lần triển khai (deployment) cho tất cả các deployment đến Capital One. AI sẽ gặp khó khăn với điều đó? Vâng, điều đó có vẻ đáng ngạc nhiên đối với tôi. Điều đó có vẻ đáng ngạc nhiên, phải không? Vâng. Vì vậy, tôi nghĩ, nếu nó có một ngữ cảnh hợp lý về nơi nó sẽ tìm thấy điều này. Vậy tôi tìm thấy dữ liệu đó, đúng không? Chắc chắn, chắc chắn có ý nghĩa. Và sau đó, được thôi, hãy cho tôi con số đó. Và sau đó nữa, hãy đảm bảo rằng bạn có thể phân tích nó theo cấp bậc nhóm. Vì vậy, hãy cho tôi nó trong một bảng để tôi có thể phân tích theo cấp bậc nhóm. Dữ liệu cấp bậc nhóm ở đâu? Như thế nào? Ồ, đây là một điều thú vị: những PR (Pull Requests) nào đã có trong các deployment đó? Vậy làm sao tôi biết? Làm thế nào tôi thực sự xác định thời gian deployment bắt đầu và kết thúc? Hóa ra điều đó không rõ ràng trong telemetry cơ bản. Và bạn phải biết một số 'phép thuật' để tìm ra khi deployment bắt đầu và kết thúc. Và cũng cho tôi biết, để tôi có thể phân tích, có bao nhiêu PR trong mỗi deployment đó và những PR nào trong mỗi deployment đó. Chà, bạn biết đấy? Hệ thống deployment chỉ – đây không phải là một vấn đề lớn, phải không? Tôi nghĩ nó đang được ghi lại. Vâng, trước khi bạn... Cảm ơn. Vậy thì hãy tưởng tượng hệ thống deployment chỉ chứa một số thông tin về dữ liệu đó, đúng không? Vậy thì tôi lấy dữ liệu đó ở đâu? Chà, dữ liệu đó không tồn tại trong bất kỳ hệ thống nào khác. Vậy có lẽ tôi phải đến GitHub và tôi phải thực hiện một API call đến GitHub API. Và khả năng huấn luyện tác nhân AI toàn diện (all-in agent training) mà tôi có ngày nay là khá tối thiểu.

Hoài nghi về Tiến bộ AI và Kinh nghiệm của Các Chuyên gia

Vâng, tôi vẫn — bạn biết đấy, so với Michael Lee, bởi vì tôi khá bearish (bi quan) về tiến bộ của AI — tôi vẫn có một phản ứng kiểu như, 'Tại sao bạn không thể dành cả ngày để đưa cái này vào một file quy tắc Cursor?' Bạn biết đấy, nơi mà hệ thống phân cấp tồn tại? Tôi sẽ, tôi sẽ chỉ, đó là lý do tại sao tôi nghĩ nó thú vị. Tôi nghĩ khi bạn đang nghiên cứu, tôi chưa thấy bất kỳ nghiên cứu toàn diện thực sự nào về kinh nghiệm mà các nhà khoa học dữ liệu có được. Nếu bạn có bất kỳ mối liên hệ nào để yêu cầu các tổ chức thực hiện các nghiên cứu tại các công ty lớn, tôi biết tất cả điều này. Có một đồng nghiệp tại OpenAI, đang nói chuyện với một trong những diễn giả làm eVals, các eVals nội bộ. Và anh ấy đã đề cập rằng anh ấy đã làm một số công việc với các nhà khoa học dữ liệu. Vì vậy, anh ấy có thể biết một số người có dữ liệu đó. Nhưng tất cả đều là nội bộ, giữa anh ấy và Cursor, giữa anh ấy và, bạn biết đấy, Anthropic hoặc bất cứ ai khác. Và vâng, và tôi cũng nghĩ một trong những nhóm mà tôi tò mò là các luật sư. Có vẻ như các luật sư, bác sĩ truyền thống, lớn tuổi hơn, và tôi nghĩ các nhà toán học đều là những người mà họ quan tâm. Đó là bởi vì, bạn biết đấy, cả luật sư và bác sĩ đều bị ràng buộc bởi một lịch sử cũ (legacy history) của những hạn chế xung quanh họ và cách họ làm việc. Vâng, các vấn đề pháp lý. Tôi nghĩ họ cần phải 'chìm đắm' trong các quy tắc pháp lý. Và họ khá bảo thủ (stodgy). Giống như tôi đã quan tâm đến việc, những người bảo thủ đó thì sao? Sự bảo thủ (kháng lại sự thay đổi), tôi nghĩ tôi ít tin tưởng hơn khi tôi giải thích rằng, những hạn chế pháp lý đó dường như vẫn tiếp tục tồn tại theo thời gian. Cách tiếp cận bảo thủ, giống như việc thành lập một công ty luật mới ít bảo thủ hơn công ty luật trước đó, dường như là.

AI và Mô hình Tư duy trong Các Ngành Nghề Cũ

Tôi đồng ý. Tôi không nghĩ rằng nó sẽ tồn tại vĩnh viễn. Tôi chỉ nghĩ điều thú vị là xem liệu điều đó có ảnh hưởng đến mô hình tư duy mà họ có ngày nay hay không, ví dụ, cách họ được nói về AI hoặc mức độ tin tưởng của họ vào nó ảnh hưởng đến cách họ sử dụng nó. Đối với tôi, điều đó sẽ rất thú vị để biết. Tôi không biết, đó là một nghiên cứu đáng giá; nó giống như một trong những điều tôi tự hỏi. Hãy tưởng tượng một luật sư trẻ vừa tốt nghiệp đại học, đã dành nhiều thời gian hơn để sử dụng ChatGPT. Sau đó, bạn lấy một luật sư đã hành nghề 50 năm và có một kho tài liệu công việc khổng lồ chứa tất cả các bản tóm tắt (brief) mà các cộng sự cấp dưới của ông ấy đã viết trong nhiều thập kỷ, và ông ấy chỉ mở các bản tóm tắt đó, thay đổi vài từ, rồi gửi chúng cho thẩm phán. Và ông ấy, bạn biết đấy, đã quen biết các thẩm phán đó trong khoảng 30, 40 năm; ông ấy biết chính xác những gì họ muốn. Liệu ông ấy có nhận được bất kỳ giá trị nào không? Nhưng liệu có giá trị nào mà ông ấy nên nhận được không? Liệu có điều gì đó, có cách nào đó mà ông ấy sẽ được giúp đỡ không? Ví dụ, tôi chắc chắn biết discovery (quá trình thu thập bằng chứng). Discovery trong luật pháp liên quan đến AI là một vấn đề rất lớn. Và tôi biết rằng có Harvey (một công cụ AI pháp lý), tôi không biết gì về những thành công mà họ đã đạt được. Tôi biết rất nhiều người làm việc trong lĩnh vực đó, cụ thể là, đó là một điều đang diễn ra, phải không? Luôn có những lời bàn tán về nó, nhưng việc áp dụng nó lại là một điều rất khác so với...

AI trong Khám phá Pháp lý và Công cụ Phát triển

Điều đó là có thật, đúng không? Bởi vì một trong những điều đầu tiên tôi nghĩ đến khi ChatGPT ra mắt – vì tôi có một chút kiến thức nền tảng về pháp luật – là, 'Ồ, điều này hoàn toàn có thể thay đổi quá trình discovery.' Giống như điều này có thể xảy ra vì discovery là phần đau đớn nhất, khó khăn nhất và tốn kém nhất. Bạn sẽ có những hệ quả xã hội nghiêm trọng nếu làm cho discovery bớt tốn kém. Đó là phần tốn kém, việc có một vụ kiện (lawsuit). Và như vậy, bạn thực sự có thể tạo ra tác động đáng kể cho xã hội nếu bạn có thể làm cho discovery rẻ, tức thời và đáng tin cậy. Vâng. Câu hỏi về biểu đồ. Vâng. [transcript bị gián đoạn] Chà, xin lỗi. [transcript bị gián đoạn] Nó đáng giá 50 giờ nhất định. Và theo... [transcript bị gián đoạn]. Vâng. Vậy bạn đang nói rằng những người phát triển không có sự khác biệt? Cursor là cái chúng ta đang nói đến, IDE mà Viacoding và người dùng gặp phải vấn đề 50 giờ. Tôi rất tò mò về điều đó bởi vì mọi người đều nói về Viacoding và Cursor như thế nào. [transcript bị gián đoạn] Và tại sao cô ấy đạt được, làm thế nào bạn đạt được 50 giờ đó? Cô ấy tò mò. Vậy điều này bao gồm thời gian. 50 giờ riêng tư là... Điều này bao gồm thời gian mà các nhà phát triển đã dành trong các thử nghiệm cộng với kinh nghiệm trong quá khứ của họ. Vì vậy, đối với một số nhà phát triển làm việc trên một số vấn đề trong thử nghiệm, một số người trong số họ đã có hơn 50 giờ kinh nghiệm với Cursor. Và điều đó chỉ là cứ như vậy. Đó có phải là cùng một nhiệm vụ cho mỗi... Không, những cái này là một phần của.

Các Tác Vụ Phức Tạp và Ngữ Cảnh Tinh Thần

Chúng là những tác vụ tự nhiên xuất hiện trên các GitHub repository mà tôi đã đề cập. Tôi không muốn... Tôi hơi lo lắng khi nói chúng "kỳ lạ" vì nó ngụ ý rằng... Tôi muốn nói rằng nó rất thú vị và rất kỳ lạ. Và nó thú vị vì những lý do tương tự mà nó kỳ lạ. Đây là những repository (những dự án) mà ở đó các nhà phát triển có một lượng ngữ cảnh tinh thần khổng lồ để xây dựng, điều mà các AI có thể không có, những dự án mà họ đã làm việc trong nhiều năm, và họ có thể... Tôi không chắc điều này luôn đúng, nhưng tôi hình dung trong đầu rằng họ về cơ bản biết cách thực hiện một tác vụ cụ thể mà họ có trước khi họ, bạn biết đấy, làm điều gì khác. Bởi vì không có chuyên gia nào khác trong dự án đó.

Bạn có thể định lượng mức độ tăng tốc không? Nó có giống như 5% không? Khi bạn tiến lên, tốc độ tiến bộ đó là gì?

Ảnh Hưởng của Hỗ Trợ AI đến Thời Gian Hoàn Thành

Vậy bạn có thể nghĩ về... Hãy xem xét trường hợp này thay vào đó. Ở phía bên trái, chúng ta có mức trung bình về những gì các nhà phát triển nói xảy ra về thời gian hoàn thành nếu vấn đề hoặc tác vụ của họ được gán cho AI chỉ được bật hoặc nhóm được phép dùng AI. Họ nghĩ rằng nếu AI chỉ được bật, họ sẽ mất nhiều thời gian hơn một chút, gần hai giờ; và tôi đoán sẽ mất khoảng một tiếng rưỡi hoặc ít hơn một chút nếu AI được phép hỗ trợ.

Nhưng sau đó, chúng tôi ngẫu nhiên hóa tác vụ cụ thể này để cho phép AI hoặc không cho phép AI. Và hóa ra nếu chúng ta ngẫu nhiên hóa cho phép AI, thì thời gian hoàn thành lại cao hơn một chút so với hai giờ, thay vì thấp hơn một chút so với hai giờ. Và sau đó bạn có thể nghĩ về sự thay đổi trong ước tính thời gian như là một cái chia cho cái kia ở đây. Nó không hoàn toàn như vậy vì những lý do mà tôi có thể đi sâu vào, nhưng về cơ bản đó chính xác là sự biến đổi. Bạn biết đấy, nó giống như (thời gian AI chỉ được bật / thời gian AI được phép) trừ đi một.

Vì vậy, để làm rõ, tôi có thể hỏi, "Tốc độ tăng lên là bao nhiêu?" Bạn biết đấy, "Nó có giống 1.1x không?" Rằng các nhà phát triển này đang làm việc nhanh hơn 1.1 lần khi chúng ta thực sự đang đo theo thang thời gian hoàn thành, chứ không phải thang tốc độ – nhưng bỏ qua chi tiết đó – nó là 1.5x? Nó là 0.5x? Họ thực sự đang chậm hơn gấp đôi? Làm thế nào chúng ta có được thông tin đó? Chà, chúng ta sẽ làm một cái gì đó như lấy thời gian AI được phép chia cho thời gian AI được phép. Bạn biết, nếu con số này là 1.1 lần dài hơn so với thời gian được phép, thì chúng ta sẽ có 1.1x. Bạn biết đấy, nó giống như vậy, hãy tiếp tục. Và thực tế, chúng ta thấy có sự chậm lại.

Phân Tích Thực Tiễn và Chất Lượng Dự Án Mã Nguồn Mở

Cảm ơn. Tôi vừa đọc một bài báo hấp dẫn – một công ty cũ, tôi nhớ – nhưng về cơ bản, một nhà báo được phép sử dụng AI để viết mã, phải không? Để thực hiện một pull request (PR). Nó đã được giới thiệu. AI đã được sử dụng để hỗ trợ xây dựng các yêu cầu và, trên thực tế, bài báo chỉ cần thực hiện một vài chỉnh sửa nhỏ rồi ký tên. Toàn bộ việc viết mã bằng AI đó thực sự hấp dẫn. Vâng, tôi chỉ biết. Đó là chuyện cũ rồi. Giống như bạn không có phần mềm nào để chạy nền. Đó là tất cả những gì tôi có để đảm bảo điều này, cố gắng thực hiện một nghiên cứu về điều đó.

Vì vậy, tôi chắc chắn chia sẻ cảm xúc đó. Nhưng, bạn biết đấy, nếu bạn không có bất kỳ ý tưởng gì đang diễn ra, thì có lẽ đây sẽ là một số cải thiện tốc độ đáng kể. Tôi sẽ nói, tôi đoán, điều số một, bạn biết đấy, đó không phải là tháng Tư hay tháng Tám. Trên thực tế, chúng tôi đã tổ chức hackathon này với những người rất có kinh nghiệm và những người ít kinh nghiệm hơn nhiều và cố gắng xem điều gì đã xảy ra, và những gì chúng tôi thấy là, bạn biết đấy, điểm số của giám khảo cực kỳ nhiễu, và tôi nghĩ bạn không nên tin điều đó. Nhưng, bạn biết đấy, điểm số của giám khảo không cao hơn nhiều khi AI được phép so với khi không được phép. Mọi người thực sự không đạt được nhiều tiến bộ hơn thế.

Và sau đó một điều nữa cần nói là, tôi nghĩ sẽ có nhiều chuyên môn hơn trong căn phòng này so với hiểu biết của tôi từ, bạn biết đấy, ngồi với những nhà phát triển mã nguồn mở này một thời gian và bản thân tôi không phải là một nhà phát triển có năng lực cao, đó là tiêu chuẩn chất lượng trên các repository trong nghiên cứu này rất cao. Vâng, thông thường là vậy. Và vì vậy tôi sẽ rất ngạc nhiên nếu các nhà báo, thậm chí thẳng thắn mà nói, nếu một kỹ sư phần mềm giỏi mà không có nhiều kinh nghiệm về repository, nhưng chắc chắn là một người không phải là kỹ sư phần mềm, có thể tạo ra một PR sạch sẽ trên các repository này ngay lần đầu tiên.

Thực tế, tôi nghĩ đó là phần lớn câu chuyện về những gì đang diễn ra ở đây là các AI, bạn biết đấy, chúng thực sự có tiến bộ đúng hướng trong một phần lớn thời gian. Nhưng vì nhiều lý do khác nhau, đôi khi vì lý do correctness, nhưng đôi khi vì những lý do như, bạn biết đấy, cách họ đã cố gắng giải quyết vấn đề và liệu đó có phải là cách giải quyết vấn đề thông thường hay cách các phần khác nhau của dự án tương tác với nhau – những cân nhắc như vậy, bạn biết đấy, chúng chưa được tính toán đúng cách. Và vì vậy, bạn biết đấy, con người không chỉ cần dành thời gian đắt đỏ để xác minh, mà còn phải dọn dẹp tất cả những thứ đó. Và tôi cảm thấy rằng một người không có tất cả kinh nghiệm đó về cơ bản sẽ không biết cách thực hiện bước đó. Và vì vậy chúng tôi sẽ không thể gửi một PR sạch sẽ đến các repository này.

Bạn biết đấy, đó là nó. Giống như tôi, ít nhất là so với những người này, tôi tệ ở một thời điểm nào đó. Và tôi liên tục đưa ra các PR nội bộ. Tôi nghĩ chúng có chất lượng khá tốt. Và, bạn biết đấy, theo thời gian, chúng đang tốt hơn. Bạn biết đấy, tôi tin rằng mọi người đang viết mã khi họ không thể viết mã. Họ đang gửi các PR có tiêu chuẩn chất lượng thấp hơn khi họ không thể làm điều đó chút nào. Nhưng để đạt được các PR ở cấp độ chuyên gia này, tôi thực sự khá hoài nghi. Và đó thực sự là một phần của điều tôi muốn nói là, các PR thường bị từ chối bởi những người mới hơn trong các dự án lớn, chất lượng cao này. Không vì lý do nào khác ngoài tác động của developer ergonomics của pull request, phải không?

Tầm Quan Trọng của Tính Dễ Duy Trì trong Mã Nguồn Mở

Vì vậy, thực tế là nó làm cho việc maintenance của tôi trong tương lai khó khăn hơn, bởi vì đối với các dự án mã nguồn mở, gần như tất cả các khuyến khích đều thiên về việc làm cho tôi dễ dàng maintenance dự án hơn, phải không? Vì vậy, mỗi khi một PR đến, nếu nó không làm cho việc maintenance dự án dễ dàng hơn đối với tôi, tôi có xu hướng từ chối nó. Vâng. Nếu nó làm cho việc maintenance dự án dễ dàng hơn thì tuyệt vời, tôi sẽ chấp nhận. Điều đó không giống như những gì bạn có trong một ngữ cảnh kinh doanh điển hình, phải không? Nơi những điều quan trọng đó thực sự hoàn thành một cái gì đó, phải không? Bởi vì, bạn biết đấy, thực tế là ai đó phải dành nhiều thời gian để maintenance gần như là job security, phải không? Nhưng đối với mã nguồn mở, điều đó lại ngược lại. Điều thực sự khiến mọi người rời bỏ dự án là những gì khó maintenance, phải không? Vì vậy, có một sự thiên vị khác về những gì bạn chấp nhận cho Code Review / Pull Request.

Ví dụ về Haskell Compiler và Tiêu Chuẩn Chất Lượng Cao

Bạn có thể nhắc tôi tên của quý ông người Anh maintain Haskell compiler không? Simon, ai đó? Vâng. Không, tôi không nhớ. Không, được rồi. Hãy theo dõi tôi.

Vì vậy, đây là một câu chuyện có thể liên quan: bạn biết đấy, một loạt các repository trong nghiên cứu có những đặc điểm chung này, một trong số đó là Haskell compiler. Nổi tiếng là trên Haskell compiler, có một khả năng nào đó, tôi không biết là 50% hay 30% hay bao nhiêu, nhưng có một khả năng nào đó nếu bạn gửi một PR, thì... (tôi đang bị ghi âm) Simon, Simon, Simon, Simon, Simon, Simon, Simon, Simon, Simon... người maintain Haskell compiler sẽ vào phần bình luận và tranh luận với bạn trong nhiều giờ, lâu hơn nhiều so với thời gian bạn dành để làm việc trên pull request, cho đến khi PR đáp ứng chính xác các thông số kỹ thuật của bạn. Kết hợp sự thật đó với một sự thật đáng chú ý, tôi nghĩ, rằng PR trung bình trong nghiên cứu, thời gian họ dành để làm việc trên code sau khi review, là 0 phút. Tức là, PR trung bình gần như hoàn hảo ngay từ lần đầu tiên vì các khuyến khích chuyên nghiệp cho các nhà phát triển này là như vậy.

Bây giờ, có một phần đuôi rất dài; trong một số trường hợp, tôi nghĩ Simon, quý ông này, thực sự xuất hiện và ồ, anh ấy đã sửa chữa chúng tôi trong nhiều giờ, và trường hợp đó kéo dài hơn nhiều. Nhưng vâng, họ đang duy trì một tiêu chuẩn cực kỳ cao này.

Khả Năng AI trong Tương Lai và An Toàn

Tôi quan tâm đến những điều sắp tới khác mà bạn đã nói trong bài nói chuyện của mình. Vâng, vậy thì, bạn biết đấy, một điều mà tôi nghĩ là có nhiều điều để nói. Tôi đoán hãy đi theo thứ tự. Như tôi nghĩ bạn đã đề cập, nếu các capability hợp nhất theo time horizon, tiếp tục nhân đôi, thì việc theo kịp điều đó thực sự rất, rất thách thức. Trong ngắn hạn, chúng ta có một số hướng để vượt qua điều đó. Nhưng, và tôi nghĩ điều đó sẽ diễn ra, giống như trong suốt năm nay, nhưng trong hai năm tới, bạn biết đấy, điều đó có vẻ thách thức. Tôi nghĩ vẫn có thể. Trong ba năm tới, tôi nghĩ, vẫn có vẻ khủng khiếp. Bạn biết đấy, nó bắt đầu trở nên khó khăn hơn và khó khăn hơn.

Dù sao, trong ngắn hạn, việc xây dựng những tác vụ dài hơn nhiều này và những cách mà chúng ta có thể vượt qua hoàn toàn vấn đề. Ví dụ, đây là một điều có thể hữu ích phần nào. Nhưng cũng nâng cao tiêu chuẩn accuracy. Bạn có thể nâng cao tiêu chuẩn accuracy, mặc dù, bạn biết đấy, lý do chúng ta quan tâm đến điều này ngay từ đầu là chúng ta tự hỏi, "GPT-5 mở rộng có nguy hiểm không?"

Giám Sát và Kiểm Soát Khả Năng AI

Được rồi, và câu trả lời là không, tôi nghĩ. Nhưng tại sao chúng ta lại nghĩ câu trả lời là không? Được rồi, ít nhất, tôi nghĩ có nhiều lý do. Nhưng ít nhất chúng ta có thể nói, bạn biết đấy, GPT-5 đơn giản là không giỏi lắm ở một số tác vụ. Giống như bạn đang cố gắng khiến nó thực hiện data science trên các column có tên rất giống nhau. Và không rõ chính xác logic đã dẫn đến các column đó. Nó không, nó không làm được loại việc đó. Tôi nghĩ, bạn cần làm gì để loại việc đó có thể gây nguy hiểm mở rộng? Nó không tấn công điều đó. Nhưng, bạn biết đấy, những thứ có khả năng gây nguy hiểm mở rộng, và nó không có khả năng làm những thứ đó. Và vì vậy, bạn biết, tôi thấy rằng AI đang thất bại ở những tác vụ khó này.

Vì vậy, tôi nghĩ, bạn biết đấy, "Tuyệt vời, sao cũng được." Nhưng nếu nó thành công 90% thời gian chứ không phải 99% thời gian, điều này rất thách thức đối với các tác vụ dài, thì, bạn biết đấy, tôi nghĩ có những thứ khác mà chúng ta có thể dựa vào và tôi sẵn sàng dựa vào những thứ đó. Nhưng ít nhất lý do ngây thơ rằng nó không nguy hiểm về bản chất – rằng nó không có khả năng làm một số việc – tôi nghĩ ít nhất bắt đầu bị đẩy lùi như một lời giải thích.

Vì vậy, đây là một khả năng khác cho những gì chúng ta có thể làm: Điều gì sẽ xảy ra nếu thay vì time horizon ở đây, chúng ta có time horizon trong khi được giám sát rất chặt chẽ? Và sau đó, bạn biết đấy, có thể time horizon khi không được giám sát chặt chẽ thì giống như thế này, nhưng time horizon khi được giám sát rất chặt chẽ thì giống như thế này. Tức là, nếu, bạn biết đấy, tôi hy vọng rằng các công ty AI lớn có các thiết lập giám sát đang hoạt động, nơi, ví dụ, AI đang xem xét các bản ghi lại của AI thực hiện công việc để xem liệu có bất kỳ điều gì đáng ngờ đang xảy ra hay không.

Và, bạn biết đấy, sẽ không phải là không thể, có lẽ, tôi phỏng đoán, để đánh lừa các monitor đó, nhưng sẽ rất thách thức để đánh lừa các monitor đó. Vì vậy, bạn biết đấy, có thể bạn có thể thực hiện, chẳng hạn, các tác vụ liên quan đến capability nguy hiểm kéo dài 40 giờ mà không cần giám sát, nhưng chỉ các tác vụ kéo dài hai giờ nếu bạn đang được giám sát rất, rất chặt chẽ. Được giám sát như thể có một model khác đang đánh giá agent, đó là loại điều mà mọi người có thể có. Có lẽ bạn hỏi con người sau này và... Với và không có safety controls, ý bạn là vậy? Vâng, vâng, vâng, đại khái là vậy. Và sau đó, bạn biết đấy, bây giờ chúng ta đã đưa thêm các yếu tố nhân đôi, và chúng ta có thể tiếp tục thực hiện việc capability extrapolation. Đó là một trong những điều mà ngoài việc giải đáp mọi câu hỏi. Vâng, ý tôi là, tôi hình dung một số phòng thí nghiệm nhỏ hơn có các đánh giá về capability có và không có safety controls, bởi vì tôi chắc chắn rằng có một cuộc tranh luận giữa các researcher và các safety team của họ. Vâng, vâng. Bạn có biết, tôi đã thấy một vài điều về điều này, nhưng không nhiều. Vâng, vâng.

Khía cạnh Định lượng và An toàn của AI

Tôi nghĩ đây có thể là một cân nhắc đặc biệt quan trọng về mặt định lượng. Hoặc tôi kỳ vọng rằng nó sẽ giảm time horizon hiệu quả xuống có thể một hoặc hai bậc độ lớn. Vâng, tôi đồng ý rằng có một số khía cạnh quan trọng mà trong đó không thực sự có sự khác biệt về thời gian. Tất nhiên, sau đó tôi cũng sẽ lo lắng rằng việc công bố điều đó sẽ khuyến khích mọi người ít tập trung vào safety hơn hoặc cố gắng tranh luận chống lại safety, vì cách nó ảnh hưởng đến capability. Tôi nghĩ có rất nhiều "bãi mìn" trong tất cả các loại công việc về safety, không chỉ là tên gọi.

Thách thức trong Đo lường Năng lực và Dự đoán Xu hướng

À, trước tiên. Được rồi, điều tiếp theo. Bạn biết đấy, chúng ta có sức mạnh này, liệu nó có tiếp tục mãi mãi không? Đây có phải là một sự thật của vũ trụ, hay nó, bạn biết đấy, bằng cách nào đó phụ thuộc vào đầu vào hoặc bạn nghĩ về những giả định về trí thông minh hay đại loại thế? Cố gắng suy nghĩ về điều đó. Xu hướng này thực sự sẽ đi về đâu? Đó là một lĩnh vực nghiên cứu khá sôi nổi. Ngoài ra, bạn biết đấy, những cách mà xu hướng này hoặc các điểm cụ thể không hoàn toàn tương ứng với điều tôi quan tâm.

Một cách rõ ràng là các mô hình này đang được đánh giá theo, bạn biết đấy, tôi nghĩ việc chấm điểm bằng thuật toán mà chúng tôi sử dụng là quan trọng hơn theo hướng mạnh mẽ hoặc bao quát hơn những mối lo ngại liên quan có thể xảy ra trong các benchmark và kiểm thử đơn vị, nhưng nó vẫn có nhiều đặc điểm tương tự. Có những cân nhắc như khả năng xây dựng trên công việc này trong tương lai, bên ngoài vấn đề trước mắt bạn mà không được thu thập bằng cách chấm điểm. Và có lẽ nếu bạn thu thập được điều đó, bạn biết đấy, bạn sẽ nhận được một cái gì đó hơi giống như từ 50% thành công lên 80% thành công, bạn có thể thực hiện các tác vụ dài nếu không quan trọng liệu bạn có thể xây dựng dựa trên công việc đó hay không, nhưng bạn biết đấy, chỉ 30 phút yêu cầu nếu không quan trọng liệu bạn có thể xây dựng dựa trên công việc đó hay không, nhưng hãy đưa những con số này trở lại một điều mà tôi quan tâm hơn một chút.

Và sau đó, vâng, dự đoán cả nếu có sự chậm lại của máy tính, nếu chúng ta sẽ chấm dứt một chế độ mà AI tự xây dựng AI và điều đó dẫn đến một kiểu đường cong dốc hơn, những cân nhắc kiểu này. Đó là một điều khác tôi đang suy nghĩ. Và sau đó là đo lường capability từ các góc độ mới.

Lịch sử và Phương pháp Đánh giá của GPT-4

Vậy thì, bạn biết đấy, đây là một lịch sử của M mà tôi nghĩ không phải là lịch sử được chấp nhận và cũng có thể không phải là một lịch sử rất chính xác vì đó chủ yếu không phải là lịch sử chính xác nhất nhưng là một cách kể có thể của anh ấy. Gần lúc đầu, M có quyền truy cập sớm vào GPT-4 khi tôi không ở đó và tôi gần như không có kiến thức quốc tế về điều này. Và có những buổi hỏi đáp được tổ chức ở khắp mọi nơi. Bạn sẽ nói, bạn biết đấy, GPT-4 có vẻ rất thông minh, so với những thứ đã có trước đó. Nó có thể làm gì? Bạn biết đấy, đôi khi bạn thử hỏi, nó có thể làm gì không? Và câu trả lời là, bạn biết đấy, nó có thể làm một số việc và không thể làm những việc khác. Và mọi người sẽ nói, ồ, thật tuyệt. Bạn biết đấy, bạn thử cái này, bạn thử loại mới mẻ này, khiến các mô hình làm việc thay vì trả lời câu hỏi.

Và sau đó bạn sẽ nghĩ, à, các mô hình khác nhau, bạn biết đấy, chúng ra mắt theo thời gian. Mô hình này ra mắt vào tháng 1, mô hình này ra mắt vào tháng 2. Liệu chúng có thể làm những loại việc khác nhau nếu chúng ta kiểm tra chúng trên cùng một, nếu chúng ta kiểm tra chúng trên cùng một thứ? Sau đó chúng ta sẽ cố gắng nghĩ ra cách rõ ràng nhất, theo một số cách, một số là heuristic về việc liệu chúng có thể làm việc không. Có các điểm dữ liệu đơn lẻ hoặc con số phản ánh liệu chúng có thể làm việc không, time horizon, cộng thêm theo thời gian và xem điều gì xảy ra. Bạn sẽ nói, ồ, điều đó thật thú vị.

Và sau đó bạn sẽ nghĩ, à, vậy điều tiếp theo, theo một nghĩa nào đó là ngớ ngẩn nhất hoặc rõ ràng nhất bạn có thể làm là gì, đúng không? Và kiểu thiết kế RCT rõ ràng nhất. Hoặc kiểu ala-ray-ray, chúng ta không phải ala-ray-ray-ray. Và sau đó chúng ta sẽ xem điều gì xảy ra và chúng ta sẽ thử, bạn biết đấy, nó sẽ lộn xộn. Có rất nhiều vấn đề về phương pháp luận mà mọi người phát hiện ra như trong công việc này, nhưng có những loại vấn đề khác nhau. Bạn biết đấy, có những ưu và nhược điểm khác nhau và có lẽ với hai điều khác nhau này để đưa ra hai câu trả lời khác nhau và có hai bộ ưu nhược điểm khác nhau, chúng ta có thể tam giác hóa sự thật từ đó.

Và bây giờ tôi nghĩ, liệu chúng ta có thể rút ra con thỏ đó thêm một lần nữa không? Có nhiều lần nữa không? Có các nguồn bằng chứng nào khác mà có, bạn biết đấy, những ưu và nhược điểm khác nhau mà tôi sẽ không hoàn toàn tin tưởng, nhưng chúng có những ưu và nhược điểm khác nhau và chúng có thể đưa ra những câu trả lời khác nhau và cứ thế?

Đề xuất Đo lường Khả năng Mới: Transcript Thế giới Thực và AI Village

Dưới đây là hai gợi ý cho những điều tôi đang tò mò vào lúc này.

Transcript trong Thế giới Thực

Đầu tiên là các transcript trong thế giới thực. Vậy thì, bạn biết đấy, các tác nhân trong lớp, hoặc trong codebase và bất kỳ sản phẩm hoặc dịch vụ nào khác, chúng để lại dấu vết, dấu vết về những đóng góp của chúng cho codebase hoặc dấu vết về hành động của chúng, những thành quả gần đây của chúng, v.v. Những dấu vết mà chúng để lại trong thế giới thực, bạn biết đấy, khác biệt đáng kể so với điều này, nơi mà nó được kiềm chế hơn và, bạn biết đấy, các tác vụ được đóng gói gọn gàng, v.v. Điều này sẽ giống như, bạn biết đấy, ví dụ với nhiều cột khác nhau rất khó hiểu. Điều này sẽ giống như, bất cứ thứ rác rưởi thực sự nào xuất hiện trong thế giới thực, mô hình hoạt động như thế nào và những thứ đó.

Có những lý do quan trọng tại sao bạn không nên tin loại thông tin đó. Nó không mang tính thực nghiệm cao. Rất khó để biết chính xác phải làm gì với nó, nhưng nó có những ưu điểm quan trọng là nó chân thực hơn. Bạn biết đấy, dữ liệu rất lớn. Có lẽ dữ liệu trên các transcript là rất lớn. Bạn biết đấy, có lẽ có rất nhiều điều bạn có thể học được từ đó. Đó là một điều.

AI Village và Mục tiêu Không Rõ ràng

Và sau đó đây là một điều khác. Có một nhóm mà các bạn nên xem qua gọi là AI Village. Nơi họ có rất nhiều mô hình hoặc tác nhân khác nhau sống trong ngôi làng này, thỉnh thoảng nói chuyện với con người, cố gắng hoàn thành các mục tiêu không rõ ràng được đặt ra cho chúng, về cơ bản là sử dụng máy tính. Chúng cố gắng làm những việc như, bạn biết đấy, tổ chức sự kiện này tại công viên, hoặc chạy một vài thí nghiệm với đối tượng con người, hoặc điều hành cửa hàng bán hàng này, bạn biết đấy, những thứ không được chỉ định rõ ràng như vậy.

Và về cơ bản, mọi lúc họ đều thấy rằng các mô hình thất bại thảm hại. Và có rất nhiều lý do để không tin bằng chứng này. Bạn biết đấy, đây là một số lý do. Thứ nhất, nó đang sử dụng máy tính, và tôi nghĩ khả năng sử dụng máy tính nói chung kém hơn nhiều so với các phương pháp dựa trên CLI, khả năng mở rộng của máy tính kém hơn đáng kể so với các thứ dựa trên CLI hiện tại, các thứ dựa trên văn bản nói chung hiện tại. Và có lẽ bạn quan tâm nhiều hơn đến những thứ dựa trên văn bản vì điều đó phù hợp hơn với những điều rất tinh tế mà bạn quan tâm và cũng có rất nhiều thứ dựa trên GUI có thể được chuyển đổi thành những thứ dựa trên văn bản.

Bạn biết đấy, có tất cả các mô hình khác nhau đang hoạt động trong ngôi làng. Tôi tự hỏi, tại sao lại có quá nhiều mô hình như vậy? Tại sao lại có một ngôi làng thay vì chỉ là một thiết lập orchestration tác nhân lớn? Tôi thực sự không hiểu điều gì đang diễn ra ở đó. Dù sao, có nhiều lý do để không tin vào điều đó, nhưng mặt khác, đó là các mô hình đang thực hiện công việc trong thế giới thực. Nó không phải là đánh dấu bắt đầu nhiệm vụ. Nó giống như cố gắng hoàn thành một mục tiêu nào đó, và chúng không thể hoàn thành ngay cả những tập con rất cơ bản của mục tiêu.

Và tôi cảm thấy điều đó cực kỳ thú vị. Và tôi tự hỏi liệu bạn có thể loại bỏ một số nhược điểm rõ ràng nhất, bạn biết đấy, chỉ làm cho nó dựa trên văn bản, cung cấp cho chúng một số công cụ dựa trên văn bản phù hợp, làm việc nhiều về orchestration để khiến các mô hình này hoạt động tốt hơn, loại bỏ các mô hình hoạt động kém hơn trong ngôi làng, v.v., nhưng sau đó cố gắng khiến chúng thực hiện các mục tiêu không rõ ràng này.

Và, bạn biết đấy, chỉ cần quan sát xem chúng mắc lỗi ở đâu? Chẳng hạn như, bạn biết đấy, chúng đã thực hiện bước một rất tốt, nhưng sau đó chúng trở nên không mạch lạc, hoặc chúng, bạn biết đấy, rơi vào một trạng thái tâm lý kỳ lạ với một trong các mô hình khác, hoặc, bạn biết đấy, chúng không thể tương tác với các dịch vụ bên ngoài một cách thích hợp, hoặc tìm ra cách sử dụng tài nguyên của chúng. Bạn biết đấy, tôi sẽ rất quan tâm đến những gì xảy ra về mặt định tính khi bạn làm điều đó.

Một lần nữa, hãy nhớ rằng chúng ta quan tâm đến khả năng của, ít nhất là hiện tại, tôi quan tâm nhất đến khả năng của AI trong việc tự động hóa R&D, và nói về lý do tại sao điều đó không xảy ra vào lúc này, và tại sao điều đó có thể không xảy ra trong tương lai, một số điều được định hình như thế này, dường như có thể, theo quan điểm tò mò của tôi, cho thấy điều đó không đúng. Tôi không chắc chính xác điều đó là gì, nhưng vâng.

AI và Thách thức của Thế giới Dành cho Con người

Quan sát của tôi là chúng thực sự là những cá nhân neurodivergent, đúng không? Và không có gì trong thế giới của chúng ta được xây dựng cho điều đó. Vâng, mọi thứ chúng ta có, chúng được định nghĩa để con người thực hiện, chúng được định hình và có kích thước phù hợp với con người. Giống như trong quân đội, balo lớn đến mức nào? Chà, nó dựa trên việc họ nghĩ một người có thể mang được bao nhiêu một cách hợp lý, đúng không? Và chúng ta mong đợi một người xử lý bao nhiêu cho thuế của họ? Điều đó dựa trên những gì chúng ta nghĩ một con người có thể làm.

Và nếu bạn nghĩ về các cá nhân neurodivergent, họ phải đối mặt với những thách thức khi kỳ vọng của thế giới không phù hợp với điều đó. Và so với một cá nhân neurodivergent, những trí tuệ này thực sự, thực sự khác biệt, đúng không? Và tất cả những điểm chưa hoàn thiện khi chúng không phù hợp với thế giới của chúng ta, đó là lý do tại sao chúng cần một hệ thống để làm trợ lý nhằm hoàn thành bất cứ điều gì thực sự trong thế giới của chúng ta, điều đó quá khó đối với chúng. Hiện tại. Gì? Hiện tại.

Vâng, tôi nghĩ, này, thật tuyệt vời. Được rồi, vâng. Chỉ là vô vọng. Vâng. Tôi phải thực sự giỏi. Tôi thích thế giới, chúng ta sẽ phải thay đổi một trong hai điều đó. Tôi đồng ý. Tôi chia sẻ cảm giác đó rất mạnh mẽ, nhưng nếu bạn yêu cầu tôi thực sự xác định rõ, tại sao lại như vậy một lần nữa? Khi chúng, bạn biết đấy, đánh bại GPUX, GPUX, nhưng một số câu hỏi khoa học nóng hổi và những điều vớ vẩn khác. Kiểu như, tôi thực sự là gì? Tại sao chúng không thể hoàn thành mọi việc trong thế giới thực? Bạn đã có một cá nhân neurodivergent không quá giỏi về một thứ gì đó. Bạn vẫn nghĩ đến việc vượt qua cuộc sống. Vâng, vâng. Chúng đều rất giỏi đọc sách. Vâng. Vâng. Có rất nhiều người như vậy trên thế giới, đúng không? Điều đó không có gì đáng ngạc nhiên.

Và mặc dù cảm giác duy nhất của tôi về nó, tôi tin rằng nó giống như, à, hôm nay là ngày thứ 200 chiếc thẻ của tôi không bay khỏi Trái Đất với vận tốc thoát ly và bay lên Mặt Trăng. Kiểu như, đó là vì bạn không chế tạo một quả tên lửa. Vâng. Một năm trước có rất nhiều cuộc nói chuyện về, bạn biết đấy. Có lẽ tôi đã mô tả sai. Nhưng tôi nghĩ một năm trước có rất nhiều cuộc nói chuyện về khả năng vượt qua giới hạn của máy tính là ấn tượng vào ngày nay. Đã có. Đã có rất nhiều cuộc nói chuyện về điều đó. Tuy nhiên, tôi hầu như chưa nói chuyện với ai đã sử dụng chúng cho bất kỳ mục đích thực tế nào. Vâng. Hoàn toàn, hoàn toàn. Vâng.

Tương tác CLI so với GUI cho AI

Nhưng nếu chúng ta chỉ chuyển sang văn bản, và có vẻ hợp lý khi hoàn thành chỉ bằng văn bản, bạn sẽ vẫn lo lắng về tên lửa đó chứ? Không. Tôi sẽ không lo lắng. Tôi thực sự muốn. Tôi thực sự muốn làm điều đó. Nó phụ thuộc vào nhiệm vụ muốn làm gì. Vâng. Vâng. Kiểu việc mà bạn có thể, mà con người có thể làm chỉ qua CLI.

Vì vậy, tôi nghĩ đây là một chủ đề đã được thảo luận mà thực sự là tôi khi họ nói về cách, bạn biết đấy, một cách để sử dụng AI hiệu quả là cung cấp cho chúng, nếu bạn có một nhiệm vụ, hãy tìm cách trình bày nhiệm vụ hoặc chuyển đổi nhiệm vụ thành một cái gì đó phổ quát, bạn biết đấy, cho mô hình. Và tôi cảm thấy cuộc trò chuyện này, bạn biết đấy, liên quan đến điều đó, như, bạn biết đấy, tương tác với Chrome ít phổ biến hơn (trong dữ liệu đào tạo) so với CLI. Vì vậy tôi nghĩ đó có thể là một lĩnh vực nghiên cứu thú vị là, bạn biết đấy, được rồi, nếu bạn quan tâm đến việc khám phá, thì khả năng nó có thể thực hiện tốt đến mức nào thực sự là một câu hỏi mở trong nhiệm vụ.

Tối ưu hóa Tác vụ và Khả năng của Tác nhân AI

Đầu tiên, tôi nghĩ là việc tạo ra các harness (bộ khung) và giao diện giúp các mô hình dễ tiếp cận hơn nhiều, nhờ đó, điều đó ít đáng lo ngại hơn. Vâng. Tôi nghĩ điều này cũng đề cập đến một điểm về nhiều mô hình liên quan đến người có đặc điểm thần kinh khác biệt (neurodivergent models), bạn biết đấy, điều này cũng khác với quy mô quản lý hoặc việc giao các tác vụ dễ dàng, phù hợp cho những thực tập sinh rất tài năng của bạn, hoặc những thực tập sinh có đặc điểm thần kinh khác biệt rất tài năng, một điều gì đó tương tự. Tôi thực sự nghĩ điều đó đúng. Từ góc độ khả năng (capabilities), các giải pháp và tự động hóa R&D (Nghiên cứu và Phát triển), bạn biết đấy, tôi nghĩ có lẽ các mô hình sẽ trở nên cực kỳ giỏi trong việc tự xác định phạm vi tác vụ cho chính mình, sao cho nó là benchmark (điểm chuẩn) hoặc điều gì đó tương tự. Nhưng, bạn biết đấy, nếu chúng không thể làm được điều đó, tôi nghĩ, có rất nhiều thứ không giống benchmark mà lại phát sinh trong thế giới thực, và bạn cần phải có khả năng làm việc linh hoạt với chúng nếu muốn làm điều gì đó phức tạp như tự động hóa một công ty AI lớn.

Và bạn biết đấy, tôi thực sự nghĩ rằng có thể vừa đúng rằng AI hoạt động cực kỳ hiệu quả trên một loại vấn đề cụ thể, hoặc nếu bạn làm cho các loại vấn đề khác tương tự hơn về phạm vi hoặc hình dạng với loại vấn đề mà chúng giỏi nhất. Và cũng có thể đúng rằng chúng không thể linh hoạt thay thế con người, bởi vì điều đó yêu cầu bạn phải tự thiết lập vấn đề theo cách phù hợp hoặc không có những ràng buộc (constraints) đó. Vâng, điều thú vị là, khi bạn nói về khả năng mới, tôi nghĩ đến tất cả các trục khác trên đồ thị mà bạn có, bởi vì tôi nghĩ không chỉ có vấn đề về chân trời thời gian (time horizon), mà còn có một danh mục tác vụ hoặc loại công việc. Ví dụ như người dùng máy tính của bạn là một trong những ví dụ đó, phải không? Nếu chúng ta nghĩ về khả năng của người dùng máy tính so với, được rồi, khả năng mà chúng ta được yêu cầu sử dụng, so với khả năng có thể trở thành một tổng hợp có tính văn bản cao. Vâng, chắc chắn rồi. Nhưng rất nhiều benchmark này, hầu hết các benchmark này về cơ bản là văn bản. Vâng, vâng, vâng, và quả thực, bạn biết đấy, những cái không phải là văn bản, những cái đòi hỏi khả năng thị giác (vision capabilities), thì lại đặc biệt cụ thể.

Đánh giá Các Khả năng Đa dạng của Mô hình

Vâng, tôi không chắc chính xác phải làm gì với đồ thị này. Tôi nghĩ một điều tôi rút ra từ đó là, bạn biết đấy, có lẽ không có quá nhiều sự biến thiên trong kiểu thời gian tăng gấp đôi chậm, kém hiệu quả trên các phân phối tác vụ. Tôi nghĩ đó chỉ là bằng chứng yếu cho điều đó. Nhưng, bạn biết đấy, trong trạng thái hiện tại của chúng ta, có thể có rất nhiều sự đa dạng, đặc biệt là về khả năng giống như hình ảnh, so với các chiều (dimensions) khác, nhưng khả năng vật lý thậm chí còn hơn thế nữa, bạn biết đấy. Vâng, đúng vậy. Vì vậy, chính xác là, bạn có thể xem xét các tập hợp, nơi bạn có thể xem xét một thứ gì đó liên quan đến xúc giác, giống như, ngày nay, chúng sẽ có điểm số bằng 0. Không có gì có xúc giác. Vì vậy, nó không thể cho bạn biết bất cứ điều gì về xúc giác. Chà, bạn biết đấy, khi tạo đồ thị này, chúng tôi cố gắng làm cho các mô hình hoạt động tốt nhất có thể trong một số cài đặt nhất định. Vì vậy, chúng tôi cố gắng cung cấp cho chúng một số thứ liên quan đến xúc giác. Tôi biết chúng sẽ hoạt động ở đó. Chắc chắn, chắc chắn, chắc chắn. Nhưng, về không gian, chúng tôi có một số ví dụ. Vâng. Các khả năng khác, vâng. Các phán đoán không gian (space judgments), phán đoán thị giác không gian (spatial judgments) tương tự. Vâng. Bạn biết đấy, chúng tôi luôn thấy trong việc nhận diện hình ảnh, kiểm soát, và những thứ tương tự.

Tôi chỉ là, tôi thậm chí không biết liệu có ai đó đã liệt kê tất cả các khả năng mà chúng ta mong đợi trong tương lai. Giống như, nếu chúng ta thực sự muốn AGI (Trí tuệ Tổng quát Nhân tạo), thì danh sách đầy đủ các khả năng là gì? Đó là cách để bắt đầu một cuộc tranh luận không hồi kết. Tôi nghĩ là... Basil Halperin và Arjun Bramani hy vọng có một bài báo về vấn đề này. Đó là một trong những bài của Bramani. Vâng. Và sau đó chúng ta phải suy nghĩ xem chúng ta đang ở đâu và liệu tất cả các khả năng có tuân theo cùng một quy luật hay không. Tất cả các khả năng đang được đo lường hiện tại, chúng tuân theo cùng một log (quy luật logarit). Vâng. Điều đó dường như là một giả thuyết không (null hypothesis) hợp lý đối với bạn cũng như tôi, tôi nghĩ vậy. Không, không, không phải một đội chắc chắn, ý tôi là, bạn biết đấy, ai mà biết được? Vâng. Ồ, có một điều tôi muốn thêm vào đó. Ồ, vâng. Đây là một điều khác tôi nghĩ đến, không hoàn toàn thuộc lớp nghiên cứu, mặc dù cũng có liên quan.

Tự động hóa Nghiên cứu AI và Sản xuất Chip: Thách thức và Tiềm năng

Vì vậy, bạn biết đấy, một số người giống như tôi thuộc trường phái hoài nghi về phần mềm và điểm kỳ dị (singularity), đó là ý tưởng rằng bạn có thể tự động hóa nghiên cứu AI mà không cần tự động hóa thiết kế chip, và có lẽ cả sản xuất chip nữa. Bạn có thể nhanh chóng gặp phải các nút thắt cổ chai (bottleneck) về tính toán. Liệu có một phần cứng cố định không? Chỉ có rất nhiều thử nghiệm bạn có thể thực hiện mà sẽ đủ hiệu quả để tiến bộ. Nhưng, bạn biết đấy, ngay cả đối với những người như tôi, những người hoài nghi về điều đó, bạn có thể nghĩ rằng trên thực tế, sản xuất chip sẽ được tự động hóa, bạn biết đấy, robot đang đến, chúng có thể làm những việc mà con người làm, và sau đó có lẽ bạn thực sự có một nền kinh tế robot cộng với AI hoàn toàn tự duy trì. Và vì vậy, bạn có một xu hướng chậm chạp từ việc máy tính chậm lại, nhưng sau đó bạn lại có một sự bùng nổ trở lại một khi toàn bộ hệ thống đi vào một vòng lặp chặt chẽ.

Một cuộc tranh luận thú vị mà tôi nghe gần đây và muốn suy nghĩ thêm là, bạn biết đấy, tôi nghĩ trong thảo luận công khai, có cảm giác rằng, tại sao khả năng robot lại tụt hậu so với khả năng giống như LLM nhiều như vậy? Chà, đó là do dữ liệu đào tạo hoặc điều gì đó tương tự, hoặc có lẽ là do các ràng buộc phần cứng. Vâng. Tôi tò mò liệu đó có phải là do các ràng buộc phần cứng không. Tôi thích, chính xác thì những ràng buộc phần cứng này là gì? Nếu chúng ta đặt siêu trí tuệ (superintelligence) vào bên trong, giống như các siêu máy tính cổ điển, vào bên trong, bạn biết đấy, các bộ phận phần cứng tồn tại ngày nay, liệu nó có thể xây dựng các cơ sở sản xuất chip không? Và tôi biết điều đó bởi vì tôi, bạn biết đấy, tôi đã tìm hiểu rất sâu, nhưng không rõ ràng đối với tôi câu trả lời là gì. Tôi nghĩ điều đó khá hợp lý. Tôi không chắc bạn cần loại điều khiển động cơ tinh vi (fine motor control) rất linh hoạt này để làm điều đó. Tôi cũng nghĩ có lẽ điều khiển động cơ tinh vi có thể được kiểm soát bởi siêu trí tuệ. Công bằng mà nói, các khía cạnh chính của sản xuất chip là... xin lỗi. Nhưng tôi cũng đang nghĩ đến việc chế tạo robot. Và, bạn biết đấy, toàn bộ quá trình.

Thách thức của Sản xuất và Công nghệ Tự lái

Và đó là lúc tôi sẽ nói rằng, tôi có một người bạn, hầu hết sự nghiệp của anh ấy là phát triển phần mềm, nhưng trong thời gian COVID đã bắt đầu sản xuất những thứ như thiết bị bảo hộ cá nhân (PPEs) và những thứ giúp ích cho mọi người. Và anh ấy đã nhận ra thế giới sản xuất khó khăn đến mức nào và quy trình lặp lại (iteration process) chậm đến mức nào. Và thực sự, anh ấy nói rằng, anh ấy biết nó sẽ tệ hơn. Anh ấy không hiểu rằng nó tệ hơn một cấp độ tiếp theo, như một bậc độ lớn. Và tôi nghĩ rằng có lẽ, bạn biết đấy, từ góc độ của chúng ta, những người không làm điều đó và nghĩ rằng, nó tệ đến mức nào được chứ? Và phản hồi mà tôi nhận được từ tất cả những người thực sự làm việc trong lĩnh vực đó thì khác xa rất nhiều. Đó cũng là điều tôi đồng tình. Tôi chỉ nói chuyện một chút với những người làm việc trong các xưởng sản xuất chip (fabs) và những thứ tương tự, nhưng tôi đã ngạc nhiên khi nói chuyện với họ về mức độ chuyên môn của con người cần thiết. Vâng. Để làm việc tại xưởng sản xuất chip, rất nhiều công việc đó thực sự có mức lương khá cao, và đó là những công việc để thành công. Hơn nữa, sự cải thiện thực sự diễn ra rất chậm (glacial) so với phần mềm, phải không? Tôi nghĩ cũng bởi vì phải tốn hàng tỷ đô la để xây dựng một nhà máy. Vì vậy, mỗi lần lặp lại là một chi phí rất lớn. Thật tàn khốc.

Vì vậy, tôi nghĩ đó là lý do tại sao nó khó phát triển đối với tôi. Ý tôi là, chỉ cần cho chúng thêm vài thế kỷ nữa. Có thể chúng sẽ làm được. Tôi nghĩ, bạn có vài thế kỷ ở đâu? Tôi có. Tôi thực sự nghĩ rằng tôi chỉ giữ quan điểm giống như bạn về việc một số tác vụ này dễ dàng như thế nào. Vâng. Chúng ta nghĩ chúng dễ dàng, nhưng theo kinh nghiệm của tôi, giống như, tôi không biết khi nào cái thứ tự lái (self-driving) này ra đời. Khi mọi người đang thúc đẩy, và tôi thực sự đã làm việc trong lĩnh vực đó một thời gian, và tôi nghĩ, tôi hiểu rằng chúng ta có thể đến rất gần với nó, nhưng để đạt được một cái gì đó hoàn toàn chấp nhận được (acceptable) là cực kỳ khó khăn, phải không? Và chúng ta đánh giá thấp mức độ công việc liên quan đến việc hoàn thành phần cuối cùng đó. 90% đầu tiên. Tôi biết chúng ta có thể làm được với máy tính khoảng 10 năm trước, gần như vậy, nhưng để đến được phần cuối cùng mà mọi người đều hài lòng với nó. Vâng, tôi cũng cảm thấy điều này. Tôi chưa lấy bằng lái xe. Vâng, không sao cả. Bởi vì tôi mong đợi chi phí tự lái sẽ đến. Vâng, tôi nghĩ điều đó là hiển nhiên, nhưng nó chưa lâu đến vậy. Và họ đang mở rộng ra toàn bộ vùng vịnh (Bay Area). Tôi chắc chắn đó là điều nghiêm túc. Họ sẽ đạt được điều đó. Tôi nghĩ nó sẽ mất rất nhiều thời gian.

Liệu nền kinh tế robot có xây dựng sản xuất chip không? Sẽ mất hàng thế kỷ. Tôi không biết, tôi có thể thấy rằng nó có thể mất, một phần của mẹo với tự lái là động lực kinh tế đang thúc đẩy nó nhanh chóng, phải không? Và có lẽ việc robot chế tạo robot cũng sẽ đưa chúng ta đến, vâng, nơi chúng ta đang ở hiện tại giống như Rip-Rap là nơi chúng ta đã đạt được, robot chế tạo robot, phải không? Điều đó là. Ồ, nhưng tôi cảm thấy, bạn biết đấy, liệu điều đó có đang chú ý đủ đến các biểu đồ không? GPT2 năm 2019. Nó rất gần đây. Tôi đã làm điều này rất không theo lối suy nghĩ thông thường, nhưng tôi nghĩ, có lẽ chúng ta đang ở trong một khoảnh khắc GPT nào đó. Vâng, đó là một điểm hợp lý. Vâng, tôi có thể sai. Chỉ là tôi đoán nó sẽ mất nhiều thời gian hơn chúng ta nghĩ. Vì vậy, nó sẽ có thể thực hiện sản xuất hàng loạt thực sự. Vâng. Ở một quy mô gây ra loại tác động toàn cầu mà bạn đang nói đến. Vâng. Và điều đó đúng, tôi nghĩ chúng có thể làm rất tốt việc chế tạo các sản phẩm độc bản (one-offs), phải không? Robot rất giỏi trong việc chế tạo các sản phẩm độc bản ở quy mô nhỏ, nhưng hoàn toàn không thực tế để làm điều đó ở quy mô lớn.

Khoảng cách trong Mô hình Robot và Triển vọng AI trong Chế tạo

Có một sự thật, tôi nghĩ nó khá đáng chú ý. Liệu có phải điều này không? Vâng, vâng. Tốc độ tính toán (compute) dành cho các mô hình robot đang tụt lại phía sau, xin lỗi, nó gần như giống nhau, nhưng mức độ chênh lệch theo bậc độ lớn (orders of magnitude difference). Tôi tò mò liệu đó có phải là, nếu tôi nói gần đúng. Dường như ít nhất các robot có khả năng hơn, ở một khía cạnh nào đó, rất có thể sẽ sớm trở thành hiện thực. Không, tôi không nói là toàn bộ quá trình. Tôi chắc chắn không nói là sản xuất thực sự. Nó dường như có một số loại thiếu sót dữ liệu (data gap) nào đó. Vâng, vâng. Đối với tôi thì đúng vậy. Điều thú vị là, cũng suy nghĩ rằng bạn không chỉ cần mở rộng dữ liệu (scaling data), bạn cũng có thể mở rộng các tham số (scale parameters), sử dụng cùng một lượng dữ liệu, đó là cách nó được sử dụng để tính toán để thu hẹp khoảng cách đó. Bạn hiểu không? Vâng.

Vì vậy, một trong ba người vừa cung cấp cho tôi một cái nhìn tổng quan rất thú vị về một lĩnh vực tôi đang đi sâu vào chế tạo (fabrication). Và điều gì giống nhau? Vì vậy, nó nói rằng, có rất nhiều lo ngại, nơi mà hiện tại nó có thể sẽ giúp ích khá đáng kể trong tương lai. Và rất nhiều trong số đó đã nằm trong các khía cạnh tính toán (computational aspects). Có rất nhiều vấn đề với các bước cuối cùng của việc thiết kế tốn kém, như mặt nạ (mask). Đó là khuôn mẫu mà bạn đang sử dụng cho tia laser để tạo ra các bóng bán dẫn (transistors). Và việc tính toán đó, cách xây dựng nó, một lần nữa, đảm bảo rằng nó tuân thủ thông số kỹ thuật (spec) mà bạn đã viết về cơ bản là cực kỳ tốn kém về mặt tính toán (computationally expensive). Và có rất nhiều cơ hội để AI giúp đỡ ở đó. Và về mặt lý thuyết cũng có khả năng, bạn biết đấy, rõ ràng, việc sản xuất là cực kỳ chính xác, nhưng cũng mong manh.

Phát hiện lỗi sản xuất bằng AI

Cơ hội để một Trí tuệ nhân tạo (AI) phát hiện các tham số cơ bản bị sai lệch dẫn đến khả năng thất bại tiềm tàng, và từ đó ngăn chặn hoặc giảm thiểu chúng, về mặt lý thuyết có thể là giải pháp cho một vấn đề lớn liên quan đến năng suất sản xuất. Trên thực tế, đây là một thách thức phổ biến đối với các nhà sản xuất. Ví dụ, lý do các CPU có tốc độ khác nhau là vì chúng thực sự được sản xuất trên cùng một dây chuyền; một số linh kiện tốt hơn, số khác lại kém hơn. Đó là lý do tại sao các mô hình có GHz cao hơn thì đắt hơn, và các mô hình thấp hơn thì rẻ hơn. Tương tự, đối với những người làm video, các GPU dân dụng của bạn—chẳng hạn như dòng 50, 60, 70, 80, 90—về cơ bản đều là cùng một chip, phải không? Chúng chỉ có chất lượng khác nhau, mức độ lỗi cố hữu khác nhau.

Thông báo kết thúc ghi âm

Không. Nhưng vấn đề là... Đó là đoạn ghi âm của chúng tôi. Họ sẽ cắt bỏ sớm thôi, nhưng cứ thoải mái tham gia thảo luận nhé. Được rồi.