Andrej Karpathy: From Vibe Coding to Agentic Engineering

• Andrej Karpathy nhận thấy sự thay đổi cơ bản trong lập trình viên, từ việc sử dụng AI như công cụ hỗ trợ sang các luồng công việc tác nhân (agentic workflows) tự chủ hoàn toàn, nơi AI thực hiện các tác vụ phức tạp với ít sự can thiệp của con người hơn.
• Mô hình ngôn ngữ lớn (LLMs) được xem là một mô hình điện toán (Software 3.0) mới, nơi việc "lập trình" chủ yếu xoay quanh việc ra lệnh (prompting) và quản lý ngữ cảnh, mở ra khả năng xử lý thông tin và tri thức mà trước đây không thể thực hiện chỉ bằng mã truyền thống.
• Trí tuệ của LLMs thể hiện tính "lởm chởm" (jagged intelligence), rất mạnh trong các lĩnh vực có khả năng kiểm chứng cao như toán học và lập trình, nhưng yếu hơn ở những lĩnh vực khác. Điều này đòi hỏi người dùng phải hiểu rõ giới hạn và xem xét việc tinh chỉnh (fine-tuning) cho các trường hợp cụ thể.

• Chuyển đổi sang luồng công việc tác nhân: Thay vì xem AI là công cụ hỗ trợ, hãy tận dụng các mô hình ngôn ngữ lớn để tạo ra các luồng công việc tự chủ (agentic workflows) có thể xử lý các tác vụ phức tạp một cách độc lập, giảm thiểu sự can thiệp và gỡ lỗi thủ công.
• Lập trình trong Software 3.0: Coi LLMs là một mô hình điện toán mới, nơi kỹ năng lập trình chuyển từ viết mã sang việc thiết kế lệnh nhắc (prompting) hiệu quả và quản lý cửa sổ ngữ cảnh (context window) để hướng dẫn LLM thực hiện tính toán.
• Tái tư duy kiến trúc ứng dụng: Đánh giá lại các ứng dụng hiện có của bạn; nhiều ứng dụng truyền thống có thể trở nên lỗi thời, được thay thế bằng các lệnh nhắc trực tiếp tới LLM, đặc biệt với khả năng đa phương thức (multimodal) như xử lý hình ảnh và tạo nội dung.
• Khai thác khả năng xử lý tri thức: Sử dụng LLMs để tự động hóa việc tạo và sắp xếp các cơ sở tri thức, wikis hoặc các hệ thống thông tin không có cấu trúc, vượt ra ngoài khả năng của lập trình dữ liệu có cấu trúc truyền thống.
• Ưu tiên các vấn đề có khả năng kiểm chứng: Khi phát triển sản phẩm hoặc giải pháp mới, tập trung vào các lĩnh vực mà đầu ra có thể dễ dàng kiểm chứng được. Đây là những nơi LLMs hoạt động hiệu quả nhất nhờ cơ chế học tăng cường (reinforcement learning).
• Hiểu rõ "trí tuệ lởm chởm": Nhận thức rằng năng lực của LLMs không đồng đều. Chúng xuất sắc trong các "mạch" được tối ưu hóa trong quá trình huấn luyện (ví dụ: viết mã, toán học), nhưng có thể thất bại trong các tình huống tưởng chừng đơn giản nằm ngoài phân phối dữ liệu đó.
• Xem xét tinh chỉnh (fine-tuning): Nếu ứng dụng của bạn nằm ngoài các lĩnh vực mà LLMs hiện tại hoạt động tốt "out of the box", hãy chuẩn bị tinh chỉnh mô hình với dữ liệu cụ thể của bạn để đạt được hiệu suất mong muốn.
• Hình dung máy tính thần kinh: Chuẩn bị cho một tương lai nơi mạng nơ-ron có thể trở thành "tiến trình chủ" (host process) chính, và các CPU truyền thống đóng vai trò "bộ đồng xử lý" (co-processor), làm thay đổi cơ bản cách chúng ta thiết kế và tương tác với hệ thống điện toán.

• vibe coding — lập trình dựa trên cảm hứng/linh cảm
• agentic workflow — luồng công việc tác nhân (tự chủ)
• LLMs (Large Language Models) — mô hình ngôn ngữ lớn
• computing paradigm — mô hình điện toán
• Software 3.0 — Phần mềm 3.0
• prompting — ra lệnh/nhắc lệnh
• context window — cửa sổ ngữ cảnh
• verifiability — khả năng kiểm chứng/tính xác minh
• jagged intelligence — trí tuệ lởm chởm (không đồng đều)
• fine-tuning — tinh chỉnh

Cảm thấy tụt hậu với vai trò lập trình viên

Chúng tôi rất vui mừng chào đón vị khách mời đặc biệt đầu tiên. Anh ấy đã góp phần xây dựng, giải thích và đôi khi đổi tên AI hiện đại. Anh ấy thực sự đã giúp đồng sáng lập OpenAI ngay trong văn phòng này, là người đã đưa Autopilot vào hoạt động tại Tesla trước đây, và anh ấy có một tài năng hiếm có là khiến những chuyển đổi kỹ thuật phức tạp nhất trở nên dễ tiếp cận và dường như không thể tránh khỏi. Các bạn đều biết anh ấy vì đã đặt ra thuật ngữ vibe coding vào năm ngoái, nhưng chỉ trong vài tháng gần đây, anh ấy đã nói một điều còn đáng kinh ngạc hơn: đó là anh ấy chưa bao giờ cảm thấy tụt hậu nhiều đến thế với tư cách là một lập trình viên. Đó là nơi chúng ta sẽ bắt đầu ngày hôm nay. Cảm ơn Andre đã tham gia cùng chúng tôi. >> Vâng. Xin chào. Rất vui được có mặt ở đây và cùng bắt đầu. >> Được rồi. Chỉ vài tháng trước, anh nói rằng anh chưa bao giờ cảm thấy tụt hậu nhiều đến thế với tư cách là một lập trình viên. Thật đáng ngạc nhiên khi nghe điều đó từ chính anh. Anh có thể giúp chúng tôi lý giải điều này không? Cảm giác đó là phấn khởi hay bất an?

Chuyển đổi từ công cụ hỗ trợ sang luồng công việc tự chủ của AI

