Robot không cần thêm demo đẹp

Robot không cần thêm demo đẹp

LeRobot v0.6.0 đáng chú ý không vì model mới, mà vì nó kéo robot learning về một quyết định builder rất thực tế: bạn đã khép được vòng học chưa?

Một team robotics nhắn mình lúc gần nửa đêm: có nên nhảy vào release mới không, hay cứ ở yên với pipeline cũ cho đỡ đau đầu? Câu hỏi nghe quen đến mức mình muốn in ra dán cạnh màn hình: cái mới không phải luôn là cái cần đưa vào production.

LeRobot v0.6.0 là một release khá nhiều món: world models, VLA mới, reward models, dataset nhanh hơn, depth support, annotation bằng VLM, benchmark CLI, deployment CLI, FSDP, HF Jobs. Nếu đọc lướt, bạn rất dễ bị lực hấp dẫn của model zoo kéo vào quỹ đạo so sánh model này với model kia.

Nhưng điểm đáng bàn không nằm ở chỗ có thêm bao nhiêu model. Điểm đáng bàn là: release này đang đẩy robot learning từ demo một lần sang vòng lặp học được từ thất bại.

Sau bài này, mình muốn bạn đổi một cách nghĩ: đừng hỏi LeRobot v0.6.0 có đáng thử không. Hỏi đúng hơn là: team bạn đã có điều kiện để biến rollout hỏng thành dữ liệu học tiếp chưa?

Sơ đồ minh họa cho bài Robot không cần thêm demo đẹp

Sơ đồ tóm tắt ý chính của bài viết.

Tín hiệu thật: không phải thêm model, mà là khép vòng

Trong AI thông thường, bạn có thể ship chatbot, log hội thoại, sửa prompt, thêm RAG, rồi cải thiện dần. Với robot, mọi thứ khó chịu hơn: robot làm sai có thể làm rơi đồ, kẹt tay gắp, va vào vật thể, hoặc tạo ra dữ liệu rất lộn xộn.

LeRobot v0.6.0 đặt trọng tâm vào vòng lặp này:

Nói thẳng ra thì, đây không phải release chỉ để bạn đổi động cơ model. Nó giống việc dựng một trạm quan sát quanh dự án robotics: nhìn được robot làm gì, fail ở đâu, fail đó có đáng học lại không, rồi đưa dữ liệu quay về training.

Điều này khác hẳn làn sóng image-to-video như Grok Imagine Video 1.5. Ở đó, giá trị chính nằm ở việc biến một ảnh thành video ngắn, có thể điều khiển camera movement, pacing, atmosphere, và giữ chi tiết hình ảnh tương đối nhất quán. Rất hữu ích cho creative workflow. Nhưng với robot, video đẹp không đủ. Bạn cần hành động đúng trong thế giới có ma sát, cảm biến, độ trễ, và vật thể không chịu ngồi yên cho model diễn.

Mổ xẻ theo quyết định: team bạn thuộc nhóm nào?

Thay vì hỏi có nên dùng hay không, mình sẽ chia thành ba nhóm quyết định.

Nhóm 1: Đang làm robotics research hoặc lab nội bộ

Nếu bạn đang train policy, có dữ liệu thao tác, hoặc đã có simulation environment, LeRobot v0.6.0 đáng để đưa vào backlog nghiêm túc.

Lý do:

Quyết định của nhóm này: thử v0.6.0 như một vòng learning loop, không phải như một model swap.

Nhóm 2: Startup đang làm automation vật lý quy mô nhỏ

Giả sử team bạn 5 người, có một robot arm xử lý tác vụ lặp lại trong kho nhỏ: gắp vật, phân loại, đặt vào khay. Bạn chưa cần chạy theo tất cả VLA mới. Cái đáng lấy trước là phần dataset và rollout.

LeRobot v0.6.0 có vài điểm thực dụng:

Quyết định của nhóm này: đừng bắt đầu bằng model to nhất; bắt đầu bằng dữ liệu sạch hơn và rollout có log tốt hơn.

Nhóm 3: Team AI app chưa có robot thật

Nếu bạn chỉ đang làm agent, RAG, coding assistant, hoặc video generation, LeRobot v0.6.0 chưa chắc là thứ cần kéo vào sprint.

Bạn vẫn nên đọc release để học pattern: khép vòng từ hành động → đánh giá → dữ liệu → cải thiện. Nhưng đừng tự ép mình phải chạy robotics stack nếu chưa có bài toán vật lý.

Quyết định của nhóm này: theo dõi kiến trúc, chưa cần adoption.

Bảng tradeoff: chọn phần nào trước?

| Thành phần | Dùng khi nào | Lợi ích | Cái giá |
|---|---|---|---|
| World models | Bạn cần policy dự đoán hậu quả trước khi hành động | Giảm kiểu hành động mù | Khó debug hơn, cần dữ liệu tốt |
| VLA model zoo | Bạn đang so nhiều policy cho tác vụ thật | Có thêm lựa chọn baseline | Dễ sa vào benchmark chasing |
| Reward models | Bạn có nhiều rollout cần chấm thành công | Giảm sức người review | Reward sai có thể dạy robot sai |
| lerobot-rollout | Bạn muốn deployment có quy trình riêng | Biến failure thành dữ liệu có cấu trúc | Cần chuẩn hóa log và môi trường |
| FSDP | Model lớn hơn GPU đơn | Train phân tán hiệu quả hơn | Tăng độ phức tạp vận hành |
| HF Jobs | Muốn train trên cloud thay vì tự dựng hạ tầng | Nhanh có môi trường chạy | Cần kiểm soát chi phí và dữ liệu |

