Ivan Nikitin, Tổng giám đốc kiêm đồng sáng lập Fortytwo – Loạt bài phỏng vấn

Ivan Nikitin là Tổng giám đốc kiêm đồng sáng lập Fortytwo, nơi ông đang phát triển công nghệ suy luận bầy đàn, kết hợp nhiều mô hình AI để cùng lập luận và đánh giá công việc của nhau. Ông có kinh nghiệm trong lĩnh vực trò chơi, AI hội thoại, AI tạo sinh và các hệ thống tương tác tại Temporal và Sensorium. Năm 2011, ông đồng sáng lập Temporal cùng Vlad Larin, hiện là đồng sáng lập kiêm Giám đốc công nghệ của Fortytwo, qua đó tích lũy kinh nghiệm xây dựng các quần thể tác nhân không ngừng phát triển và những hệ thống kết hợp các mô hình chuyên biệt.

Fortytwo xây dựng hạ tầng AI cho phép các mô hình cộng tác trong quá trình suy luận. Fortytwo Engine sử dụng Swarm Decoder để định hướng một tiến trình lập luận chung khi tiến trình đó diễn ra, nhằm nâng cao độ chính xác và giảm việc tạo token không cần thiết trong các tác vụ kéo dài. Công ty cung cấp API cho nhà phát triển thông qua Fortytwo Engine và giải pháp triển khai tại chỗ thông qua Fortytwo Harbor.

Trước khi đồng sáng lập Fortytwo, ông đã dành nhiều năm xây dựng các sản phẩm xoay quanh AI hội thoại, AI tạo sinh và hệ thống tương tác tại Sensorium và Temporal. Những trải nghiệm đó đã định hình quan điểm của ông như thế nào về những hạn chế của từng mô hình ngôn ngữ lớn riêng lẻ, và cuối cùng dẫn ông đến cách tiếp cận dựa trên bầy đàn mà Fortytwo theo đuổi ra sao?

Một bộ phận lớn trong nhóm chúng tôi, trong đó có cả tôi, đến với AI thông qua trò chơi. Trò chơi là cái nôi của điện toán cá nhân và AI hiện đại: chính trò chơi là lý do GPU ra đời, còn việc chơi trò chơi là môi trường thử nghiệm nghiêm túc đầu tiên cho học tăng cường. Thế giới trò chơi tạo ra một môi trường thực tiễn để xây dựng các tác nhân có khả năng học hỏi, thích nghi và cạnh tranh. Tại Temporal, công ty tôi đồng sáng lập năm 2011 cùng Vlad Larin, hiện là đồng sáng lập kiêm Giám đốc công nghệ của Fortytwo, chúng tôi bắt đầu với trí tuệ không ngừng phát triển: các quần thể tác nhân cạnh tranh dưới áp lực chọn lọc. Chúng tôi muốn tìm hiểu cách một quần thể có thể đạt được nhiều hơn một tác nhân riêng lẻ, với điều kiện có cơ chế phù hợp để nhận diện và phát huy những đóng góp mạnh nhất của quần thể. Chọn lọc và đánh giá trở thành trọng tâm trong cách chúng tôi nhìn nhận trí tuệ.

Khi các mô hình transformer xuất hiện, chúng tôi mở rộng sang lĩnh vực AI hội thoại và xây dựng một nền tảng gồm các nhân vật được điều khiển bằng AI, có thể tham gia những cuộc trò chuyện cởi mở, không theo kịch bản, với trí nhớ và cá tính riêng. Việc này diễn ra khoảng hai năm trước ChatGPT, khi các mô hình chúng tôi sử dụng chỉ có cửa sổ ngữ cảnh từ 512 đến 1.024 token. Khi ấy, không thể trông đợi một mô hình ngôn ngữ đời đầu đáp ứng ổn định mọi yêu cầu khác nhau của trải nghiệm đó. Chúng tôi phải xây dựng một quy trình xử lý tùy chỉnh gồm các mô hình chuyên biệt, mỗi mô hình đảm nhận một nhiệm vụ hẹp hơn, cùng với cơ chế kết hợp những đóng góp của chúng. Việc xếp hạng và chọn lọc câu trả lời trở thành yếu tố thiết yếu để toàn bộ trải nghiệm hoạt động hiệu quả. Qua đó, chúng tôi nhận ra rằng có thể tạo ra năng lực lớn đến mức nào bằng cách kết hợp các mô hình còn hạn chế thành một hệ thống được thiết kế tốt.

