Release AI đáng soi là lỗi nó dám sửa

Release AI đáng soi là lỗi nó dám sửa

Antidoom không làm model thông minh hơn theo kiểu hào nhoáng. Nó nhắc builder nhìn release qua failure mode: lỗi nào được đóng, đóng ở đâu, và có phá thứ khác không.

11 giờ đêm, Minh — tech lead của một team AI nội bộ ở Sài Gòn — nhắn vào group: model reasoning mới chạy bài toán code ngon hơn, nhưng thỉnh thoảng nó tự lặp một đoạn như diễn viên quên thoại rồi cứ nói lại câu cũ đến khi hết sân khấu.

Bạn biết cảm giác đó chứ. Log đang đẹp, token vẫn chảy, GPU vẫn nóng, dashboard vẫn xanh. Nhưng output thì kẹt trong một vòng lặp kiểu: wait, alternatively, wait, alternatively… cho đến khi context window — vùng ngữ cảnh model còn giữ được trong một lượt xử lý — bị ăn sạch.

Cái đáng nói ở Antidoom của Liquid AI không phải là thêm một model mới để bạn đổi endpoint. Điểm đáng soi là: họ chọn một failure mode rất cụ thể, mổ nó tới đúng token bắt đầu gây lỗi, rồi sửa ở đúng chỗ đó.

Sau bài này, mình muốn bạn đổi câu hỏi từ: release này mạnh không? sang: release này đóng được lỗi vận hành nào, với phạm vi can thiệp nhỏ tới đâu?

Sơ đồ minh họa cho bài Release AI đáng soi là lỗi nó dám sửa

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

Cảnh đang diễn ra: demo càng dài, lỗi càng thích lộ mặt

Team của Minh có một agent giải bài coding interview nội bộ để hỗ trợ review. Prompt khó, model phải suy luận nhiều bước. Với câu dễ, mọi thứ ổn. Với câu dài hơn, model bắt đầu sinh ra doom loop — vòng lặp đầu ra, tức model phát ra một đoạn rồi lặp lại chính đoạn đó liên tục.

Đây không phải lỗi hài hước kiểu model nói lan man. Đây là lỗi production khá đau:

Antidoom nhắm đúng lỗi này. Trên checkpoint sớm của LFM2.5-2.6B, tỉ lệ completion bị lặp trên các prompt toán và coding khó giảm từ 10.2% xuống 1.4% sau training. Với Qwen3.5-4B, nguồn ghi nhận mức giảm từ 22.9% xuống 1%.

Quan trọng hơn: phương pháp này không dạy model thêm toán hay code. Nó gỡ cái dây kéo màn đang mắc, để phần biểu diễn vốn đã có thể diễn ra được tiếp.

Mổ đúng chỗ: sửa token mở vòng, không đập cả sampling

Nói thẳng ra thì Antidoom thú vị vì nó nhỏ.

Cơ chế chính là Final Token Preference Optimization, viết tắt FTPO — tối ưu ưu tiên ở token cuối của đoạn dẫn tới lỗi. Nó gần họ hàng với DPO — Direct Preference Optimization, cách train model thích câu trả lời được chọn hơn câu bị loại — nhưng ở đây đơn vị xử lý hẹp hơn: một completion token tại điểm bắt đầu loop.

Thay vì nói: model hay lặp, vậy giảm temperature, đổi top-p, thêm penalty, hoặc fine-tune lại cả tập lớn, Antidoom làm việc này:

  1. tìm đoạn output bắt đầu lặp;
  2. xác định token đầu tiên khởi động vòng lặp;
  3. tạo cặp chosen/rejected ở đúng vị trí đó;
  4. train để model ưu tiên nhiều lựa chọn hợp lý khác, không chỉ thay bằng một token cố định.

Điểm này đáng giá với builder. Vì trong production, can thiệp càng rộng thì rủi ro regression càng lớn. Bạn bóp repetition penalty quá tay, model có thể né cả những cấu trúc lặp hợp lệ trong code, bảng, hoặc lập luận từng bước. Bạn đổi sampling global, mọi prompt đều bị ảnh hưởng dù chỉ một nhóm prompt gặp lỗi.

Antidoom chọn intervention radius — bán kính can thiệp — rất nhỏ: đúng token mở loop. Phần còn lại của phân phối xác suất được giữ tương đối nguyên.

Ví dụ cụ thể: giả sử agent của bạn hay kẹt khi giải thích bug phức tạp bằng chuỗi ‘Wait… Alternatively…’. Cách xử lý thô là thêm rule cắt output khi thấy lặp ba lần. Cách đó cứu tiền token, nhưng không giúp model đi tiếp. Cách tinh hơn là huấn luyện hoặc điều chỉnh tại điểm model chuẩn bị chọn token mở đầu vòng lặp, để nó rẽ sang một hướng suy luận khác vẫn hợp lý.

Framework cho builder: soi release bằng failure-mode card

Các release gần đây có một mẫu chung đáng học: thứ đáng giữ không nằm ở tên model, mà nằm ở lỗi cụ thể nó dám nhận và cách nó đo lỗi đó.

Mình hay dùng một thẻ 5 dòng khi đọc release cho team build hệ thống AI:

| Câu hỏi | Vì sao quan trọng |
|---|---|
| Failure mode là gì? | Lỗi phải gọi tên được: doom loop, long-horizon drift, interactive latency, throughput nghẽn, mất boundary. |
| Lỗi xuất hiện khi nào? | Prompt dài, tương tác nhiều bước, video dài, request 1M-token, hay robot đổi embodiment? |
| Can thiệp ở đâu? | Training objective, attention mask, distillation, compression, serving format, hay policy head? |
| Bán kính ảnh hưởng rộng không? | Sửa một token, một block, một mask, hay đổi toàn bộ behavior? |
| Tradeoff được công bố là gì? | Có mất điểm benchmark, tăng latency, cần GPU mới, hoặc phụ thuộc data pipeline không? |

Áp card này vào Antidoom:

Đó là một release có thể đưa vào backlog thử nghiệm, vì nó trả lời được câu hỏi vận hành.

Nhìn sang các release khác: cùng một tín hiệu, khác mặt nạ

LingBot-World-Infinity cũng không chỉ đáng chú ý vì sinh video tương tác. Nó gọi tên hai lỗi: long-horizon drift — chất lượng trôi dần khi chuỗi tương tác kéo dài — và interactive latency — độ trễ khi người dùng hành động liên tục. Phần kỹ thuật như MoBA Attention Mask — mask chú ý trộn bidirectional và autoregressive — là đạo cụ phía sau, nhưng failure mode mới là lý do để builder quan tâm.

LingBot-Vision thì đảo ưu tiên của vision foundation model. Thay vì chỉ học ngữ nghĩa kiểu ảnh này có con gì, nó nhấn vào boundary — ranh giới, contour, discontinuity — vì robot cần biết mép vật nằm đâu để thao tác. Đây là kiểu release đáng đọc nếu bạn làm dense spatial perception, không phải nếu bạn chỉ cần image captioning.

Nemotron-Labs-3-Puzzle-75B-A9B lại là câu chuyện khác: giảm chi phí phục vụ. Nguồn nêu mục tiêu từ đầu: tăng server throughput ở cùng user throughput và hỗ trợ nhiều request 1M-token hơn trên phần cứng cụ thể. Nhưng tradeoff cũng hiện rõ: Arena-Hard-V2 giảm 4.2 điểm, SWE-Bench giảm 2.6 điểm. Tức là không có màn tung hoa giấy miễn phí; có chỗ được, có chỗ mất.

Nhìn vậy, Antidoom nằm trong một nhóm release mình thích hơn hẳn các màn khoe model chung chung: release bắt đầu từ lỗi thật.

Điều nên bỏ qua: tiếng ồn quanh ‘open-source’ và điểm số đẹp

Open-source là tốt, nhưng không tự động biến một phương pháp thành phù hợp với stack của bạn. Với Antidoom, câu hỏi thực tế không phải là có mở mã không, mà là team bạn có đủ log để phát hiện loop-start token không, có pipeline tạo chosen/rejected pair không, và có chỗ nào trong vòng đời model để retrain an toàn không.

Nếu bạn đang dùng API đóng, Antidoom có thể chưa áp dụng trực tiếp. Nhưng framework vẫn dùng được: thay vì chỉ thêm stop sequence, hãy đo nhóm prompt gây loop, vị trí loop bắt đầu, token pattern, độ dài trước khi kẹt, và chi phí token bị đốt.

Nếu bạn self-host model nhỏ cho reasoning, đây là nơi đáng thử hơn. Không phải vì nó sẽ biến model 2-4B thành thiên tài, mà vì nó xử lý một lỗi làm năng lực sẵn có không ra được ngoài.

Checklist một buổi cho team của Minh sẽ là:

1. Lấy 100-300 prompt khó từng gây output lặp.
2. Gắn detector đơn giản: n-gram repeat, đoạn lặp liên tiếp, completion dài bất thường.
3. Lưu lại vị trí token đầu tiên mở loop.
4. Phân loại: loop do discourse marker, do code block, do template, hay do prompt nhập nhằng.
5. Quyết định: cắt ở inference, sửa prompt, hay đưa vào pipeline preference training.

Phần số lượng ở trên là ví dụ minh họa cho một buổi audit nhỏ, không phải benchmark. Mục tiêu là tạo bản đồ lỗi trước khi chọn thuốc.

Giữ lại gì cho lần đọc release tiếp theo?

Nếu là mình, mình sẽ không đưa Antidoom vào danh sách ‘model mới phải thử’ chung chung. Mình sẽ đưa nó vào ngăn kéo khác: kỹ thuật giảm lỗi suy luận có phạm vi can thiệp hẹp.

Đó cũng là cách mình đọc LingBot, Nemotron Puzzle, hay các release tương tự: không hỏi ai đang đứng dưới ánh đèn mạnh nhất, mà hỏi hậu trường vừa sửa được chỗ nào hay gây sập show.

Takeaway gọn: release AI đáng tin hơn khi nó gọi đúng tên lỗi, sửa đúng điểm nghẽn, và nói rõ phần phải đánh đổi. Còn nếu chỉ thấy pháo sáng mà không thấy dây điện phía sau, khoan vỗ tay đã — có khi màn tiếp theo là debug.

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

Nguồn tham khảo