BTC
$96,000
5.73%
ETH
$3,521.91
3.97%
HTX
$0.{5}2273
5.23%
SOL
$198.17
3.05%
BNB
$710
3.05%
lang
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
Trang chủ
AI AI
Tin nhanh
Bài viết
Sự kiện
BlockBeats Pro
Thêm
Thông tin tài chính
Chuyên đề
Hệ sinh thái chuỗi khối
Mục nhập
Podcast
Data
OPRR
Partnered With:

a16z: Tương lai của AI thị giác không phải là hình ảnh, mà là mã nguồn.

Đọc bài viết này mất 31 phút
Từ việc tạo ra pixel, đến việc tạo ra mã nguồn có thể chỉnh sửa
Tiêu đề gốc: The Next Frontier of Visual AI Is Code
Tác giả gốc: @stuffyokodraws, a16z
Biên dịch: Peggy


Lời biên tập: Trong vài năm qua, cuộc cạnh tranh về AI thị giác hầu như xoay quanh một câu hỏi: ai tạo ra hình ảnh chân thực hơn, ai tạo ra video mượt mà hơn. Mô hình khuếch tán biến các prompt văn bản thành hình ảnh, video và cảnh thực tế, khiến giới ngoài quen với việc đánh giá năng lực của mô hình dựa trên "giống hay không" và "đẹp hay không".


Tuy nhiên, bài viết từ a16z này chỉ ra rằng giai đoạn tiếp theo của AI thị giác có thể không chỉ là tạo ra các pixel đẹp hơn, mà là tạo ra các code artifact (tệp có cấu trúc có thể tiếp tục chỉnh sửa, kiểm thử và bàn giao) đằng sau các pixel.


Sự khác biệt này nghe có vẻ kỹ thuật, nhưng thực tế quyết định liệu AI có thể thực sự đi vào quy trình sản xuất hay không. Nhà thiết kế không chỉ cần một ảnh chụp UI, mà cần HTML/CSS, component React, layer và tệp có thể bàn giao; nhà làm hoạt hình không chỉ cần một video, mà cần keyframe, đường cong thời gian và tham số chuyển động có thể chỉnh sửa; nghệ sĩ 3D không chỉ cần một ảnh render, mà cần cấu trúc hình học, vật liệu, ánh sáng, camera và phân cấp cảnh.


Do đó, bài viết chia tạo hình ảnh thành hai hướng: tạo pixel gốc (tạo trực tiếp hình ảnh hoặc video) phù hợp với tính chân thực, không khí và khám phá; tạo code gốc (tạo SVG, Lottie, script Blender, cảnh USD, v.v.) phù hợp hơn với chỉnh sửa, lặp và sản xuất. Điều thực sự quan trọng ở hướng sau là nó có thể hình thành vòng lặp "code → render → kiểm tra → sửa đổi". Mô hình không còn chỉ lấy mẫu lại nhiều lần, mà đang gỡ lỗi một chương trình thị giác có thể xác minh.


Đây cũng là lý do tác giả đặc biệt lạc quan về 3D. Bởi vì một ảnh render của chiếc ghế không phải là chiếc ghế, chỉ là hình ảnh của chiếc ghế. Tài sản thực sự có thể sử dụng trong game, trình mô phỏng hoặc công cụ 3D phải có cấu trúc hình học ổn định, phân cấp bộ phận, vật liệu và ràng buộc chức năng: cửa phải mở được, ngăn kéo phải trượt được, bánh xe phải quay được. Nói cách khác, giá trị của AI thị giác trong tương lai không nằm ở "trông giống", mà ở "có thể tiếp tục sử dụng hay không".


Bài viết này cung cấp một khung đánh giá tốt: làn sóng đầu tiên của AI thị giác giải quyết vấn đề tạo ra, làn sóng tiếp theo sẽ giải quyết vấn đề sản xuất. Khi AI thị giác chuyển từ đầu ra cuối cùng sang mã nguồn, thứ thực sự bị thay đổi không chỉ là công cụ thiết kế, mà là toàn bộ chuỗi sản xuất nội dung thị giác.


Dưới đây là nội dung gốc:


Trong vài năm qua, AI thị giác chủ yếu được đánh giá dựa trên "pixel". Hình ảnh hoặc video cuối cùng càng đẹp, mô hình dường như càng mạnh.


Điều này không có gì đáng ngạc nhiên. Các mô hình khuếch tán (diffusion models) đầu tiên biến prompt văn bản thành hình ảnh đẹp, sau đó mở rộng sang video, và cuối cùng là những thế giới ngày càng chân thực. Mọi người tự nhiên so sánh nó với Photoshop hoặc máy ảnh.


Nhưng đối với nhiều tác vụ liên quan đến thị giác, như thiết kế đồ họa, thiết kế UI hoặc mô hình 3D, thứ người dùng thực sự cần không chỉ là pixel hiển thị cuối cùng. Họ cần một sản phẩm có thể liên tục được cải tiến dựa trên phản hồi và ý tưởng mới. Nhà thiết kế không chỉ cần một bản mockup (bản phác thảo thiết kế), mà còn cần layer, component và file bàn giao; nhà làm hoạt hình không chỉ cần một video, mà còn cần đường cong thời gian, keyframe và quỹ đạo chuyển động có thể chỉnh sửa; nghệ sĩ 3D không chỉ cần một bản render, mà còn cần cấu trúc hình học, chất liệu, ánh sáng, camera và cấu trúc scene.


Ngày nay, những công cụ AI thị giác thú vị nhất không còn cố gắng tạo ra đầu ra cuối cùng trực tiếp nữa. Chúng bắt đầu tạo ra mã nguồn đằng sau đầu ra cuối cùng. Sự thay đổi này đang giải phóng khả năng chỉnh sửa, khả năng lặp và vòng phản hồi – những thứ mà các mô hình pixel-native khó có thể sánh kịp.


Hai công nghệ tạo sinh thị giác


Chúng ta có thể hiểu việc tạo sinh thị giác theo hai cách chính.


Cách thứ nhất là tạo sinh pixel-native. Các hệ thống này thường tạo trực tiếp hình ảnh hoặc video, thường được thực hiện trong không gian tiềm ẩn (latent space). Chúng giỏi về kết cấu, bầu không khí, ánh sáng và tính chân thực. Nếu mục tiêu là tạo ra một cảnh quay điện ảnh, một bộ moodboard (bảng tâm trạng) đẹp, hoặc một hình ảnh siêu thực, mô hình khuếch tán vẫn là phương pháp chủ đạo.


Cách thứ hai là tạo sinh code-native. Các hệ thống này tạo ra một dạng biểu diễn, sau đó được thực thi hoặc render bởi một engine khác. Mô hình không tạo trực tiếp pixel cuối cùng, mà tạo ra một chương trình có thể tạo ra pixel.


Chương trình này có thể là một file SVG, một bố cục HTML/CSS, một component React, một file JSON Lottie, một script Blender, một scene graph USD, một shader (bộ tạo bóng), hoặc một scene engine game. Đầu ra thị giác cuối cùng vẫn là pixel, nhưng "nguồn gốc thực sự" là một biểu diễn có cấu trúc.


Sự khác biệt này rất quan trọng, vì quy trình sản xuất rất quan tâm đến "điều gì xảy ra sau khi tạo ra". Một hình ảnh được tạo ra có thể được sử dụng như đầu ra, nhưng một chương trình thị giác được tạo ra có thể được sử dụng như một sản phẩm: nó có thể được chỉnh sửa, tái sử dụng, cải tiến, quản lý phiên bản; nó có thể được tích hợp vào stack công nghệ phần mềm và được xác thực dựa trên các ràng buộc; nó có thể được render nhiều lần trong các điều kiện khác nhau, và được chuyển giao giữa các nhà thiết kế, kỹ sư và Agent.


Tôi cho rằng, một sự chuyển đổi quan trọng đã và đang diễn ra: đối với một số vấn đề về thị giác, chúng ta sẽ học cách định nghĩa lại các tác vụ sinh thị giác thành các tác vụ mã hóa, và bằng cách giải quyết một bài toán mã hóa có ranh giới rõ ràng, có thể kiểm chứng, chúng ta sẽ đạt được những cải tiến cực kỳ hiệu quả.


Mã là một phương tiện tốt để giải quyết các vấn đề thị giác


Cách đơn giản nhất để hiểu giá trị của việc sinh mã thị giác là nhìn vào những gì xảy ra sau bản nháp đầu tiên.


Giả sử một mô hình tạo ra một logo. Nếu đầu ra là một hình ảnh raster, và một trong các đường cong bị sai, người dùng phải che, vẽ lại cục bộ, tạo lại, hoặc vẽ lại bằng tay. Nhưng nếu đầu ra là SVG, người dùng có thể trực tiếp chỉnh sửa đường dẫn, hình cơ bản, gradient, nét vẽ hoặc các thành phần văn bản. Đây đã là cách các nhà thiết kế tạo logo trên Quiver.



Trong lĩnh vực thiết kế UI, nếu đầu ra là một ảnh chụp màn hình, nó chỉ mang tính tham khảo cảm hứng. Nhưng nếu đầu ra là HTML/CSS hoặc React, nhà thiết kế có thể kiểm tra DOM, thay thế các thành phần thực tế, kiểm tra trạng thái phản hồi, kiểm tra khả năng tiếp cận, và tích hợp nó vào ứng dụng.



Đây cũng là lý do tại sao sinh mã thị giác đặc biệt phù hợp với test-time compute (tính toán tại thời điểm kiểm tra). Trong sinh pixel gốc, việc tăng cường tính toán suy luận thường có nghĩa là lấy mẫu nhiều đầu ra hơn: tạo 20 hình, chọn hình đẹp nhất, có thể thử lại một lần nữa. Điều này tất nhiên có ích, nhưng mỗi lần thử về cơ bản giống như tung xúc xắc lại. Mô hình có thể phản hồi lại, nhưng phản hồi này thường mang tính tổng thể và không đủ chính xác.


Về mặt kỹ thuật, các mô hình khuếch tán cũng có thể hưởng lợi từ test-time compute. Ví dụ, Inference-time Scaling of Diffusion Models through Classical Search cho thấy rằng việc tìm kiếm trong giai đoạn suy luận có thể cải thiện hiệu suất của mô hình khuếch tán trong lập kế hoạch, học tăng cường và sinh hình ảnh. Nhưng cơ chế vòng lặp ở đây khác. Trong mô hình khuếch tán, hệ thống thường tìm kiếm giữa các quỹ đạo tiềm năng hoặc các mẫu đầu ra cuối cùng. Tín hiệu phần thưởng có thể cho mô hình biết đầu ra nào tốt hơn đầu ra khác, nhưng nó không thể ánh xạ phản hồi một cách rõ ràng đến một sửa đổi cụ thể ở cấp độ mã nguồn.


Sinh mã gốc tạo ra một vòng lặp chính xác hơn: mã → kết xuất → kiểm tra → sửa đổi.


Mô hình tạo ra sản phẩm, kết xuất nó, quan sát vấn đề ở đâu, sau đó sửa chữa tệp nguồn. Nếu khoảng cách không đúng, sửa CSS; nếu đường cong logo bị lệch, chỉnh sửa đường dẫn SVG; nếu nhịp điệu hoạt ảnh quá chậm, điều chỉnh tham số thời gian. Điểm mấu chốt là, mỗi lần lặp đều cải thiện sản phẩm cơ bản, chứ không chỉ đầu ra đã kết xuất. Đây cũng là lý do tại sao sinh mã thị giác tự nhiên có thể hưởng lợi từ việc tạo nhiều token hơn và test-time compute. Mô hình đang gỡ lỗi chương trình thị giác trong một môi trường khép kín, có thể kiểm chứng, chứ không chỉ đơn thuần là lấy mẫu thêm nhiều hình ảnh.


Ngăn xếp công nghệ tạo hình ảnh lấy mã làm cốt lõi