Bài học còn lại là về hiệu quả. Chúng tôi nhận thấy có thể huấn luyện và cung cấp mô hình chuyên biệt cho các tác vụ được xác định rõ ràng một cách hiệu quả hơn, nhờ đó đạt được nhiều kết quả hơn với năng lực tính toán hạn chế. Tuy nhiên, mở rộng quy mô suy luận vẫn là một thách thức: một mặt là giới hạn sử dụng API, mặt khác là chi phí tự lưu trữ ở quy mô lớn. Khi không có khả năng tiếp cận năng lực tính toán tiên tiến nhất, chúng tôi phải cân nhắc kỹ cách khai thác tối đa nguồn lực sẵn có. Fortytwo kết hợp những bài học đó trong tầm nhìn về suy luận bầy đàn: nhiều mô hình, hoặc nhiều phiên bản của cùng một mô hình, cùng tham gia lập luận và đánh giá công việc của các mô hình khác. Nhờ vậy, cả hệ thống đạt độ chính xác cao hơn bất kỳ thành viên nào.

Fortytwo Engine sử dụng một số mô hình có trọng số mở để định hướng một tiến trình lập luận duy nhất và kiểm tra lẫn nhau trong khi câu trả lời được tạo ra. Cách tiếp cận này khác gì so với các hệ thống đa tác nhân thông thường, các tổ hợp mô hình, hay cách đơn giản là chạy nhiều mô hình rồi chọn câu trả lời tốt nhất sau đó?

Điểm khác biệt then chốt là suy luận bầy đàn được tích hợp trực tiếp vào công cụ suy luận do chúng tôi phát triển. Chúng tôi gọi cơ chế này là Swarm Decoder: nhiều mô hình tham gia liên tục định hình một mạch lập luận duy nhất trong quá trình tạo ra mạch đó. Việc đánh giá và định hướng diễn ra ngay trong tiến trình này, cho phép các mô hình tác động đến hướng đi của nó trước khi câu trả lời hoàn tất.

Các phương án khác hoạt động theo cách khác. Với phương pháp tổ hợp ở cấp câu trả lời, các mô hình tạo ra những câu trả lời riêng biệt, sau đó các câu trả lời này được xếp hạng, chọn lọc hoặc kết hợp. Kiến trúc ban đầu của Fortytwo, được triển khai năm 2025, xếp hạng các câu trả lời đã hoàn tất dựa trên đánh giá của các mô hình ngang hàng. Cách này cải thiện đáng kể độ chính xác của câu trả lời, nhưng phải đánh đổi bằng độ trễ tăng thêm và chi phí tính toán cao hơn. Nhiều hệ thống đa tác nhân thông thường phân chia công việc giữa các tác nhân, sử dụng một bộ điều phối và các thông điệp bằng ngôn ngữ tự nhiên để quản lý phần việc của từng tác nhân. Việc chuyển giao đó có thể đòi hỏi thêm các lượt suy luận, lặp lại ngữ cảnh và đưa ra quyết định về việc chuyển thông tin nào từ tác nhân này sang tác nhân khác. Trong Swarm Decoder không có bước chuyển giao: các mô hình tham gia cùng xử lý một mạch lập luận duy nhất và chỉ trao đổi nhận định về hướng đi nào tốt hơn.

Swarm Decoder được thiết kế để phát hiện những giả định thiếu vững chắc ngay trong quá trình tạo sinh, trước khi tốn nhiều công sức xây dựng dựa trên chúng. Mục tiêu là giảm sai sót, việc phải quay lại và lượng nội dung tạo ra không cần thiết; lợi ích về hiệu quả xuất hiện khi việc kiểm tra giúp ngăn chặn được nhiều công việc hơn mức nó làm phát sinh. Vì vậy, độ trễ không tăng: quá trình chạy đi theo một lộ trình trực tiếp hơn, nhờ đó Engine hoàn thành tác vụ nhanh hơn so với khi chỉ dùng riêng mô hình đó, đồng thời sử dụng tổng số token ít hơn, tính cả token của mọi mô hình tham gia.

Ông đã nhấn mạnh rằng hiện tượng trôi lệch của mô hình trong các tác vụ kéo dài là một vấn đề lớn. Nguyên nhân thực sự gây ra hiện tượng này là gì, và nó biểu hiện ra sao trong các ứng dụng thực tế như kỹ thuật phần mềm, nghiên cứu hay tác nhân AI tự hành?