Vâng, chắc chắn là cả hai cảm giác đó đều có. À, trước hết, tôi đoán giống như nhiều người trong số các bạn, tôi đã sử dụng các agentic tools (công cụ tác nhân) như LotCode và những thứ tương tự trong một thời gian, có lẽ là từ năm ngoái khi chúng mới ra mắt. Chúng rất giỏi trong việc tạo ra các đoạn mã, và đôi khi chúng có thể mắc lỗi và bạn phải chỉnh sửa chúng, nhưng nói chung là hữu ích. Và sau đó, tôi phải nói rằng tháng 12 là một bước ngoặt rõ ràng, đối với tôi, lúc đó tôi đang nghỉ ngơi nên có nhiều thời gian hơn một chút. Tôi nghĩ nhiều người khác cũng tương tự, và tôi bắt đầu nhận thấy rằng với các mô hình mới nhất, các đoạn mã tạo ra đều hoạt động tốt, và sau đó tôi cứ tiếp tục yêu cầu thêm, và chúng vẫn hoạt động tốt. Tôi không nhớ lần cuối cùng mình phải sửa lỗi là khi nào, và sau đó tôi chỉ, bạn biết đấy, tin tưởng hệ thống ngày càng nhiều hơn, và rồi tôi đã vibe coding [tiếng cười]. Và vì vậy, tôi thực sự nghĩ rằng đó là một sự chuyển đổi rất rõ rệt. Tôi nghĩ rằng rất nhiều người, thực ra, tôi đã cố gắng nhấn mạnh điều này trên Twitter hay X, bởi vì tôi nghĩ nhiều người đã trải nghiệm AI vào năm ngoái như những thứ tương tự ChatGPT. Nhưng bạn thực sự phải nhìn lại, và bạn phải nhìn từ tháng 12 trở đi, bởi vì mọi thứ đã thay đổi về cơ bản, đặc biệt là với workflow (luồng công việc) agentic (tác nhân) và nhất quán này đã thực sự bắt đầu hoạt động. Và vì vậy, tôi phải nói rằng, vâng, chính nhận thức đó đã thực sự khiến tôi lao vào một chuỗi các dự án phụ không ngừng. Thư mục các dự án phụ của tôi cực kỳ đầy ắp với rất nhiều thứ ngẫu nhiên, và chỉ là vibe coding mọi lúc. Vì vậy, vâng, điều đó đã xảy ra vào tháng 12, tôi nghĩ vậy, và tôi đã theo dõi những hệ quả của nó kể từ đó.

LLM như một mô hình tính toán mới: Từ Software 1.0 đến 3.0

Anh đã nói rất nhiều về ý tưởng LLMs (mô hình ngôn ngữ lớn) như một máy tính mới, rằng đó không chỉ là phần mềm tốt hơn, mà là một computing paradigm (mô hình điện toán) hoàn toàn mới. Software 1.0 là các quy tắc rõ ràng, Software 2.0 là learned weights (trọng số học được), Software 3.0 là hiện tại. Nếu điều đó thực sự đúng, một nhóm sẽ xây dựng khác biệt như thế nào vào ngày họ thực sự tin vào điều này? >> Đúng vậy. Chính xác là như vậy. Với Software 1.0, tôi viết mã. Software 2.0, tôi thực sự lập trình bằng cách tạo tập dữ liệu và huấn luyện các neural networks (mạng nơ-ron). Vì vậy, việc lập trình giống như sắp xếp các tập dữ liệu, có thể là một số mục tiêu và các neural network architectures (kiến trúc mạng nơ-ron). Và rồi điều xảy ra là về cơ bản, nếu bạn huấn luyện một trong những GPT models (mô hình GPT) hoặc LLMs này trên một tập hợp đủ lớn các tác vụ, một cách ngầm định—về cơ bản là ngầm định, bởi vì bằng cách huấn luyện trên internet, bạn phải multitask (thực hiện đa nhiệm) tất cả những thứ có trong tập dữ liệu—chúng thực sự trở thành một loại máy tính có thể lập trình được theo một nghĩa nào đó. Vì vậy, Software 3.0 là về việc, bạn biết đấy, việc lập trình của bạn giờ đây chuyển sang prompting (ra lệnh), và những gì có trong context window (cửa sổ ngữ cảnh) là đòn bẩy của bạn đối với trình thông dịch là LLM, thứ đang diễn giải ngữ cảnh của bạn và thực hiện computation (tính toán) trong không gian thông tin kỹ thuật số. Vì vậy, tôi đoán, vâng, đó là một kiểu chuyển đổi, và tôi nghĩ có một vài ví dụ đã thực sự giúp tôi hiểu rõ điều này, và có lẽ chúng có thể mang tính hướng dẫn.

Ví dụ về cài đặt OpenClaw: Sức mạnh của tác nhân trong Software 3.0

Ví dụ, khi OpenClaw ra mắt, khi bạn muốn cài đặt OpenClaw, bạn sẽ mong đợi rằng thông thường đây là một bash script (tập lệnh bash), giống như một shell script (tập lệnh shell). Vì vậy, bạn chạy shell script để cài đặt OpenClaw. Nhưng vấn đề là, để nhắm mục tiêu đến nhiều nền tảng và nhiều loại máy tính khác nhau mà bạn có thể chạy OpenClaw trên đó, những shell script này thường phình to và trở nên cực kỳ phức tạp. Nhưng vấn đề là bạn vẫn bị mắc kẹt trong vũ trụ Software 1.0 của việc muốn tự viết mã. Và thực ra, việc cài đặt OpenClaw là một đoạn văn bản bạn chỉ cần sao chép và dán cho agent (tác nhân) của mình. Vì vậy, về cơ bản, đó là một kỹ năng nhỏ của việc, bạn biết đấy, sao chép và dán cái này rồi đưa cho agent của bạn, và nó sẽ cài đặt OpenClaw. Và lý do điều này mạnh mẽ hơn nhiều là bạn đang làm việc trong Software 3.0 paradigm (mô hình Software 3.0) nơi bạn không cần phải chỉ rõ từng chi tiết riêng lẻ của thiết lập đó. Agent có trí thông minh riêng mà nó tổng hợp, sau đó nó tuân theo các hướng dẫn, xem xét môi trường, máy tính của bạn và thực hiện các intelligent actions (hành động thông minh) để mọi thứ hoạt động, và nó debugs (gỡ lỗi) mọi thứ trong vòng lặp, và điều đó mạnh mẽ hơn rất nhiều, phải không? Vì vậy, tôi nghĩ đó là một cách suy nghĩ rất khác biệt: chỉ là đoạn văn bản nào cần sao chép và dán cho agent của bạn? Đó là programming paradigm (mô hình lập trình) mới.

Ví dụ về MenuGen: Từ ứng dụng phức tạp đến lệnh nhắc đơn giản