Đằng sau các ví dụ trên là một ngăn xếp công nghệ như sau: mô hình mã hóa + biểu diễn ký hiệu + trình kết xuất hoặc engine.



Mô hình mã hóa là tác giả và người chỉnh sửa của sản phẩm. Nó chịu trách nhiệm viết HTML, SVG, Lottie JSON, script Blender, cảnh USD hoặc chương trình tài sản 3D tùy chỉnh.


Biểu diễn ký hiệu là nguồn sự thật. Đây chính là lý do sản phẩm có khả năng chỉnh sửa. Một UI có các nút DOM, quy tắc bố cục và thành phần; một hoạt ảnh Lottie có các lớp, hình dạng vector, đường cong thời gian, keyframe và tham số chuyển động; một tài sản 3D có cấu trúc hình học, vật liệu, khớp nối, ràng buộc và quan hệ phân cấp.


Trình kết xuất hoặc engine chuyển đổi các cấu trúc này thành pixel. Trình duyệt kết xuất HTML/CSS, trình kết xuất SVG kết xuất đồ họa vector, trình phát Lottie kết xuất hoạt ảnh, Blender hoặc engine game kết xuất cảnh 3D, và trình mô phỏng xác minh xem một tài sản có khớp nối có thực sự di chuyển hoặc tương tác được hay không.


OmniLottie là một ví dụ điển hình cho thấy tầm quan trọng của biểu diễn ký hiệu. Lottie là một định dạng hoạt ảnh nhẹ dựa trên JSON, không biểu diễn hoạt ảnh dưới dạng một video phẳng mà sử dụng các hình dạng vector, lớp, keyframe và tham số thời gian có thể chỉnh sửa để thể hiện chuyển động. OmniLottie đề xuất chuyển đổi JSON Lottie gốc thành một chuỗi lệnh phù hợp hơn cho mô hình hiểu, giúp mô hình có thể tạo và chỉnh sửa hoạt ảnh Lottie một cách đáng tin cậy hơn. Trọng tâm của bài báo này không phải là xây dựng một vòng lặp Agent hoàn chỉnh, mà là làm cho Lottie phù hợp hơn với việc tạo mô hình: nó chuyển đổi JSON Lottie gốc thành một tập hợp các lệnh và chuỗi tham số nhỏ gọn. Hành động này rất quan trọng, vì bản thân Lottie đã là một định dạng hoạt ảnh có thể chỉnh sửa. Một khi chuyển động được biểu diễn dưới dạng các tham số hình dạng, lớp, thời gian và hoạt ảnh, phản hồi có thể được ánh xạ tới các sửa đổi ở cấp độ tệp nguồn. Nếu vật thể di chuyển quá chậm, hãy điều chỉnh thời gian; nếu đường dẫn sai, hãy sửa vector; nếu biến dạng lệch, hãy cập nhật chuỗi hình dạng.



Ngăn xếp công nghệ này tương ứng với vòng lặp test-time compute mà Agent mã hóa có thể sử dụng để cải thiện chất lượng đầu ra: trong mỗi vòng lặp "mã → kết xuất → kiểm tra → sửa đổi", mô hình không tạo ra một mẫu mới, mà đang sử dụng phản hồi từ trình kết xuất để cải thiện sản phẩm cơ bản. Nó có thể sửa đổi quy tắc CSS, điều chỉnh đường dẫn SVG, sửa thời gian hoạt ảnh hoặc cập nhật ràng buộc 3D, sau đó kết xuất lại và tiếp tục cải tiến.


Điều này giúp vòng lặp có khả năng hội tụ. Trong quá trình tạo pixel gốc, mỗi lần thử lại thường tạo ra một đầu ra mới. Trong quá trình tạo mã gốc, mỗi lần thử lại có thể cải thiện chính tác phẩm nguồn. Mô hình không chỉ lấy mẫu thêm nhiều hình ảnh hoặc video, mà đang gỡ lỗi chương trình thị giác trong một môi trường khép kín, có thể kết xuất.


Bản đồ thị trường: Hình thành điểm đột phá xung quanh runtime


Thị trường tạo mã thị giác đang được tổ chức xung quanh "runtime", nơi tác phẩm được kết xuất hoặc thực thi. Trong tạo mã thị giác gốc, mô hình tạo ra một tác phẩm ký hiệu, và tác phẩm này được thực thi trong một môi trường nào đó: trình duyệt, trình kết xuất SVG, trình phát Lottie, Blender, công cụ trò chơi hoặc trình mô phỏng.


Mỗi runtime hình thành một điểm đột phá khác nhau, vì mỗi runtime có biểu diễn nguồn, vòng phản hồi và quy trình sản xuất riêng.



Ứng dụng rõ ràng nhất hiện nay là trong lĩnh vực thiết kế 2D, đặc biệt là thiết kế UI và thiết kế đồ họa. Nhưng tạo mã thị giác không chỉ giới hạn trong các công cụ thiết kế. Miễn là đằng sau tác phẩm thị giác tồn tại một biểu diễn cơ bản có thể được tạo, kết xuất, kiểm tra và tối ưu hóa, nó có thể xuất hiện.


Tại sao 3D là biên giới quan trọng tiếp theo


Mặc dù thiết kế sản phẩm và thiết kế 2D là các trường hợp sử dụng trực quan nhất hiện nay, nhưng tác phẩm 3D có thể hưởng lợi nhiều nhất từ cách tiếp cận "định nghĩa lại vấn đề nhất quán thành vấn đề mã hóa".


Một thiết kế 2D đôi khi chỉ cần trông đúng là đã hữu ích. Nhưng tài sản 3D thì không. Một bản kết xuất của chiếc ghế không phải là chiếc ghế, nó chỉ là hình ảnh của chiếc ghế. Để tài sản này thực sự có thể sử dụng trong trò chơi, trình mô phỏng hoặc công cụ chỉnh sửa 3D, nó phải có biểu diễn 3D cơ bản nhất quán, bao gồm cấu trúc hình học, vật liệu, phân cấp bộ phận và ngữ cảnh cảnh chính xác.


Đây là lý do tại sao 3D phù hợp tự nhiên với tạo mã thị giác. Giá trị của nó không chỉ là tạo ra thứ trông giống 3D từ một góc nhìn, mà là tạo ra một cấu trúc 3D nhất quán có thể đứng vững dưới các góc nhìn, chỉnh sửa và tương tác khác nhau. Điều này đòi hỏi một vòng lặp lặp: đề xuất đối tượng, kết xuất nó, kiểm tra xem cấu trúc hình học và bộ phận có hợp lý không, sau đó sửa đổi biểu diễn cơ bản. Nhưng vòng lặp này chỉ hiệu quả khi Agent có công cụ và ngữ cảnh phù hợp. Chỉ chạy Blender liên tục cho đến khi thứ gì đó trông đẹp hơn là không đủ. Agent cần có khả năng chuyển đổi góc nhìn camera, truy vấn trạng thái cảnh, cô lập đối tượng, so sánh với mục tiêu, ghi nhớ các lần thử trước đó và chuyển đổi khác biệt thị giác thành các sửa đổi ở cấp độ tệp nguồn. Chính những khả năng này mang lại cơ hội cho test-time compute hội tụ.


Đối với nhiều tài sản, tính nhất quán về mặt hình ảnh chỉ là yêu cầu cơ bản. Đối tượng còn cần có ngữ nghĩa bộ phận chính xác và các ràng buộc chức năng: cửa phải mở được, bản lề phải xoay được, ngăn kéo phải trượt được, bánh xe phải quay được. Nói cách khác, đầu ra không chỉ đơn thuần là một hình dạng trông hợp lý, mà còn phải hoạt động giống như thứ mà nó đại diện.


Đây chính là điểm nổi bật của các dự án như VIGA và Articraft3D. Chúng tôi dự đoán trong năm nay sẽ còn xuất hiện nhiều công trình liên quan hơn nữa, bao gồm cả các dự án thương mại và mã nguồn mở. VIGA sử dụng Blender làm môi trường kết xuất và phản hồi, biến quá trình tái tạo hình ảnh thành một vòng lặp "mã - kết xuất - kiểm tra"; nhưng VIGA không đơn giản chỉ để lộ Blender thô cho vòng lặp Agent. Nó cung cấp cho Agent các công cụ ngữ nghĩa để quan sát và chỉnh sửa, đồng thời lưu giữ ký ức về các lần thử trước đó, giúp Agent có thể kiểm tra đối tượng từ góc nhìn tốt hơn, chẩn đoán vấn đề và thực hiện các chỉnh sửa có mục tiêu. Articraft3D thì xử lý cấu trúc tài sản một cách trực tiếp hơn: nó định nghĩa việc tạo ra các đối tượng 3D có khớp nối như việc viết các chương trình, các chương trình này chịu trách nhiệm xác định bộ phận, hình học, khớp nối và kiểm thử.



Tác động trong tương lai và các vấn đề chưa được giải quyết


Nếu việc tạo mã hình ảnh thực sự thành công, sản phẩm chiến thắng cuối cùng sẽ không chỉ tạo ra đầu ra đẹp hơn. Chúng sẽ nắm vững toàn bộ vòng lặp: tạo ra sản phẩm, kết xuất sản phẩm, kiểm tra xem có vấn đề gì và sửa đổi tệp nguồn.


Điều này kéo theo một số tác động.


Thứ nhất, trình kết xuất sẽ trở thành môi trường phản hồi. Trình duyệt, trình kết xuất SVG, trình phát Lottie, Blender, công cụ trò chơi và trình mô phỏng sẽ trở thành môi trường để Agent kiểm tra và cải thiện tác phẩm, giống như các Agent mã hóa ngày nay đang tận dụng sandbox và máy ảo.


Thứ hai, chất lượng của bối cảnh lặp sẽ trở nên quan trọng hơn bao giờ hết. Để đưa Agent vào "vòng lặp Ralph" của phiên bản mã hình ảnh, biểu diễn trung gian phải đủ chính xác để hướng dẫn bước tiếp theo. Mô hình không chỉ cần biết "có thứ gì đó trông không ổn", mà còn phải biết nên sửa phần nào trong tệp nguồn và tại sao lại sửa như vậy. Những lỗi nhỏ trong cấu trúc, kết xuất hoặc phản hồi có thể nhanh chóng tích lũy qua nhiều vòng lặp.


Thứ ba, tương lai rất có thể sẽ là sự kết hợp. Các mô hình pixel gốc vẫn giỏi nhất về tính chân thực, kết cấu và khám phá; các hệ thống mã gốc phù hợp hơn với cấu trúc, lặp và sản xuất. Các quy trình làm việc hữu ích nhất sẽ kết hợp cả hai.


Tất nhiên, vẫn còn nhiều câu hỏi mở. Mỗi lĩnh vực cuối cùng sẽ áp dụng dạng biểu diễn nào? Liệu chúng ta có cần phải xây dựng lại các công cụ và trình kết xuất, thay vì tiếp tục sử dụng các công cụ thế hệ trước? Thị hiếu hình ảnh có thể được nắm bắt ở mức độ nào thông qua các ràng buộc, kiểm thử và vòng lặp phản hồi?


Nhưng hướng đi đã rất rõ ràng: AI thị giác đang chuyển từ đầu ra sang các sản phẩm mã nguồn. Làn sóng đầu tiên giúp việc tạo hình ảnh trở nên dễ dàng hơn; làn sóng tiếp theo sẽ giúp việc tạo ra các sản phẩm thị giác có thể chỉnh sửa, kiểm thử, bàn giao và cải tiến trở nên dễ dàng hơn.


[Liên kết gốc]



Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia

举报 Báo lỗi/Báo cáo
Chọn thư viện
Thêm mới thư viện
Hủy
Hoàn thành
Thêm mới thư viện
Chỉ mình tôi có thể nhìn thấy
Công khai
Lưu
Báo lỗi/Báo cáo
Gửi