Hiện tượng trôi lệch xảy ra khi ngữ cảnh của mô hình dần không còn tập trung vào tác vụ. Trong một phiên chạy kéo dài, ngữ cảnh dần bị lấp đầy bởi đầu ra của chính mô hình, kết quả từ công cụ, nội dung tệp và những lần thử lại. Chỉ dẫn ban đầu ngày càng chiếm tỷ trọng nhỏ hơn trong những gì mô hình chú ý đến; những lỗi trước đó của chính mô hình cũng trở thành một phần của dữ liệu đầu vào mà nó dùng để suy luận, khiến lỗi chồng chất thay vì triệt tiêu lẫn nhau. Thêm vào đó, các mô hình suy luận hiện nay được huấn luyện bằng học tăng cường để hoàn thành tác vụ, và chúng học được những lối tắt trông có vẻ như đã hoàn thành: bỏ qua lệnh gọi công cụ, tuyên bố thành công, hoặc tóm tắt thay vì kiểm tra. Chúng tôi gọi đó là sự lười biếng, và các mô hình tiên phong cũng mắc phải tình trạng này nhiều như các mô hình có trọng số mở. Nguyên nhân cốt lõi là một mô hình đơn lẻ không có cơ chế kiểm tra độc lập từ bên ngoài. Nó tự chấm điểm công việc của mình, trong khi các mô hình không giỏi tự đánh giá chính xác.

Trong kỹ thuật phần mềm, hiện tượng này thể hiện ở việc tác nhân sửa lỗi mà ông mô tả nhưng lại vi phạm ràng buộc ông nêu trong thông điệp đầu tiên, viết một bài kiểm thử dễ dàng vượt qua, hoặc đọc cùng một tệp đến bốn lần vì quên mất mình đã tìm hiểu được gì. Trong nghiên cứu, đó là một phiên chạy kéo dài dần chuyển từ câu hỏi ông đặt ra sang câu hỏi dễ trả lời nhất, rồi đưa ra một bản tóm tắt chung chung. Với các tác nhân tự hành, đây là phiên bản tốn kém: đi chệch hướng, gọi công cụ lặp đi lặp lại, quay lại các bước trước và tiêu tốn số token gấp nhiều lần mức cần thiết cho tác vụ.

Chúng ta có thể định lượng điều này. Chúng tôi cho Qwen 3.8 27B thực hiện 450 tác vụ DeepSWE — các công việc kỹ thuật phần mềm thực tế, sử dụng công cụ trong ngữ cảnh dài — một lần chạy độc lập và một lần chạy qua Fortytwo Engine. Khi chạy độc lập, mô hình dùng trung bình 16,3 triệu token mỗi lần chạy, tổng cộng 7,4 tỷ token. Khi chạy qua Engine, cùng mô hình đó dùng trung bình 12,3 triệu token mỗi lần chạy, tổng cộng 5,6 tỷ token, ít hơn 24,7%, đồng thời giải được nhiều tác vụ hơn: 47,8% so với 42,2%. Mô hình không hề thay đổi. Bốn triệu token mỗi lần chạy được tiết kiệm chính là phần trôi lệch: việc đọc lại, thử lại và quay lại các bước trước mà một mô hình đơn lẻ phải làm vì không có ai phát hiện những bước đi sai trong lúc nó thực hiện. Bầy mô hình phát hiện được các bước sai đó, nên không cần phải trả chi phí cho chúng.

Trước đây, Fortytwo để các mô hình đánh giá câu trả lời đã hoàn tất của nhau, còn kiến trúc hiện tại cho phép chúng tác động đến quá trình suy luận ngay trong lúc quá trình đó đang diễn ra. Ông đã rút ra bài học gì từ cách tiếp cận trước đây, và vì sao việc định hướng theo thời gian thực hiệu quả hơn?

Kiến trúc năm 2025 đã chứng minh rằng chúng ta có thể đạt được năng lực ở cấp độ mô hình tiên phong bằng cách mở rộng theo chiều ngang — bổ sung thêm nhiều mô hình tham gia thay vì chạy đua tìm mô hình lớn nhất. Một bầy mô hình có trọng số mở, xếp hạng câu trả lời hoàn chỉnh của nhau, đã vượt qua mô hình đơn lẻ tốt nhất trong bầy tới 17 điểm phần trăm; đồng thời, bầy mô hình này hoạt động vững vàng trong những tình huống mà một mô hình đơn lẻ không thể xử lý tốt: câu lệnh nhiễu, chỉ dẫn bị chèn vào và đa số câu trả lời sai.

Điều kiến trúc đó không làm được là can thiệp. Việc xếp hạng các câu trả lời đã hoàn tất phù hợp với một câu hỏi đơn lẻ, nhưng quá trình chạy của tác nhân gồm hàng trăm bước, xen kẽ các lần gọi công cụ, và những sai lầm mang tính quyết định thường xảy ra từ sớm rồi chồng chất. Đánh giá ở cuối đồng nghĩa với việc mọi mô hình đều đã phải gánh toàn bộ chi phí token, còn bộ đánh giá chỉ có thể chọn trong số những tiến trình đã rẽ theo các hướng khác nhau. Cách này cũng khiến chi phí của bầy mô hình tăng theo số lượng mô hình — điều phù hợp với một câu hỏi khó duy nhất nhưng không phù hợp với một tác nhân lập trình.

Việc định hướng theo thời gian thực giải quyết cả hai vấn đề. Xếp hạng liên tục tạo ra áp lực chọn lọc xuyên suốt quá trình chạy, nhờ đó một bước đi sai được điều chỉnh ngay khi xuất hiện, trước khi lan rộng. Bầy mô hình không bao giờ chấp nhận một lần thử qua loa, bởi trong bảng xếp hạng, cách làm qua loa sẽ thua cách làm cẩn thận hơn. Vì vậy, cùng một cơ chế giờ đây giúp chúng tôi vừa đạt độ chính xác cao hơn, vừa dùng ít token hơn.

Trong các thử nghiệm với Qwen 3.8 27B, Fortytwo cho biết đã dùng ít hơn 24,7% số token trong 450 lượt chạy DeepSWE, đồng thời cải thiện kết quả trên sáu bộ chuẩn đánh giá. Điều gì đang diễn ra bên trong bầy mô hình giúp cải thiện hiệu suất trong khi giảm mức tiêu thụ token?

Việc kiểm tra của bầy mô hình có một khoản chi phí nhỏ và cố định; phần chi phí tiết kiệm được nhờ ngăn chặn việc khắc phục sai sót lại tăng theo độ dài của tác vụ, bởi mỗi bước đi sai không được sửa sẽ kéo theo chi phí của mọi thứ được xây dựng dựa trên nó. Vì vậy, tác vụ càng dài thì càng có thể tiết kiệm nhiều, và DeepSWE nằm ở phía có các tác vụ dài nhất trong phổ này; đó là lý do mức tiết kiệm đạt gần một phần tư tổng số token.

Về độ chính xác, vấn đề nằm ở trí tuệ phát triển không đồng đều. Các mô hình thường tiến bộ không đồng đều: có thể suy luận ở trình độ tiến sĩ trong lĩnh vực này nhưng lại đưa ra những điều hoàn toàn vô nghĩa ở lĩnh vực khác, bởi tinh chỉnh, học tăng cường và các phương pháp hậu huấn luyện khác giúp mô hình cải thiện trên dữ liệu dùng để huấn luyện, trong khi mức tiến bộ giảm dần khi các tác vụ thực tế khác xa dữ liệu đó. Swarm Decoder không can thiệp vào mô hình. Công cụ này cải thiện chính quá trình suy luận một cách nhất quán, vì vậy sáu bộ chuẩn đánh giá không phải là sáu lĩnh vực mà chúng tôi tối ưu hóa riêng; đó là sáu nơi chúng tôi đo lường cùng một yếu tố. Nhìn chung, mô hình thông minh hơn và chú ý hơn; khi các mô hình khác kiểm tra từng bước, người dùng có cảm giác như mô hình đang dành nhiều công sức hơn hẳn cho tác vụ của mình. Đó cũng là lý do chúng tôi có thể định giá Engine theo mức phí trên mỗi token của mô hình nền: khách hàng không phải trả tiền cho ngân sách lớn hơn, mà trả tiền để đi đến câu trả lời đúng qua một lộ trình ngắn hơn.

Các nhà phát triển AI ngày càng quan tâm đến chi phí suy luận khi các mô hình suy luận tạo ra những chuỗi token dài hơn. Ông có nghĩ rằng cải thiện hiệu quả của chính quá trình suy luận về lâu dài có thể quan trọng ngang với việc làm cho từng mô hình nhỏ hơn, nhanh hơn hoặc rẻ hơn không?