FSDP, hay Fully Sharded Data Parallel, là cách chia nhỏ trọng số và trạng thái training qua nhiều GPU để train model lớn hơn giới hạn một máy. Với builder, câu hỏi không phải FSDP có hay không, mà là team bạn đã đủ đau vì giới hạn GPU chưa.

Ví dụ cụ thể: rollout hỏng nên đi đâu?

Hình dung thế này: robot của bạn được giao nhặt một vật màu đỏ và đặt vào khay bên phải. Nó nhặt đúng vật, nhưng đặt lệch mép khay. Demo nhìn qua thì cũng gần đúng, nhưng production thì fail.

Với pipeline yếu, bạn sẽ có video fail nằm trong folder nào đó, rồi một người trong team xem lại, ghi chú bằng tay, có khi tuần sau quên mất.

Với tư duy mà LeRobot v0.6.0 đang đẩy mạnh, rollout hỏng nên đi theo đường này:

  1. lerobot-rollout chạy policy và lưu dữ liệu hành động.
  2. Sensor ghi lại RGB, depth, trạng thái robot nếu có.
  3. Reward model đánh dấu kết quả không đạt.
  4. VLM annotation mô tả tình huống: vật đúng, vị trí đặt sai, khay bên phải bị lệch.
  5. Dữ liệu fail quay lại tập train hoặc tập evaluate.
  6. Benchmark CLI kiểm tra policy mới có sửa được lỗi này không.

Đây là điểm mình thấy nhiều team hiểu sai: robotics AI không thắng bằng một demo clip mượt, mà bằng khả năng tái sử dụng thất bại.

Một video generation model có thể tạo cảnh 720p đẹp từ ảnh tĩnh. Nhưng robot policy cần chịu trách nhiệm với hành động. Trong vũ trụ robotics, mỗi failure là một thiên thạch nhỏ; nếu không theo dõi quỹ đạo của nó, nó sẽ quay lại đập vào production lúc bạn ít ngờ nhất.

Một buổi chiều nên thử gì?

Nếu bạn là tech lead, đừng mở sprint bằng câu: nâng toàn bộ stack lên v0.6.0. Mở bằng một thí nghiệm có biên rõ.

Trong một buổi chiều, bạn có thể làm thế này:

1. Chọn một tác vụ nhỏ

Ví dụ minh họa: pick-and-place một loại vật thể, cùng một góc camera, cùng một bề mặt. Đừng chọn ngay tác vụ đa vật thể, ánh sáng thay đổi, camera rung, vật thể phản chiếu.

Mục tiêu là kiểm tra vòng lặp, không phải chứng minh robot thông minh.

2. Định nghĩa failure taxonomy

Tạo 5 nhãn lỗi đủ dùng:

Nếu reward model chưa đủ tin cậy, dùng nhãn người chấm trước. Reward model nên được xem như người phụ chấm bài, không phải trọng tài tuyệt đối ngay ngày đầu.

3. Chạy rollout và giữ log có cấu trúc

Dù dùng CLI nào, hãy đảm bảo mỗi rollout có tối thiểu:

run_id: pick_red_block_001
policy_version: policy_baseline_a
scene: tray_right_static
inputs:
  rgb: true
  depth: true
evaluation:
  success: false
  failure_type: placed_wrong_position
notes: object picked correctly, placement offset

Điểm mấu chốt: log phải đọc được bởi người và máy. Nếu failure chỉ nằm trong tên file kiểu final_final_test3.mp4, bạn đang tự khóa cửa phòng thí nghiệm của mình.

4. So sánh bằng benchmark nhỏ trước

Nếu sáu benchmark simulation mới trong LeRobot phù hợp bài toán của bạn, tốt. Nếu không, tạo benchmark nội bộ nhỏ: cùng scene, cùng số rollout giả định, cùng tiêu chí pass/fail. Không cần phô trương. Cần lặp lại được.

5. Chỉ đổi một biến mỗi lần

Đổi model, đổi sensor, đổi reward, đổi dataset cùng lúc là cách rất nhanh để không biết thứ gì tạo ra cải thiện. Với robotics, debug mù tốn hơn nhiều so với đi chậm có kiểm soát.

Điều đáng giữ, điều nên bỏ qua

Điều đáng giữ nhất từ LeRobot v0.6.0 là framework vận hành: imagine, evaluate, improve. Cho policy dự đoán, cho hệ thống đánh giá, rồi đưa kết quả quay lại cải thiện.

Điều nên bỏ qua là cảm giác phải thử mọi model trong release. Model zoo càng lớn, quyết định càng cần chặt. Nếu không, team bạn sẽ dành hai tuần đổi checkpoint và vẫn chưa biết failure chính nằm ở perception, action, reward hay data.

Với Grok Imagine Video 1.5, bài học phụ cũng rõ: thế giới AI đang rất thích chữ imagine. Nhưng imagine trong video generation là tạo chuyển động nhìn hợp lý. Imagine trong robot learning là dự đoán hậu quả để hành động ít ngu hơn. Hai thứ cùng dùng một từ, nhưng áp lực production khác hẳn.

Khuyến nghị của mình:

Rủi ro còn lại: reward model sai, benchmark không đại diện, dữ liệu depth lệch giữa lab và thực tế, chi phí cloud training khó đoán, và đội ngũ bị hút vào so model thay vì sửa loop.

Chốt lại: release này không hỏi bạn có thích robot thông minh hơn không. Nó hỏi team bạn có đủ kỷ luật để biến mỗi lần robot làm sai thành nhiên liệu học tiếp không. Không có trạm quan sát thì đừng trách vì sao tàu cứ bay lệch quỹ đạo.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo