Robot AI: đừng nhìn model, nhìn quỹ đạo dữ liệu

Xiaomi-Robotics-1 nhắc builder một điều hơi phũ: với robot AI, lợi thế không nằm ở model to hơn mà ở cách tạo, gắn nhãn và chuyển dữ liệu sang đời thật.

11 giờ đêm, Nam — tech lead của một team automation ở Bình Dương — nhắn mình một câu rất thật: “Bên em có nên chờ model robot mới nhất không chị, hay tự gom data trước?”

Mình đọc xong cười nhẹ. Không phải vì câu hỏi ngây thơ, mà vì nó quá quen. Team nào bước từ LLM sang robotics cũng dễ mang theo một phản xạ: model mới hơn, to hơn, benchmark cao hơn thì chắc đáng chọn hơn. Nhưng robot AI không bay theo cùng quỹ đạo với chatbot. Ở đây, lực hấp dẫn lớn nhất thường không phải parameter count, mà là dữ liệu hành động trong môi trường thật.

Xiaomi-Robotics-1 là một tín hiệu đáng mổ xẻ vì nó nói khá rõ chuyện này: model lớn hơn có giúp, nhưng nhiều dữ liệu huấn luyện hơn tạo ra bước nhảy đáng kể hơn. Và điểm thú vị không nằm ở câu “robot AI đang tiến bộ”, mà ở cách Xiaomi né nút thắt đắt nhất: họ phần lớn không dùng robot thật để thu data.

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

Thứ đang diễn ra: robotics đang học bài scaling, nhưng đề thi khác LLM

Với LLM, scaling thường xoay quanh compute, data text, tokenizer, context window. Internet là một mỏ chữ khổng lồ. Bạn có thể tranh luận về chất lượng, bản quyền, lọc nhiễu, nhưng ít nhất “chữ” có sẵn ngoài kia.

Robot thì khác. Một robot muốn biết cách cầm cái ly, mở ngăn kéo, nhặt đồ trong bếp, đẩy xe qua hành lang… nó cần dữ liệu về thao tác vật lý: camera nhìn thấy gì, tay chuyển động ra sao, lực và hướng thế nào, kết quả có thành công không. Loại dữ liệu này không tự nằm rải trên web như bài blog hay repo GitHub.

Cách truyền thống là cho người điều khiển robot thật làm từng thao tác. Chậm, tốn tiền, và dễ bị “kẹt quỹ đạo”: cùng một robot, cùng một phòng lab, cùng vài loại vật thể, lặp đi lặp lại. Model nhìn có vẻ học được, nhưng ra khỏi lab là lúng túng.

Xiaomi chọn hướng khác: dùng gripper cầm tay có camera gắn kèm, để người vận hành thao tác trực tiếp trong nhiều môi trường như bếp, văn phòng, cửa hàng, nhà máy, ngoài trời. Không cần kéo robot đến mọi nơi. Kết quả là hơn 100.000 giờ ghi lại chuyển động. Phần mô tả dữ liệu cũng không dán nhãn thủ công hết; họ dùng một model AI khác để mô tả từng đoạn chuyển động bằng text và nói đã gắn nhãn toàn bộ trong khoảng hai tuần.

Dịch sang tiếng người: họ không chỉ train robot; họ thiết kế lại dây chuyền tạo dữ liệu cho robot.

Va chạm của team Nam: mua robot trước hay mua khả năng quan sát trước?

Nam kể team đang có một line kiểm hàng bán tự động. Ý tưởng ban đầu là mua cánh tay robot, gắn camera, rồi fine-tune model để nhặt sản phẩm lỗi ra khỏi khay. Nghe hợp lý. Nhưng khi hỏi kỹ, mình phát hiện team chưa có log thao tác, chưa có video lỗi đa dạng, chưa biết vật thể thay đổi theo ca sản xuất thế nào, và chưa có cách mô tả “thành công” ngoài câu “nhìn bằng mắt thấy ổn”.

Đây là lỗi mình thấy nhiều builder mắc: nhảy thẳng vào embodiment — phần thân robot thật — khi chưa có trạm quan sát dữ liệu đủ tốt. Trong robotics, embodiment là chuyện robot có cơ thể, cảm biến, giới hạn chuyển động và tương tác vật lý với môi trường. Nó quan trọng, nhưng không phải lúc nào cũng là bước đầu tiên.

Hình dung thế này: nếu bạn muốn dạy một người mới bốc xếp hàng trong kho, bạn không chỉ đưa họ đôi găng tay xịn rồi bảo “tự học đi”. Bạn cho họ xem nhiều tình huống, chỉ đâu là hàng dễ vỡ, đâu là góc khuất, lúc nào cần xoay thùng, khi nào không được chồng lên. Robot cũng vậy, chỉ khác là nó cần dữ liệu có cấu trúc hơn nhiều.

Điểm Xiaomi gợi ý cho team như Nam là: trước khi hỏi “model nào?”, hãy hỏi “chúng ta có thể thu được bao nhiêu hành vi đúng, trong bao nhiêu bối cảnh, với chi phí nào?”

Mổ xẻ lớp đáng tiền: data interface quan trọng hơn demo robot chạy đẹp

Có ba lớp cần tách ra khi nhìn các release robotics gần đây.

Lớp 1: Thu dữ liệu rẻ hơn robot thật.
Gripper cầm tay của Xiaomi là một ví dụ của data collection interface — giao diện thu dữ liệu. Nó không cố mô phỏng toàn bộ robot ngay từ đầu, mà ghi lại thao tác người làm trong môi trường đa dạng. Tradeoff nằm ở chỗ dữ liệu từ gripper không khớp hoàn toàn với cánh tay robot thật. Khi chuyển sang robot, vẫn có khoảng cách gọi là transfer gap — độ lệch giữa nguồn dữ liệu huấn luyện và phần cứng triển khai.

Nhưng nếu cách này giúp thu được nhiều bối cảnh hơn, nó có thể đáng hơn việc có ít dữ liệu “chuẩn robot” nhưng nghèo tình huống.

Lớp 2: Gắn nhãn bằng model khác, nhưng đừng ngủ quên.
Việc dùng AI để mô tả đoạn chuyển động giúp mở rộng dataset nhanh. Tuy nhiên với builder, auto-labeling — gắn nhãn tự động — không miễn phí về mặt rủi ro. Nếu model mô tả sai hành động, hoặc bỏ qua chi tiết quan trọng như “tay xoay nhẹ trước khi nhấc”, robot có thể học một câu chuyện thiếu mảnh ghép.

Trong production, mình sẽ không tin toàn bộ nhãn tự động. Cần có sampling audit — kiểm tra mẫu định kỳ — theo nhóm tác vụ: nhặt, đặt, xoay, mở, kéo, tránh vật cản. Không cần kiểm hết, nhưng phải biết lỗi nhãn đang tập trung ở đâu.

Lớp 3: Benchmark chỉ là kính thiên văn, không phải bản đồ bay.
Mistral với Robostral Navigate nhắm vào navigation — robot đi qua môi trường — dùng một camera RGB và đạt tối đa 79,4% trên R2R-CE, theo công bố của họ. Con số này đáng chú ý, nhất là khi model được train trong môi trường mô phỏng với khoảng 400.000 đường đi qua 6.000 không gian ảo. Nhưng navigation khác manipulation. Đi đến cái bàn và cầm đúng cái cốc là hai bài toán khác nhau.

Với team builder, câu hỏi không phải “benchmark nào cao hơn?” mà là “benchmark đó đo đúng failure mode của mình không?” Nếu robot của bạn chủ yếu gắp vật thể biến dạng, điểm navigation đẹp không trả lời được nhiều.

Framework 4 câu hỏi trước khi chọn model robot

Nếu là team của Nam, mình sẽ không lập tức mua model mới nhất. Mình sẽ dùng một framework ngắn để quyết định đường đi.

1. Tác vụ của bạn là đi, nhìn, hay thao tác?

Navigation, perception và manipulation là ba vùng khác nhau. Perception là nhận biết hình ảnh hoặc trạng thái; manipulation là cầm, kéo, đặt, xoay vật thể. Một model giỏi đi trong hành lang chưa chắc giỏi mở nắp hộp.

Ghi rõ tác vụ chính giúp tránh mua sai năng lực.

2. Dữ liệu thật đang thiếu ở đâu?

Đừng chỉ đếm số video. Hãy chia theo môi trường, vật thể, ánh sáng, góc camera, người vận hành, trạng thái lỗi. Nếu tất cả data đến từ một góc máy và một loại khay, model đang học “sân nhà”, không học thế giới.

Ví dụ cụ thể: giả sử team bạn có 200 giờ video thao tác, nhưng 180 giờ đến từ ca sáng, cùng ánh sáng, cùng một SKU. Khi chuyển sang ca tối hoặc sản phẩm mới, model có thể rơi khỏi quỹ đạo quen thuộc ngay.

3. Bạn có interface thu data nào rẻ hơn robot không?

Không phải team nào cũng cần gripper như Xiaomi. Nhưng có thể dùng camera gắn trên dụng cụ, recording từ thao tác người, teleoperation đơn giản, hoặc mô phỏng nếu bài toán phù hợp. Mục tiêu là tăng đa dạng hành vi trước khi đốt tiền vào robot uptime.

Robot thật nên được dùng để validate và fine-tune phần transfer, không nhất thiết là máy quay chính cho mọi data.

4. Bạn đo thành công bằng execution, không chỉ bằng output đẹp chứ?

Bài học này không chỉ có trong robotics. SQRL của Feyn AI trong text-to-SQL cũng đi theo hướng “kiểm tra trước khi trả lời”: model có thể inspect database — chạy truy vấn đọc để xem dữ liệu thật — trước khi viết SQL cuối. Vì SQL đúng cú pháp vẫn có thể trả kết quả sai.

Robot cũng vậy. Video demo mượt không đủ. Bạn cần đo task success, lỗi va chạm, thời gian hoàn thành, khả năng phục hồi sau khi trượt, và độ ổn định khi đổi môi trường. Nói thẳng ra thì, nếu metric không chạm vào thế giới thật, nó chỉ là ánh sáng đẹp trên màn hình.

Điều đáng giữ lại, và phần nên bỏ qua

Điều đáng giữ từ Xiaomi-Robotics-1 không phải là “hãy bắt chước Xiaomi”. Phần đáng giữ là tư duy: mở rộng dữ liệu hành động bằng interface rẻ hơn, đa dạng hơn, rồi xử lý transfer sang robot thật như một bài toán riêng.

Điều nên bỏ qua là FOMO quanh model release. Robotics sẽ còn nhiều tên mới, nhiều benchmark mới, nhiều tuyên bố “ít camera hơn”, “ít training hơn”, “general hơn”. Sakana với Fugu Ultra v1.1 ở mảng model router cũng nhắc mình một bài học tương tự: claim benchmark tự công bố có thể thú vị, nhưng builder cần nhìn latency, cost, phạm vi phục vụ, và kiểm chứng độc lập trước khi đưa vào workflow. Với robot, cái giá của sai không chỉ là token đắt; nó có thể là cánh tay máy dừng line sản xuất.

Còn nguồn PDF-to-JSON open-source thì kéo câu chuyện về một điểm rất thực dụng: đôi khi lợi thế không nằm ở model “thông minh hơn”, mà ở việc biến dữ liệu bẩn thành dạng hệ thống dùng được. Robotics cũng đang đi qua đoạn đường tương tự. Ai có pipeline dữ liệu tốt hơn, người đó có cơ hội bay xa hơn.

Nếu là mình, mình sẽ chọn quỹ đạo này

Với một team Việt Nam đang build robotics AI, mình sẽ làm theo thứ tự:

1. Khoanh tác vụ hẹp: một thao tác, một nhóm vật thể, một môi trường trước.
2. Thiết kế data collection interface: tìm cách ghi hành vi người làm với chi phí thấp hơn chạy robot liên tục.
3. Tạo schema nhãn tối giản: hành động, vật thể, trạng thái trước/sau, lỗi nếu có.
4. Dùng auto-labeling có kiểm mẫu: tiết kiệm thời gian nhưng không giao toàn bộ tay lái cho model.
5. Đưa robot thật vào vòng kiểm chứng sớm: đo transfer gap, không chờ dataset hoàn hảo mới test.

Sau bài này, điều mình muốn bạn nghĩ khác là: trong robotics AI, “model nào mạnh nhất?” thường là câu hỏi đến hơi sớm. Câu đáng hỏi trước là: team mình có đang tạo được quỹ đạo dữ liệu đủ rộng để model học điều thật sự cần làm không?

Robot không thiếu sân khấu để biểu diễn; nó thiếu nhật ký va chạm với đời thật. Và đời thật thì, như vũ trụ, không nhân nhượng với demo quay một góc đẹp.

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