Dưới đây là phân tích từ ba báo cáo kỹ thuật gần đây: bài báo về Kimi K2.5 của Moonshot AI, báo cáo và bài đăng blog về Composer 2 của Cursor, và bài viết về Context-1 của Chroma.
Mỗi báo cáo giới thiệu một điểm khác biệt đặc trưng:
  • Kimi K2.5 huấn luyện một Agent Swarm (Bầy đàn Agent), nơi mô hình học cách chia nhỏ nhiệm vụ thành các agent phụ chạy song song thông qua RL (Học tăng cường).
  • Composer 2 của Cursor sử dụng cơ chế tự tóm tắt (self-summarization) để xử lý các phiên lập trình dài và chạy RL thời gian thực từ lưu lượng truy cập thực tế (production traffic).
  • Context-1 của Chroma dạy mô hình cách tự chỉnh sửa ngữ cảnh: chủ động loại bỏ các tài liệu đã truy xuất để giải phóng không gian cho các lượt tìm kiếm tiếp theo.
Cả ba đều sử dụng học tăng cường với phương pháp luận tương tự:
  1. Bắt đầu từ một mô hình nền tảng mạnh: Không có bên nào huấn luyện từ đầu. Moonshot mở rộng từ Kimi K2 với tiền huấn luyện đa phương thức. Cursor bắt đầu từ Kimi K2.5 (1T tham số/32B active MoE). Chroma sử dụng gpt-oss-20B.
  2. Huấn luyện bên trong môi trường thực tế (production harness): Mỗi đội ngũ chạy các kịch bản RL (rollouts) thông qua cùng một bộ công cụ, câu lệnh (prompt) và môi trường thực thi mà mô hình của họ gặp phải trong thực tế.
  3. Phần thưởng dựa trên kết quả (Outcome-based rewards): Cả ba đều sử dụng các tín hiệu kết quả có thể kiểm chứng và các Mô hình Phần thưởng Tạo sinh (GRM) đặc biệt cho các nhiệm vụ mở, phong cách hoặc quy tắc ứng xử.
  4. Triển khai quy mô lớn, bất đồng bộ: Mỗi hệ thống tạo ra các quỹ đạo (trajectories) song song cho mỗi bước huấn luyện. Việc triển khai Agent rất tốn kém, vì vậy tất cả đều đầu tư mạnh vào cơ sở hạ tầng để chạy chúng ở quy mô lớn.

Kimi K2.5: Agent Swarm và điều phối Agent song song thông qua RL

Bài báo: Kimi K2.5: Visual Agentic Intelligence
Kimi K2.5 là mô hình đa phương thức của Moonshot AI với kiến trúc MoE 1T tham số / 32B active. Tính năng đặc biệt nhất của nó là Agent Swarm, một khung làm việc nơi mô hình học cách phân rã nhiệm vụ một cách linh hoạt thành các nhiệm vụ phụ song song và điều phối chúng cho các agent phụ. Chiến lược song song hóa này được học thông qua RL, không phải được lập trình sẵn bằng tay.
PARL: Parallel-Agent Reinforcement Learning (Học tăng cường Agent song song)
Hầu hết các hệ thống agent hiện nay thực thi tuần tự: suy nghĩ → gọi công cụ → quan sát → suy nghĩ → gọi công cụ. Agent Swarm phá vỡ điều này bằng cách huấn luyện mô hình để sản sinh (spawn) các agent phụ chạy song song.
Kiến trúc này bao gồm hai vai trò:
  • Orchestrator (Bộ điều phối - Có thể huấn luyện): Quyết định khi nào cần tạo agent phụ, giao nhiệm vụ gì và cách tổng hợp kết quả của chúng. Được trang bị các công cụ create_subagent và assign_task.
  • Sub-agents (Agent phụ - Bị đóng băng): Thực thi các nhiệm vụ phụ được giao một cách độc lập. Các quỹ đạo hoạt động của chúng bị loại trừ khỏi mục tiêu tối ưu hóa.
Việc tách biệt này giải quyết vấn đề "gán lỗi/công trạng" (credit assignment problem). Trong tối ưu hóa đồng thời từ đầu đến cuối, một câu trả lời cuối cùng đúng có thể do bộ điều phối phân rã tốt, hoặc do một agent phụ gặp may. Bằng cách đóng băng các agent phụ và coi đầu ra của chúng như các quan sát từ môi trường, chỉ có logic điều phối của bộ điều phối được tối ưu hóa.
Kimi còn giới thiệu khái niệm "critical steps" (bước tới hạn) để đo lường chi phí tính toán trong môi trường song song, tương tự như đường tới hạn (critical path) trong đồ thị tính toán. Thay vì đếm tổng số bước của tất cả các agent, "critical steps" đo chuỗi thực thi dài nhất. Đối với mỗi giai đoạn, chi phí là số bước tối đa trong số tất cả các agent phụ song song. Tổng số "critical steps" là tổng của các giá trị tối đa này. Điều này khuyến khích bộ điều phối cân bằng công việc giữa các agent phụ (giảm nhánh dài nhất) thay vì chỉ tối đa hóa tính đồng thời.

Phần thưởng PARL (PARL Reward)

Việc huấn luyện một bộ điều phối song song đáng tin cậy đòi hỏi thiết kế phần thưởng khắt khe. Phần thưởng PARL gồm ba thành phần:
  • Phần thưởng hiệu suất (r perf): Nhiệm vụ có thành công không? Đây là tín hiệu chính.
  • Phần thưởng song song (r parallel): Khuyến khích khởi tạo các agent phụ để tránh tình trạng "sụp đổ tuần tự" (serial collapse) – một dạng tối ưu cục bộ nơi bộ điều phối mặc định chỉ chạy đơn agent và không bao giờ khám phá các chiến lược song song.
  • Phần thưởng hoàn thành (r finish ): Thưởng cho các nhiệm vụ phụ đã hoàn thành để ngăn chặn "song song giả tạo" (spurious parallelism) – một hành vi trục lợi phần thưởng (reward-hacking) khi bộ điều phối đẻ ra hàng loạt agent phụ mà không phân rã nhiệm vụ thực chất, chỉ để "ăn" điểm r parallel.
Các hệ số phần thưởng phụ trợ này sẽ được giảm dần về 0 trong quá trình huấn luyện, để chính sách (policy) cuối cùng chỉ tập trung tối ưu cho hiệu suất.

Cách thức hoạt động khi thực thi (Inference)

Khi chạy thực tế, mô hình nhận nhiệm vụ và quyết định xem có nên song song hóa hay không:
  1. Bộ điều phối phân tích nhiệm vụ và xác định cấu trúc các nhiệm vụ phụ.
  2. Nó tạo ra các agent phụ với chỉ dẫn cụ thể bằng công cụ create_subagent.
  3. Nó giao việc cho các agent phụ bằng assign_task một cách song song. Các agent phụ thực thi đồng thời với các cửa sổ ngữ cảnh độc lập.
  4. Bộ điều phối thu thập kết quả và tổng hợp câu trả lời cuối cùng hoặc lặp lại quy trình.
Quyết định song song hóa không được lập trình cứng. Với các tác vụ đơn giản, mô hình làm việc tuần tự. Với các nhiệm vụ nghiên cứu đa nguồn phức tạp, nó sẽ kích hoạt nhiều agent song song. Dữ liệu huấn luyện khuyến khích điều này: các câu lệnh giả lập nhấn mạnh vào "tìm kiếm rộng" (nhiều nguồn tin độc lập) hoặc "tìm kiếm sâu" (nhiều nhánh suy luận cần tổng hợp sau). Các câu lệnh không trực tiếp yêu cầu mô hình song song hóa; chúng tạo ra các tình huống mà ở đó song song hóa mang lại lợi ích.
Agent Swarm giúp giảm độ trễ thực thi tới 4.5 lần đồng thời cải thiện độ chính xác. Trên BrowseComp, nó đạt 78.4% (so với 60.6% của đơn agent), vượt qua GPT-5.2 Pro (77.9%). Agent Swarm cũng đóng vai trò như một cơ chế quản lý ngữ cảnh chủ động: việc phân rã nhiệm vụ vào các ngữ cảnh agent phụ riêng biệt giúp tránh tình trạng tràn ngữ cảnh (context overflow) vốn thường làm hỏng các phiên làm việc tuần tự dài.

Quy trình huấn luyện mở rộng

Công thức RL của Kimi K2.5 còn vài thành phần đáng chú ý:
  • Phần thưởng kết quả dựa trên quy tắc (Rule-based): Cho các tác vụ có lời giải có thể kiểm chứng (suy luận, tác vụ agent).
  • Mô hình Phần thưởng Tạo sinh (GRMs): Cho các tác vụ mở. Đây không phải là giám khảo đúng/sai nhị phân mà là các bên đánh giá chi tiết theo tiêu chí chất lượng nội bộ (tính hữu ích, thẩm mỹ, tuân thủ chỉ dẫn). Việc sử dụng nhiều bộ tiêu chí GRM giúp giảm thiểu tình trạng trục lợi phần thưởng.
  • Tinh chỉnh lấy mẫu loại bỏ (RFT): Tạo ra một luồng dữ liệu tự cải thiện: các quỹ đạo RL thành công được trích xuất để làm dữ liệu SFT cho các giai đoạn huấn luyện tiếp theo.
  • Nút gạt hiệu suất token (Toggle): Thay đổi giữa các giai đoạn tối ưu ngân sách và mở rộng tiêu chuẩn, giúp cắt giảm 25-30% độ dài đầu ra mà gần như không làm giảm hiệu suất.

Cursor Composer 2: RL cho lập trình Agentic

Tài liệu: Báo cáo kỹ thuật Composer 2, Cải thiện Composer thông qua RL thời gian thực
Composer 2 là mô hình nội bộ của Cursor dành cho kỹ thuật phần mềm dạng agent. Nó có thể đọc/sửa file, chạy lệnh shell, tìm kiếm codebase và duyệt web với mục tiêu giải quyết các nhiệm vụ lập trình thực tế một cách tự chủ.

Môi trường cố định, sát với thực tế

Composer 2 được huấn luyện trong chính môi trường (harness) mà người dùng tương tác: cùng công cụ, cùng định dạng prompt, cùng hệ thống tin nhắn và ngữ cảnh file. Họ duy trì một bản sao (shadow deployment) của hệ thống backend Cursor trong khi huấn luyện để các hành vi của công cụ (như tìm kiếm ngữ nghĩa) hoạt động giống hệt như trên môi trường thực tế.
Các bài đo chuẩn (benchmark) công khai như SWE-bench thường sử dụng môi trường đơn giản hóa và các câu lệnh quá chi tiết. Yêu cầu của lập trình viên thực tế thường mơ hồ, lộn xộn và có nhiều giải pháp đúng. Việc huấn luyện trên các vấn đề thực tế giúp Composer 2 học được cách xử lý các tình huống thực tế này.
Họ cũng xây dựng CursorBench, một bộ đánh giá nội bộ gồm các tác vụ từ chính đội ngũ kỹ sư của họ. Các tác vụ trên CursorBench có trung vị là 181 dòng code thay đổi (so với 7-10 dòng trên SWE-bench) và các câu lệnh ngắn, mơ hồ hơn nhiều.

Công thức RL: Bốn thành phần

Cơ sở hạ tầng RL của Composer 2 gồm bốn dịch vụ tách biệt:
  1. Huấn luyện (Training): Hệ thống bất đồng bộ hoàn toàn xây dựng trên Ray và PyTorch.
  2. Môi trường (Environments): Mỗi kịch bản (rollout) chạy trong một máy ảo Firecracker riêng biệt (Anyrun), có khả năng chạy toàn bộ môi trường phát triển với trình duyệt và GUI.
  3. Thực thi (Inference): Hợp tác với Fireworks AI để thực thi RL. Việc đồng bộ hóa trọng số diễn ra ở mỗi bước huấn luyện thông qua tải lên S3 (nén delta), cho phép thực thi phân tán quy mô lớn.
  4. Đánh giá (Evaluations): Sử dụng các bản sao backend và client cố định để đảm bảo hành vi đánh giá khớp với những gì người dùng thấy.
Thuật toán chính là một biến thể gần với GRPO, áp dụng đơn kỷ nguyên (mỗi prompt chỉ huấn luyện một lần) với cập nhật toàn bộ tham số. Họ loại bỏ thuật ngữ chuẩn hóa độ dài từ GRPO tiêu chuẩn (vì nó gây ra thiên kiến về độ dài) và bỏ qua việc chuẩn hóa lợi thế theo độ lệch chuẩn để tránh khuếch đại nhiễu.
Cursor cũng huấn luyện thêm các lớp Dự đoán Đa Token (MTP) để giải mã suy đoán (speculative decoding). Các lớp này tự học cách dự đoán phân phối logit của đầu mô hình chính. Kết quả là tốc độ thực thi nhanh hơn 2-3 lần với sự sụt giảm chất lượng không đáng kể.

Tự tóm tắt cho các phiên làm việc dài (Self-Summarization)

Các nhiệm vụ lập trình thực tế có thể kéo dài rất lâu. Một agent có thể phải thực hiện hàng chục lần gọi công cụ, đọc nhiều file và lặp lại hàng trăm lượt hội thoại. Để giữ cho mô hình hoạt động hiệu quả trong một cửa sổ ngữ cảnh hữu hạn, Composer 2 sử dụng cơ chế tự tóm tắt: mỗi kịch bản (rollout) có thể bao gồm nhiều lần tạo nội dung được kết nối với nhau bằng các bản tóm tắt. Phần thưởng kết quả cuối cùng sẽ áp dụng cho tất cả các token trong chuỗi đó. Nhờ vậy, những bản tóm tắt tốt (giữ lại được thông tin quan trọng) sẽ được củng cố, trong khi những bản tóm tắt kém (làm mất ngữ cảnh then chốt) sẽ bị hạ trọng số.
Mô hình học cách quyết định khi nào và tóm tắt như thế nào như một phần tự nhiên của quá trình huấn luyện RL. Với các nhiệm vụ khó, nó thường tóm tắt nhiều lần.

RL thời gian thực: Học từ lưu lượng thực tế (Production Traffic)

Bên cạnh RL mô phỏng, Cursor còn chạy cái mà họ gọi là RL thời gian thực, lấy các token thực tế từ quá trình thực thi trên môi trường sản xuất và trích xuất tín hiệu huấn luyện từ tương tác của người dùng. Chu kỳ hoạt động như sau:
  1. Thu thập hàng tỷ token từ tương tác của người dùng với checkpoint hiện tại.
  2. Chắt lọc phản hồi của người dùng thành các tín hiệu phần thưởng (ví dụ: người dùng có thực hiện các thay đổi tiếp theo không, họ có hài lòng không...).
  3. Huấn luyện trên các tín hiệu này và tạo ra một checkpoint mới đã được cập nhật.
  4. Chạy checkpoint qua CursorBench để kiểm tra xem có bị lỗi lùi (regression) không.
Nếu vượt qua, tiến hành triển khai.
Toàn bộ vòng lặp này mất khoảng năm giờ, vì vậy họ có thể cập nhật checkpoint cải tiến nhiều lần trong ngày. Việc giữ vòng lặp nhanh giúp dữ liệu gần như là "on-policy" (sát với chính sách hiện tại): mô hình tạo ra dữ liệu cũng chính là mô hình đang được huấn luyện.

Chroma Context-1: Agent tìm kiếm tự chỉnh sửa ngữ cảnh

Bài báo: Context-1: Huấn luyện một Agent tìm kiếm tự chỉnh sửa
Context-1 là một mô hình tìm kiếm dạng agent với 20 tỷ tham số, được huấn luyện để làm tốt một việc duy nhất: tìm kiếm tài liệu. Nó không trả lời câu hỏi, mà trả về một tập hợp các tài liệu bổ trợ đã được xếp hạng cho một mô hình suy luận ở bước sau. Cốt lõi của sự đổi mới này là ngữ cảnh tự chỉnh sửa (self-editing context). Mô hình học cách chủ động loại bỏ các tài liệu đã truy xuất không còn liên quan, giải phóng không gian ngữ cảnh để tiếp tục khám phá.

Quy trình dữ liệu giả lập (Synthetic Data)

Các nhiệm vụ tìm kiếm dạng agent trong thế giới thực rất khó thu thập ở quy mô lớn, vì bạn cần các truy vấn đa bước (multi-hop) với các tập tài liệu chuẩn đã biết trước. Chroma đã xây dựng một quy trình tạo dữ liệu giả lập trên bốn lĩnh vực: web, tài chính (hồ sơ SEC), pháp lý (bằng sáng chế USPTO) và email (file Epstein + Enron).
Mỗi nhiệm vụ tuân theo cùng một cấu trúc:
  • Thu thập các tài liệu bổ trợ với các sự kiện độc nhất.
  • Tạo ra các manh mối gây nhiễu (tham chiếu gián tiếp đến sự kiện) và một câu hỏi.
  • Xác minh: Trích xuất các trích dẫn nguyên văn từ tài liệu và kiểm tra xem chúng có thực sự xuất hiện trong văn bản nguồn không.
  • Thu thập các tài liệu gây nhiễu (distractors): các tài liệu khớp với một số tiêu chí nhưng dẫn đến câu trả lời khác.
Bước xác minh rất quan trọng vì câu hỏi "tài liệu này có liên quan không?" thường không đáng tin cậy với LLM. Thay vào đó, họ sử dụng quy trình dựa trên trích xuất: LLM trích xuất các câu trích dẫn khớp nhau từ cả tài liệu và manh mối, sau đó một bước kiểm tra xác định sẽ xác minh xem các câu đó có thực sự tồn tại trong nguồn không. Cách này đạt được độ chính xác >80% so với nhãn do con người đánh giá.

Hệ thống điều phối Agent (Agent Harness)

Context-1 hoạt động với bốn công cụ:
  1. search_corpus(query): tìm kiếm lai (hybrid) BM25 + tìm kiếm dày đặc (dense) với sự kết hợp RRF và tái xếp hạng.
  2. grep_corpus(pattern): tìm kiếm bằng biểu thức chính quy (regex).
  3. read_document(doc_id): đọc các đoạn (chunk) cụ thể.
  4. prune_chunks(chunk_ids): xóa các đoạn không liên quan khỏi ngữ cảnh.
Hệ thống bắt buộc một ngân sách token cố định (ví dụ: 32k token). Sau mỗi lượt, mức sử dụng hiện tại sẽ được hiển thị: [Token usage: 14,203/32,768]. Vượt qua ngưỡng mềm, hệ thống sẽ gợi ý cắt tỉa. Vượt qua ngưỡng cứng, tất cả các công cụ ngoại trừ prune_chunks sẽ bị chặn; mô hình buộc phải cắt tỉa hoặc kết thúc.

Huấn luyện: SFT Warmup + RL

Quá trình huấn luyện diễn ra qua hai giai đoạn:
  1. SFT Warmup: Tạo các quỹ đạo sử dụng Kimi K2.5 làm backend, sau đó lọc theo chất lượng độ phủ (recall). Các quỹ đạo có độ phủ cao được giữ lại toàn bộ.
  2. RL với CISPO: Huấn luyện hoàn toàn on-policy bằng CISPO (một biến thể của GRPO). 1024 quỹ đạo mỗi bước.

Phần thưởng được xây dựng kỹ lưỡng:

  1. Kết quả: Điểm F-beta với beta được đặt cao (ưu tiên độ phủ - recall gấp 16 lần độ chính xác - precision). Điều này phản ánh vai trò của Context-1: bỏ lỡ một tài liệu còn tệ hơn là đưa vào một tài liệu không liên quan.
  2. Quá trình: Độ phủ quỹ đạo. Ghi nhận công trạng cho agent nếu nó tìm thấy tài liệu liên quan trong quá trình tìm kiếm, ngay cả khi tài liệu đó sau đó bị cắt tỉa.
  3. Hình phạt: Phạt việc cắt tỉa lặp đi lặp lại nhiều lần liên tiếp hoặc các vòng lặp tìm kiếm không đem lại giá trị thêm.

Các chủ đề thống nhất

  • Huấn luyện tại nơi triển khai: Cả ba đội ngũ đều đầu tư mạnh mẽ để môi trường huấn luyện khớp với môi trường thực tế. Điều này giảm thiểu khoảng cách giữa hiệu suất khi huấn luyện và hiệu suất thực tế.
  • Quản lý ngữ cảnh là vấn đề ưu tiên hàng đầu: Ngữ cảnh của agent tăng dần theo thời gian. Cursor dùng tự tóm tắt, Kimi phân mảnh ngữ cảnh qua các agent phụ, và Chroma dạy mô hình loại bỏ các đoạn không liên quan.
  • Thiết kế phần thưởng là một quá trình lặp lại: Mọi đội ngũ đều phát hiện và sửa lỗi "trục lợi phần thưởng" (reward hacking). Mỗi khi mô hình có hành vi biến tướng, họ quan sát, hiểu động cơ và thêm vào một phần thưởng hoặc hình phạt mục tiêu.
  • Các bài đo chuẩn công khai là không đủ: Nếu bạn đang xây dựng một mô hình chuyên biệt (vertical model), bạn cần một bộ đánh giá chuyên biệt.
Mô hình nhỏ, huấn luyện chuyên biệt có thể cạnh tranh với các mô hình hàng đầu: Mô hình 20B của Chroma đạt hiệu suất tìm kiếm tương đương các LLM khổng lồ với chi phí thấp hơn và tốc độ nhanh gấp 10 lần. Việc huấn luyện RL chuyên biệt cho từng lĩnh vực giúp xóa nhòa khoảng cách về số lượng tham số.

Tài nguyên

Kimi K2.5: Bài báo, Trọng số mô hình
Cursor Composer 2: Bài báo, Blog về RL thời gian thực
Chroma Context-1: Báo cáo kỹ thuật, Trọng số mô hình, Mã nguồn tạo dữ liệu
Nguồn bài viết từ Tác giả Phil Schmid