Một ví dụ khác mà tôi nghĩ đến, thậm chí còn cực đoan hơn, là khi tôi đang xây dựng MenuGen. MenuGen là ý tưởng mà bạn đến một nhà hàng, họ đưa cho bạn một thực đơn. Thường thì không có hình ảnh. Vì vậy, tôi không biết bất kỳ món nào trong số đó là gì—thường thì khoảng 30% hoặc 50% các món tôi hoàn toàn không biết. Vì vậy, tôi muốn chụp ảnh thực đơn nhà hàng và lấy hình ảnh về những món đó trông như thế nào theo nghĩa chung. Và thế là tôi đã xây dựng, tôi đã vibe coded (lập trình dựa trên cảm hứng) ứng dụng này về cơ bản cho phép bạn tải ảnh lên, nó thực hiện tất cả những thứ này, và chạy trên Vercel. Và về cơ bản nó dựng lại thực đơn và cung cấp cho bạn tất cả các món, và nó cung cấp cho bạn một hình ảnh mà nó sử dụng một image generator (trình tạo hình ảnh) để về cơ bản OCR (nhận dạng ký tự quang học) tất cả các tiêu đề khác nhau, sử dụng image generator để lấy hình ảnh của chúng và sau đó hiển thị cho bạn. Và sau đó tôi đã thấy phiên bản Software 3.0 của điều này, điều đã khiến tôi kinh ngạc, đó là chỉ cần chụp ảnh của bạn, đưa nó cho Gemini, và nói, 'Sử dụng NanoBanana để phủ các mục lên thực đơn.' Và NanoBanana về cơ bản đã trả về một hình ảnh chính xác là bức ảnh thực đơn tôi đã chụp, nhưng nó thực sự đã đưa vào các pixel, nó đã hiển thị các món khác nhau trong thực đơn. Và điều này khiến tôi kinh ngạc bởi vì thực ra tất cả MenuGen của tôi là vô nghĩa. Nó đang hoạt động trong mô hình cũ; ứng dụng đó không nên tồn tại. Và, vâng, Software 3.0 paradigm (mô hình Software 3.0) thì thô sơ hơn rất nhiều. Neural network (mạng nơ-ron) của bạn đang thực hiện ngày càng nhiều công việc, và prompt (lệnh nhắc) hoặc context (ngữ cảnh) của bạn chỉ là hình ảnh, và đầu ra là một hình ảnh, và không cần có bất kỳ ứng dụng nào ở giữa.

Cơ hội mới: Xử lý thông tin và tri thức không chỉ là lập trình

Vì vậy, tôi nghĩ rằng mọi người phải thay đổi cách nhìn nhận, bạn biết đấy, không nên làm việc trong mô hình hiện có của những thứ đã tồn tại và chỉ nghĩ về nó như một sự tăng tốc của những gì đã có. Thực ra, những điều mới đang có sẵn bây giờ. Và quay trở lại câu hỏi lập trình của bạn, nó thậm chí không phải—tôi nghĩ đó cũng là một ví dụ về việc làm việc trong tư duy cũ—bởi vì nó không chỉ là về lập trình và lập trình trở nên nhanh hơn. Đây là một information processing (xử lý thông tin) tổng quát hơn mà giờ đây có thể automatable (tự động hóa). Vì vậy, nó thậm chí không chỉ là về mã. Mã trước đây hoạt động với dữ liệu có cấu trúc (structured data), phải không? Và bạn viết mã trên structured data. Nhưng ví dụ, với dự án cơ sở tri thức LLM của tôi, về cơ bản bạn có thể nhờ LLMs tạo wikis (wiki) cho tổ chức của bạn hoặc cho cá nhân bạn, v.v. Đây thậm chí không phải là một chương trình. Đây không phải là thứ có thể tồn tại trước đây vì không có mã nào có thể tạo knowledge base (cơ sở tri thức) dựa trên một loạt sự thật. Nhưng bây giờ bạn chỉ cần lấy những tài liệu này và về cơ bản biên dịch lại chúng theo một cách khác, sắp xếp lại chúng và tạo ra một thứ gì đó mới mẻ và thú vị như một cách định hình lại dữ liệu. Và vì vậy, đây là những điều mới mà trước đây không thể thực hiện được. Và vì vậy tôi nghĩ đây là điều mà tôi liên tục cố gắng quay lại, không chỉ là những gì chúng ta có thể làm mà trước đây đã tồn tại và giờ nhanh hơn, mà tôi nghĩ có những cơ hội mới về những điều mà trước đây không thể thực hiện được, và tôi gần như nghĩ rằng điều đó thú vị hơn.

Tương lai của lập trình: Điều gì sẽ hiển nhiên vào năm 2026?

Tôi rất thích sự tiến triển và đối lập của MenuGen mà anh đã trình bày, và tôi nghĩ ngay cả—tôi chắc rằng nhiều người ở đây đã theo dõi sự tiến bộ lập trình của chính anh từ tháng 10 năm ngoái đến đầu tháng 1/2 năm nay. Nếu bạn suy rộng điều đó hơn nữa, thì điều gì sẽ tương đương vào năm 2026, đối với việc xây dựng các trang web vào những năm 90, xây dựng ứng dụng di động vào những năm 2010, xây dựng SaaS (phần mềm dịch vụ) trong kỷ nguyên Claude (điện toán đám mây) vừa qua? Điều gì sẽ trở nên hoàn toàn hiển nhiên khi nhìn lại, nhưng hiện tại vẫn chưa được xây dựng nhiều?

Tương lai của điện toán: Máy tính thần kinh và sự đảo ngược vai trò

[hắng giọng] Chà, quay trở lại với ví dụ MenuGen, tôi đoán, rất nhiều mã này không nên tồn tại và chỉ là các neural networks (mạng nơ-ron) đang làm hầu hết công việc. Tôi thực sự nghĩ rằng phép ngoại suy này trông rất kỳ lạ bởi vì bạn có thể hình dung—tôi không biết—vâng, bạn có thể hình dung các neural computers (máy tính thần kinh) hoàn toàn theo một nghĩa nào đó. Bạn đưa raw videos (video thô), như tưởng tượng một thiết bị lấy raw videos hoặc audio (âm thanh) vào về cơ bản là một neural net (mạng nơ-ron), và sử dụng diffusion (khuếch tán) để tạo ra một UI (giao diện người dùng) độc đáo cho khoảnh khắc đó theo một nghĩa nào đó. Và tôi cảm thấy như vào những ngày đầu của điện toán, thực ra, mọi người đã hơi bối rối về việc liệu máy tính sẽ trông giống máy tính bỏ túi hay máy tính sẽ trông giống neural nets. Vào những năm 50 và 60, không thực sự rõ ràng hướng nào sẽ đi, và tất nhiên, chúng ta đã đi theo con đường máy tính bỏ túi và cuối cùng đã xây dựng classical computing (điện toán cổ điển). Và sau đó các neural nets hiện đang chạy ảo hóa trên các máy tính hiện có, nhưng tôi nghĩ bạn có thể hình dung rằng rất nhiều điều này sẽ đảo ngược, và neural net trở thành một loại host process (tiến trình chủ), và các CPUs (bộ xử lý trung tâm) trở thành một loại co-processor (bộ đồng xử lý). Vì vậy, chúng ta đã thấy biểu đồ về, bạn biết đấy, intelligent compute (điện toán thông minh) của neural networks sẽ chiếm ưu thế và trở thành khoản chi tiêu flops (số phép toán dấu phẩy động mỗi giây) chủ đạo. Vì vậy, bạn có thể hình dung một điều gì đó thực sự kỳ lạ và xa lạ, nơi neural nets đang thực hiện hầu hết công việc nặng nhọc. Chúng sử dụng tool use (sử dụng công cụ) như một phụ lục lịch sử cho một số loại deterministic tasks (nhiệm vụ xác định). Nhưng điều thực sự điều hành mọi thứ là các neural nets này theo một cách nào đó. Vì vậy, bạn có thể hình dung một điều gì đó cực kỳ xa lạ như phép ngoại suy, nhưng tôi nghĩ chúng ta có thể sẽ đạt được điều đó từng chút một.

Khái niệm về khả năng kiểm chứng và các công việc tự động hóa

[cười khẩy] >> Tôi muốn nói một chút về khái niệm verifiability (khả năng kiểm chứng), thực tế là AI sẽ tự động hóa nhanh hơn và dễ dàng hơn các lĩnh vực mà đầu ra có thể được verified (kiểm chứng). Nếu khung lý thuyết đó đúng, thì công việc nào sắp phát triển nhanh hơn nhiều so với những gì mọi người nhận ra, và những ngành nghề nào mà mọi người thực sự nghĩ là an toàn nhưng thực ra lại có verifiability cao? >> Vâng. Tôi đã dành một thời gian viết về verifiability, và về cơ bản, máy tính truyền thống có thể dễ dàng tự động hóa những gì bạn có thể chỉ định bằng mã. Và đợt LLMs mới nhất này có thể dễ dàng tự động hóa những gì bạn có thể verify theo một nghĩa nào đó, bởi vì cách thức hoạt động là khi các frontier labs (phòng thí nghiệm tiên phong) đang huấn luyện những LLMs này, đây là những môi trường reinforcement learning (học tăng cường) khổng lồ.

Tính "lởm chởm" (Jaggedness) của Mô hình và Khả năng Xác minh

Các mô hình được thưởng dựa trên khả năng xác minh, và do cách chúng được huấn luyện, chúng phát triển thành những thực thể "lởm chởm" (jagged entities), đạt đỉnh cao về năng lực trong các lĩnh vực có thể verifiable như toán học, lập trình và các lĩnh vực liên quan. Ngược lại, chúng có xu hướng trì trệ và còn "thô" (rough around the edges) khi không thuộc các không gian đó. Tôi viết về khả năng verifiability (tính xác minh) vì tôi muốn hiểu tại sao những mô hình này lại có vẻ "lởm chởm" như vậy. Một phần là do cách các phòng thí nghiệm huấn luyện mô hình, nhưng tôi nghĩ một phần khác là do trọng tâm của các phòng thí nghiệm và những gì họ đưa vào phân phối dữ liệu (data distribution). Một số thứ có giá trị kinh tế hơn đáng kể và tạo ra nhiều môi trường hơn vì các phòng thí nghiệm muốn làm việc trong những thiết lập đó. Mã nguồn (code) là một ví dụ điển hình. Có lẽ có rất nhiều môi trường verifiable mà họ có thể nghĩ đến nhưng không được đưa vào vì chúng không thực sự hữu ích để phát triển năng lực.

Tuy nhiên, đối với tôi, điều bí ẩn lớn nhất là ví dụ yêu thích trong một thời gian là: "Có bao nhiêu chữ cái trong từ 'strawberry'?" Các mô hình thường xuyên trả lời sai câu này, đó là một ví dụ về tính "lởm chởm". Tôi nghĩ giờ đây các mô hình đã khắc phục được lỗi này, nhưng ví dụ mới là: "Tôi muốn đi rửa xe và tiệm rửa xe cách đây 50 mét. Tôi nên lái xe hay đi bộ?" Các mô hình state-of-the-art ngày nay sẽ bảo bạn đi bộ vì nó quá gần. Làm thế nào một mô hình state-of-the-art như Opus 4.7 lại có thể đồng thời tái cấu trúc một codebase 100.000 dòng mã hoặc tìm ra các lỗ hổng zero-day vulnerabilities và yet tells me to walk to this car wash? Điều này thật điên rồ! Và chừng nào những mô hình này còn "lởm chởm", đó là dấu hiệu cho thấy, thứ nhất, có thể có điều gì đó hơi sai lệch, hoặc thứ hai, bạn cần phải tham gia vào vòng lặp (in the loop) một chút và xem chúng như những công cụ, đồng thời bạn phải theo dõi những gì chúng đang làm.

Tóm lại, tất cả những gì tôi viết về khả năng verifiability chỉ nhằm cố gắng hiểu tại sao những điều này lại "lởm chởm" như vậy. Liệu có bất kỳ mẫu hình nào không? Và tôi nghĩ đó là sự kết hợp của khả năng verifiable cộng với sự quan tâm của các phòng thí nghiệm.

Một giai thoại khác mang tính hướng dẫn là từ GPT-3.5 đến GPT-4, mọi người nhận thấy cờ vua (chess) đã cải thiện rất nhiều. Nhiều người nghĩ rằng đó chỉ là sự tiến bộ về năng lực, nhưng thực ra, đó là do – tôi nghĩ đây là thông tin công khai, tôi đã thấy trên internet – một lượng lớn dữ liệu cờ vua đã được đưa vào tập dữ liệu pre-training. Chỉ vì nó nằm trong data distribution (phân phối dữ liệu), mô hình đã cải thiện nhiều hơn đáng kể so với việc chỉ mặc định. Vậy là, ai đó tại OpenAI đã quyết định thêm dữ liệu này và giờ đây bạn có một năng lực đạt đỉnh cao hơn rất nhiều. Đó là lý do tại sao tôi nhấn mạnh khía cạnh này: chúng ta phần nào phụ thuộc vào những gì các phòng thí nghiệm đang làm, những gì họ đưa vào. Và bạn phải thực sự khám phá cái thứ mà họ cung cấp cho bạn, cái mà không có hướng dẫn sử dụng. Nó hoạt động trong một số cài đặt, nhưng có thể không trong những cài đặt khác. Và bạn phải tự mình khám phá nó một chút. Nếu bạn đang ở trong các "mạch" là một phần của reinforcement learning (RL), bạn sẽ "bay cao". Còn nếu bạn đang ở trong các "mạch" nằm ngoài data distribution, bạn sẽ gặp khó khăn và phải tìm ra mình đang ở trong "mạch" nào trong ứng dụng của mình. Nếu không thuộc các "mạch" đó, bạn phải thực sự xem xét việc fine-tuning (tinh chỉnh) và tự làm một số công việc của riêng mình, bởi vì nó sẽ không nhất thiết đến từ LLM (mô hình ngôn ngữ lớn) một cách tự động (out of the box).

Lời khuyên cho Founder và các Lĩnh vực có thể Tự động hóa

Tôi muốn quay lại khái niệm jagged intelligence (trí tuệ lởm chởm) một chút. Nếu bạn là một founder (nhà sáng lập) ngày nay và đang nghĩ đến việc xây dựng một công ty, bạn đang cố gắng giải quyết một vấn đề mà bạn nghĩ là khả thi (tractable), một lĩnh vực có thể verifiable (xác minh được). Nhưng bạn nhìn xung quanh và nghĩ: "Ôi trời ơi, các phòng thí nghiệm thực sự đã đạt được escape velocity (vận tốc thoát) trong những lĩnh vực rõ ràng nhất như toán học, lập trình và các lĩnh vực khác." Lời khuyên của bạn dành cho các founder trong khán giả là gì?

Tôi nghĩ điều này liên quan đến câu hỏi trước, rằng tôi thực sự tin khả năng verifiability (tính xác minh) khiến mọi thứ trở nên khả thi trong mô hình hiện tại, vì bạn có thể áp dụng một lượng lớn reinforcement learning (RL) vào đó. Một cách để nhìn nhận là điều đó vẫn đúng ngay cả khi các phòng thí nghiệm không tập trung trực tiếp vào nó. Vì vậy, nếu bạn ở trong một môi trường verifiable mà bạn có thể tạo ra các môi trường RL hoặc các ví dụ thì điều đó thực sự giúp bạn có khả năng tự mình fine-tuning (tinh chỉnh) và bạn có thể hưởng lợi từ điều đó. Nhưng đó về cơ bản là công nghệ chỉ hoạt động được. Bạn có thể tác động nếu bạn có một lượng lớn tập dữ liệu đa dạng về môi trường RL, v.v. Bạn có thể sử dụng fine-tuning framework yêu thích của mình và tác động để tạo ra thứ gì đó hoạt động khá tốt. Tôi không biết ví dụ về điều này có thể là gì. Nhưng tôi nghĩ có một số môi trường reinforcement learning rất có giá trị mà mọi người có thể nghĩ đến, mà tôi nghĩ không phải là một phần của... Vâng, tôi không muốn tiết lộ câu trả lời, nhưng có một lĩnh vực mà tôi nghĩ rất... Ồ, được rồi. Xin lỗi, tôi không có ý vape post trên sân khấu, nhưng có một số ví dụ về điều này.

Ngược lại, bạn nghĩ điều gì vẫn chỉ có thể tự động hóa (automatable) từ xa?

Tôi nghĩ rằng cuối cùng hầu hết mọi thứ đều có thể được làm cho verifiable (xác minh được) ở một mức độ nào đó, một số điều dễ hơn những điều khác. Bởi vì ngay cả đối với những thứ như viết lách, bạn có thể hình dung việc có một hội đồng gồm các LLM làm giám khảo và có thể nhận được một cái gì đó hợp lý từ cách tiếp cận này. Vì vậy, vấn đề là cái gì dễ hay khó. Tôi thực sự nghĩ rằng cuối cùng... vâng, tôi nghĩ... [tiếng cười] mọi thứ đều có thể tự động hóa (automatable).

Tuyệt vời. Được rồi. Năm ngoái bạn đã đặt ra thuật ngữ vibe coding và hôm nay chúng ta đang ở trong một thế giới có vẻ nghiêm túc hơn một chút, thiên về agentic engineering (kỹ thuật dựa trên agent). Bạn nghĩ sự khác biệt giữa hai điều này là gì và bạn sẽ gọi điều chúng ta đang ở hiện tại là gì?

Vibe Coding và Agentic Engineering

Vâng. Tôi sẽ nói rằng vibe coding là về việc nâng cao ngưỡng năng lực (raising the floor) cho mọi người trong lĩnh vực phần mềm. Vì vậy, ngưỡng này được nâng lên, mọi người đều có thể vibe code bất cứ thứ gì và điều đó thật tuyệt vời, đáng kinh ngạc. Nhưng sau đó, tôi sẽ nói rằng agentic engineering (kỹ thuật dựa trên agent) là về việc duy trì quality bar (tiêu chuẩn chất lượng) đã tồn tại trước đây trong phần mềm chuyên nghiệp. Bạn không được phép đưa vào các vulnerabilities (lỗ hổng bảo mật) do vibe coding. Bạn vẫn chịu trách nhiệm về phần mềm của mình như trước đây, nhưng bạn có thể làm nhanh hơn không? Và điều bất ngờ là bạn có thể, nhưng làm thế nào để làm điều đó một cách đúng đắn?

Đối với tôi, agentic engineering – tôi gọi nó như vậy vì tôi nghĩ nó giống như một ngành kỹ thuật. Bạn có những agents này, những thực thể "gai góc" (spiky entities). Chúng có phần "dễ hỏng" (fable), hơi "ngẫu nhiên" (stochastic), nhưng chúng cực kỳ mạnh mẽ. Vấn đề là làm thế nào để phối hợp chúng để đi nhanh hơn mà không hy sinh quality bar của bạn, và làm điều đó một cách tốt và đúng đắn – đó là lĩnh vực của agentic engineering.

Vì vậy, tôi xem chúng là khác nhau: một cái có thể là về việc nâng cao ngưỡng năng lực, và cái còn lại là về việc extrapolating (ngoại suy). Và điều tôi thấy là có một high ceiling (giới hạn rất cao) về năng lực của agentic engineer. Mọi người từng nói về 10x engineer (kỹ sư 10x) trước đây, tôi nghĩ điều này giờ đây đã được phóng đại nhiều hơn. 10x không phải là mức tăng tốc mà bạn đạt được. Và tôi nghĩ, đối với tôi, những người rất giỏi trong lĩnh vực này đạt được hiệu suất cao hơn 10x rất nhiều từ góc nhìn của tôi hiện tại.

Mã hóa với AI và Thay đổi trong Tuyển dụng

Tôi thực sự thích cách trình bày đó. Một điều đáng nhớ mà Sam Altman đã nói khi đến AIN năm ngoái là những người thuộc các thế hệ khác nhau sử dụng ChatGPT khác nhau. Nếu bạn ở độ tuổi 30, bạn sử dụng nó như một công cụ thay thế tìm kiếm của Google. Nhưng nếu bạn ở tuổi thiếu niên, ChatGPT là cánh cổng dẫn bạn đến internet. Điều song song ở đây trong lĩnh vực lập trình ngày nay là gì? Nếu chúng ta quan sát hai người lập trình bằng cách sử dụng OpenClaw, Claude Code, Codeex, một người bạn sẽ coi là tầm thường và một người bạn sẽ coi là hoàn toàn AI native. Bạn sẽ mô tả sự khác biệt đó như thế nào?

[hắng giọng] Tôi nghĩ đó chỉ là việc cố gắng tận dụng tối đa các tools (công cụ) có sẵn, sử dụng tất cả các tính năng của chúng, đầu tư vào thiết lập (setup) của riêng bạn. Giống như trước đây, tất cả các kỹ sư đều quen với việc tận dụng tối đa các tools họ sử dụng, dù là Vim hay VS Code, hoặc bây giờ là Claude Code hay Codeex, v.v. Vì vậy, chỉ cần đầu tư vào thiết lập của bạn và sử dụng nhiều tools có sẵn cho bạn. Và tôi nghĩ nó trông giống như vậy.

Tôi nghĩ một suy nghĩ liên quan là nhiều người có thể đang tuyển dụng cho điều này, vì họ muốn thuê những agentic engineers (kỹ sư dựa trên agent) mạnh mẽ. Tôi thấy rằng hầu hết mọi người vẫn chưa refactored (tái cấu trúc) quy trình tuyển dụng của họ cho năng lực agentic engineer. Ví dụ, nếu bạn đưa ra các câu đố để giải, thì đây vẫn là old paradigm (mô hình cũ). Tôi sẽ nói rằng việc tuyển dụng phải giống như: hãy đưa cho tôi một dự án thực sự lớn và xem ai đó thực hiện dự án lớn đó, chẳng hạn như viết một bản sao Twitter (Twitter clone) cho các agents, sau đó làm cho nó thực sự tốt, thực sự an toàn, và sau đó có một số agents mô phỏng một số hoạt động trên Twitter này. Và sau đó tôi sẽ sử dụng 10 Codeex 5.4x cho X-high để cố gắng phá vỡ trang web bạn đã triển khai, và chúng sẽ cố gắng phá vỡ nó và chúng không thể phá vỡ nó. Vì vậy, có lẽ nó trông giống như vậy, phải không? Và vâng, quan sát mọi người trong cài đặt đó và xây dựng các dự án lớn hơn và sử dụng các tooling (bộ công cụ) có lẽ là điều tôi sẽ xem xét phần lớn.

Kỹ năng Con người trong Kỷ nguyên Agent

Và khi các agents làm được nhiều việc hơn, bạn nghĩ kỹ năng con người nào trở nên có giá trị hơn, chứ không phải ít đi?

Vâng, đó là một câu hỏi hay. Tôi nghĩ, hiện tại, câu trả lời là các agents giống như những "thực thể thực tập sinh" (intern entities). Điều đáng chú ý là bạn về cơ bản vẫn phải chịu trách nhiệm về aesthetics (tính thẩm mỹ), judgment (phán đoán), taste (gu thẩm mỹ) và một chút oversight (giám sát). Có lẽ một trong những ví dụ yêu thích của tôi về sự kỳ lạ của các agents là đối với menu genen, bạn đăng ký bằng tài khoản Google (Google account), nhưng bạn mua tín dụng bằng tài khoản Stripe (Stripe account). Cả hai đều có email addresses (địa chỉ email). Agent của tôi thực sự đã cố gắng, khi bạn mua tín dụng, nó đã gán tín dụng đó bằng địa chỉ email từ Stripe cho địa chỉ email của Google. Kiểu như không có persistent user ID (ID người dùng cố định), mà nó cố gắng khớp các địa chỉ email, nhưng bạn có thể sử dụng các địa chỉ email khác nhau cho Stripe và Google của mình và về cơ bản nó sẽ không liên kết các khoản tiền.

Đây là loại sai lầm mà các agents vẫn mắc phải, kiểu như tại sao bạn lại sử dụng địa chỉ email để cố gắng cross-correlate the funds (đối chiếu chéo các khoản tiền)? Chúng có thể tùy ý. Bạn có thể sử dụng các email khác nhau, v.v. Đây là một điều kỳ lạ khi làm. Vì vậy, tôi nghĩ con người phải chịu trách nhiệm về spec (đặc tả), plan (kế hoạch) này. Và tôi thực sự không thích plan mode. Ý tôi là rõ ràng nó rất hữu ích, nhưng tôi nghĩ có điều gì đó tổng quát hơn ở đây, nơi bạn phải làm việc với agent của mình để thiết kế một spec rất detailed (chi tiết), và có lẽ đó là các docs (tài liệu), sau đó để các agents viết chúng và bạn chịu trách nhiệm oversight (giám sát) và các top-level categories (danh mục cấp cao nhất), nhưng các agents đang làm rất nhiều công việc "dưới mui xe" (under the hood). Và tôi nghĩ bạn không quan tâm đến một số chi tiết. Ví dụ, với arrays (mảng) hoặc tensors (ten-xơ) trong neural networks (mạng nơ-ron).

Chi Tiết API và Vai Trò Của Con Người

Có rất nhiều chi tiết giữa PyTorch và NumPy, cũng như các thư viện khác như pandas, liên quan đến các chi tiết API nhỏ. Tôi đã quên mất sự khác biệt giữa keep dims và keep dim, hoặc liệu đó là dim hay axis, hay reshape, permute, transpose. Tôi không còn nhớ những thứ này nữa, đúng không? Bởi vì bạn không cần phải nhớ. Đây là loại chi tiết do các intern xử lý vì họ có khả năng ghi nhớ rất tốt.

Tuy nhiên, bạn vẫn cần phải biết, ví dụ, có một tensor cơ bản, có một view cơ bản, và sau đó bạn có thể thao tác với view của cùng một vùng lưu trữ hoặc bạn có thể có các vùng lưu trữ khác nhau, điều này sẽ kém hiệu quả hơn. Vì vậy, bạn vẫn phải hiểu những gì những thứ này đang làm và một số nguyên tắc cơ bản, để bạn không sao chép bộ nhớ một cách không cần thiết. Nhưng các chi tiết của API hiện đã được giao phó, vì vậy bạn phụ trách về "gu" thẩm mỹ, kỹ thuật, thiết kế, và đảm bảo rằng nó có ý nghĩa, rằng bạn đang yêu cầu những điều đúng đắn, và rằng bạn đang nói rằng 'những user ID này phải là duy nhất mà chúng ta sẽ gắn mọi thứ vào'. Và như vậy, bạn đang thực hiện một số công việc thiết kế và phát triển, còn các kỹ sư thì điền vào chỗ trống. Đó là tình hình hiện tại, và tôi nghĩ mọi người đều đang thấy điều đó.

Chất Lượng Mã Nguồn và Reinforcement Learning

Bạn có nghĩ rằng "gu" thẩm mỹ và óc phán đoán này sẽ ít quan trọng hơn theo thời gian, hay giới hạn sẽ liên tục tăng lên?

Đó là một câu hỏi hay. Tôi hy vọng rằng nó sẽ được cải thiện. Tôi nghĩ lý do có lẽ nó chưa được cải thiện hiện nay là, một lần nữa, nó không phải là một phần của RL (reinforcement learning). Có lẽ không có chi phí hoặc phần thưởng nào về mặt thẩm mỹ, hoặc nó chưa đủ tốt, hay đại loại vậy. Tôi nghĩ rằng khi bạn thực sự nhìn vào mã nguồn, đôi khi tôi hơi 'đau tim' một chút, vì không phải lúc nào nó cũng là mã nguồn siêu tuyệt vời, và nó rất bloaty (phình to), có rất nhiều việc sao chép-dán, và có những abstraction (trừu tượng hóa) vụng về, dễ vỡ. Nó hoạt động, nhưng nhìn chung thì nó thực sự tệ. Và tôi thực sự hy vọng rằng điều này có thể cải thiện trong các model tương lai.

Một ví dụ điển hình khác là dự án micro GPT này, nơi tôi đã cố gắng đơn giản hóa việc huấn luyện LLM hết mức có thể. Các model ghét điều này. Chúng không thể làm được. Tôi đã cố gắng – tôi cứ cố gắng prompt một LLM để đơn giản hóa hơn nữa, đơn giản hóa hơn nữa, nhưng nó không thể. Bạn có cảm giác như mình đang ở bên ngoài các mạch RL. Bạn cảm thấy như bạn đang vất vả lắm mới hoàn thành được việc gì đó. Nó không diễn ra với tốc độ ánh sáng. Vì vậy, tôi nghĩ rằng con người vẫn phụ trách điều này. Nhưng tôi cũng nghĩ rằng không có gì cơ bản ngăn cản điều đó; chỉ là các phòng thí nghiệm chưa thực hiện nó mà thôi.

Các Dạng Trí Tuệ Không Đồng Đều: Động Vật và Hồn Ma

Vâng.

Tôi muốn quay lại ý tưởng về các dạng trí tuệ không đồng đều. Bạn đã viết một chút về điều này trong một bài viết rất kích thích tư duy về "động vật đối lập với hồn ma". Và ý tưởng là chúng ta không xây dựng động vật; chúng ta đang triệu hồi hồn ma. Và đây là những dạng trí tuệ không đồng đều được hình thành bởi dữ liệu và các reward function (hàm thưởng), chứ không phải bởi intrinsic motivation (động lực nội tại), niềm vui, sự tò mò, hay sự trao quyền – những thứ có được thông qua evolution (tiến hóa). Tại sao cách nhìn nhận đó lại quan trọng, và nó thực sự thay đổi điều gì về cách bạn xây dựng, triển khai, đánh giá, hoặc thậm chí tin tưởng chúng?

Vâng, tôi nghĩ lý do tôi viết về điều này là vì tôi đang cố gắng hiểu rõ bản chất của những thứ này, đúng không? Bởi vì nếu bạn có một model tốt về bản chất của chúng, thì bạn sẽ có năng lực hơn trong việc sử dụng chúng. Và tôi nghĩ rằng, tôi không biết liệu nó có – tôi không chắc liệu nó có thực sự có sức mạnh thực sự hay không. [cười] Tôi nghĩ nó hơi mang tính philosophizing (triết lý hóa) một chút.

Nhưng tôi nghĩ rằng, nó chỉ đơn giản là việc chấp nhận sự thật rằng những thứ này không phải là trí tuệ động vật. Giống như nếu bạn la mắng chúng, chúng sẽ không hoạt động tốt hơn hay tệ hơn, hoặc nó không có bất kỳ tác động nào. Và tất cả chỉ là những mạch statistical simulation (mô phỏng thống kê) này, nơi nền tảng là pre-training (huấn luyện trước) – như thống kê – và sau đó có RL (reinforcement learning) được gắn thêm vào. Vì vậy, nó giống như làm tăng dispendages (sự mất cân bằng) và, có lẽ nó chỉ là một mindset (tâm thế) về điều tôi đang đối mặt, hoặc điều gì có khả năng hoạt động hay không, hoặc cách sửa đổi nó. Nhưng tôi thực sự không biết liệu tôi có thể đưa ra 'đây là năm kết quả rõ ràng về cách làm cho hệ thống của bạn tốt hơn' hay không. Nó giống như việc bạn phải cảnh giác với nó và, ừm...

Tương Lai của Môi Trường Hướng Agent

...tìm hiểu theo thời gian.

Đó là nơi nó bắt đầu. Được rồi, vậy bạn đang làm việc rất sâu với các agent không chỉ trò chuyện. Chúng có permissions (quyền hạn) thực sự. Chúng có local context (ngữ cảnh cục bộ). Chúng thực sự thực hiện action (hành động) thay mặt bạn. Thế giới sẽ trông như thế nào khi tất cả chúng ta bắt đầu sống trong thế giới đó?

Vâng, tôi nghĩ rất nhiều người ở đây có lẽ đang hào hứng về việc agent bản địa, agentic environment (môi trường hướng agent) này trông như thế nào, và mọi thứ đều phải được viết lại. Mọi thứ vẫn cơ bản được viết cho con người và phải được di chuyển xung quanh. Hầu hết thời gian khi tôi sử dụng các framework hoặc library khác nhau, chúng vẫn có docs (tài liệu) cơ bản được viết cho con người. Đây là pet peeve (điều khó chịu) yêu thích của tôi. Tại sao mọi người vẫn bảo tôi phải làm gì? Tôi không muốn làm gì cả. Cái gì tôi nên sao chép-dán vào agent của tôi? [cười] Vì vậy, cứ mỗi khi tôi được bảo, bạn biết đấy, 'hãy truy cập URL này' hay đại loại vậy, tôi lại 'à!' [cười] [khịt mũi].