Đúng vậy, và tôi cho rằng đây đã là đòn bẩy lớn hơn. Làm cho mô hình nhỏ hơn, nhanh hơn và rẻ hơn sẽ hạ giá mỗi token. Nhưng chẳng ai mua token. Họ mua một nhiệm vụ đã hoàn thành, và trong kỷ nguyên tác tử, số token cần cho mỗi nhiệm vụ đã tăng vọt: một mô hình suy luận có thể tiêu tốn hàng triệu token khi xử lý một nhiệm vụ lập trình thực tế, và một phần lớn trong số đó là do phải quay lại những bước đã làm. Giảm 25% số token cho mỗi nhiệm vụ có giá trị đúng bằng việc giảm 25% giá, nhưng còn có thể cộng dồn với mọi cải tiến về phần cứng, lượng tử hóa và kernel; hơn nữa, chúng tôi có thể áp dụng cách này cho bất kỳ mô hình trọng số mở nào trên thị trường.

Ngành này có ba đòn bẩy. Mô hình tốt hơn, tức là huấn luyện, và việc này tốn kém. Token rẻ hơn, tức là phần cứng và vận hành dịch vụ; lĩnh vực này đang dần hội tụ vì ai cũng dùng cùng loại GPU. Và giảm số token cho mỗi nhiệm vụ, tức là cách vận hành suy luận; hướng này gần như chưa được khám phá. Cho đến nay, mở rộng quy mô đồng nghĩa với mô hình lớn hơn và chuỗi suy nghĩ dài hơn, cả hai đều đòi hỏi một mô hình thực hiện mọi việc trong cùng một tiến trình. Chúng tôi cho rằng trục phát triển tiếp theo sẽ mang tính tập thể: nhiều mô hình cùng suy luận, phân bổ khả năng đánh giá giữa chúng, nhờ đó bản thân tiến trình sẽ ngắn hơn và đáng tin cậy hơn. Đây là một kiểu mở rộng quy mô khác với việc tăng số lượng tham số hay năng lực tính toán tại thời điểm kiểm thử, và đó là hướng chúng tôi đặt cược vào. Chúng tôi gọi cách tiếp cận này là ưu tiên các mô hình ngang hàng thay vì tham số.

Fortytwo Engine tương thích với OpenAI API và vận hành các mô hình trọng số mở. Khả năng tương thích với các hệ thống phát triển AI hiện có quan trọng đến mức nào, và các nhà phát triển có thể chuyển một ứng dụng từ API thông thường chỉ dùng một mô hình sang kiến trúc bầy đàn dễ dàng ra sao?

Khả năng tương thích là yếu tố thiết yếu. Hệ sinh thái tác tử—bao gồm các tác tử lập trình, bộ công cụ điều phối, framework và công cụ đánh giá—được xây dựng dựa trên cấu trúc OpenAI API. Vì vậy, với các nhà phát triển sử dụng Fortytwo Engine, việc chuyển đổi cũng giống như chuyển từ nhà cung cấp dịch vụ suy luận này sang nhà cung cấp khác: với một ứng dụng, tác tử, bộ công cụ điều phối hoặc dịch vụ tương thích, thông thường chỉ cần thay đổi cấu hình một lần: điểm cuối, khóa API và lựa chọn mô hình.

Điều thay đổi là cách vận hành, chứ không phải cách tích hợp. Khác biệt thể hiện rõ trong các lượt chạy tác tử kéo dài, khi lượng token tiêu thụ và độ chính xác ngay lần đầu quyết định chi phí: cùng một mô hình nhưng khi chạy qua Engine sẽ hoàn thành nhanh hơn, dùng ít token hơn và xử lý đúng nhiều nhiệm vụ hơn. Tôi khuyên nên xem đây như mọi lần đổi mô hình khác: chạy bài đánh giá mà bạn vốn dùng cho tác tử của mình, so sánh số token cho mỗi nhiệm vụ và tỷ lệ thành công, rồi giữ lại lựa chọn nào cho kết quả tốt hơn.

Cảm ơn ông về cuộc phỏng vấn tuyệt vời. Độc giả muốn tìm hiểu về suy luận bầy đàn và cách đánh giá ngang hàng có thể cải thiện hiệu quả suy luận hãy truy cập Fortytwo.