Vì vậy, mọi người, tôi nghĩ, đều hào hứng về việc làm thế nào chúng ta phân tách các workload (khối lượng công việc) cần thực hiện thành các sensor (cảm biến) cơ bản trên thế giới, các actuator (cơ cấu chấp hành) trên thế giới. Làm thế nào để chúng ta biến nó thành agent-native? Về cơ bản, hãy mô tả nó cho các agent trước. Và sau đó có rất nhiều automation (tự động hóa) xung quanh, ừm, vâng, xung quanh các data structure (cấu trúc dữ liệu) rất dễ đọc đối với các LLM. Vì vậy, tôi nghĩ, vâng, tôi hy vọng sẽ có rất nhiều infrastructure (cơ sở hạ tầng) ưu tiên agent ngoài kia, và bạn biết đấy, đối với Menuguan — nổi tiếng là khi tôi viết, tôi không chắc nổi tiếng đến mức nào nhưng khi tôi viết bài blog về Menuguan [cười] — rất nhiều công việc, rất nhiều rắc rối, thậm chí không phải là viết mã cho Menugen; mà là triển khai nó trên Vercel vì tôi phải làm việc với tất cả các service khác nhau, và tôi phải kết nối chúng, và tôi phải vào cài đặt và menu của chúng, và bạn biết đấy, cấu hình DNS của tôi, và nó thật khó chịu. Và đó là một ví dụ điển hình về việc tôi hy vọng rằng Menugen — rằng tôi có thể đưa một prompt cho một LLM để xây dựng Menugen, và sau đó tôi không cần phải chạm vào bất cứ thứ gì, và nó được triển khai theo cùng một cách trên internet. Tôi nghĩ đó sẽ là một bài kiểm tra tốt để xem liệu nhiều cơ sở hạ tầng của chúng ta có đang ngày càng trở nên agent-native hay không. Và cuối cùng, tôi sẽ nói, vâng, tôi thực sự nghĩ rằng chúng ta đang hướng tới một thế giới mà có agent representation (đại diện agent) cho con người và cho các tổ chức, và, ừm, bạn biết đấy, agent của tôi sẽ nói chuyện với agent của bạn để tìm hiểu một số chi tiết về các cuộc họp của chúng ta hoặc những thứ tương tự. [cười] Vì vậy, tôi thực sự nghĩ rằng đó là đại khái nơi mọi thứ đang diễn ra, nhưng, ừm, vâng, tôi nghĩ mọi người ở đây đều hào hứng về điều đó.

Giáo Dục Trong Kỷ Nguyên AI: Tư Duy và Hiểu Biết

Tôi thực sự thích sự tương đồng trực quan về sensors (cảm biến) và actuators (cơ cấu chấp hành). Tôi thực sự chưa từng nghĩ đến điều đó. Nó siêu thú vị, đúng không?

Được rồi, tôi nghĩ chúng ta phải kết thúc bằng một câu hỏi về giáo dục. Bởi vì bạn có lẽ là một trong những người giỏi nhất trên thế giới trong việc biến các khái niệm kỹ thuật phức tạp thành đơn giản và suy nghĩ sâu sắc về cách chúng ta thiết kế giáo dục xung quanh nó. Điều gì vẫn còn đáng để học hỏi sâu sắc khi trí tuệ trở nên rẻ khi chúng ta bước vào kỷ nguyên AI tiếp theo?

Vâng. Gần đây có một tweet đã làm tôi kinh ngạc, và tôi cứ nghĩ về nó gần như mỗi ngày. Nó đại ý rằng, 'Bạn có thể outsource (thuê ngoài) việc tư duy của mình, nhưng bạn không thể outsource (thuê ngoài) sự hiểu biết của mình.'

Tôi nghĩ điều đó được diễn đạt rất hay.

Vâng, bởi vì tôi vẫn là một phần của hệ thống, và tôi vẫn – tôi vẫn phải bằng cách nào đó, thông tin vẫn phải đi vào não tôi, và tôi cảm thấy mình đang trở thành một bottleneck (nút thắt cổ chai) chỉ vì phải biết chúng ta đang cố gắng xây dựng cái gì, tại sao nó đáng để làm, làm thế nào để tôi chỉ đạo – bạn biết đấy, làm thế nào để tôi chỉ đạo các agent của mình, v.v. Vì vậy, tôi vẫn nghĩ rằng cuối cùng thì phải có thứ gì đó chỉ đạo việc tư duy và xử lý, v.v., và điều đó vẫn bị hạn chế một cách cơ bản bởi sự hiểu biết. Và đây cũng là một lý do tôi rất hào hứng về tất cả các LLM knowledge base (cơ sở kiến thức LLM) bởi vì tôi cảm thấy đó là một cách để tôi xử lý thông tin, và bất cứ khi nào tôi thấy một projection (phép chiếu) khác về thông tin, tôi luôn cảm thấy mình có được insight (hiểu biết sâu sắc). Vì vậy, nó thực sự chỉ là rất nhiều prompt để tôi thực hiện synthetic data generation (tạo dữ liệu tổng hợp) trên một số data cố định. Vì vậy, tôi thực sự thích, bất cứ khi nào tôi đọc một bài article (bài báo), tôi có wiki của riêng mình được xây dựng từ những bài báo này, và tôi thích đặt câu hỏi về mọi thứ, hoặc, ừm, và tôi nghĩ rằng cuối cùng thì đây là những tool (công cụ) để nâng cao sự hiểu biết theo một cách nhất định, và đây vẫn là một loại bottleneck vì sau đó bạn không thể chỉ đạo – bạn không thể là một người chỉ đạo giỏi nếu bạn vẫn – bởi vì các LLM chắc chắn không xuất sắc trong việc hiểu biết, bạn vẫn là người duy nhất phụ trách điều đó. Vì vậy, vâng, tôi nghĩ rằng các tool phục vụ mục đích đó, tôi nghĩ, là vô cùng thú vị và hấp dẫn.

Tôi rất hào hứng được quay lại đây sau vài năm nữa và xem liệu chúng ta đã hoàn toàn automated (tự động hóa) ra khỏi vòng lặp hay chưa, và liệu chúng có thực sự tự lo liệu việc hiểu biết hay không. Cảm ơn Andre rất nhiều vì đã tham gia cùng chúng tôi. [tiếng vỗ tay]