- CoRT (Chain of Recursive Thoughts) là một dự án theo phương thức trong đó mô hình AI không chốt câu trả lời ngay một lần, mà tự tạo và đánh giá nhiều phương án qua nhiều lượt rồi chọn câu trả lời cuối cùng
- Luồng hoạt động gồm tạo phản hồi ban đầu, xác định số vòng suy nghĩ cần thiết, tạo 3 phương án cho mỗi vòng, đánh giá toàn bộ phản hồi và chọn phản hồi tốt nhất
- Khi thử nghiệm với Mistral 3.1 24B, dự án cho biết chất lượng phản hồi được cải thiện đáng kể so với các mô hình nhỏ, đặc biệt trong tác vụ lập trình
- Web UI hiện vẫn ở giai đoạn phát triển ban đầu; trên Windows dùng
start_recthink.bat, còn trên Linux dùng luồng chạy pip, npm, recthink_web.py
- Các thành phần cốt lõi gồm tự đánh giá, tạo phương án cạnh tranh, cải thiện lặp lại và độ sâu suy nghĩ động; dự án được phát hành theo giấy phép MIT
CoRT làm gì
- CoRT là phương thức khiến mô hình AI xem xét đệ quy phản hồi của chính mình, tạo các phương án thay thế rồi chọn câu trả lời tốt nhất
- Mục tiêu là buộc AI không dùng nguyên câu trả lời đã đưa ra một lần, mà lặp lại quá trình tự nghi ngờ và thử lại
- README mô tả điều này như một “AI battle royale”, trong đó phản hồi sống sót giữa nhiều câu trả lời ứng viên được dùng làm kết quả cuối cùng
Cách tạo phản hồi
- Luồng xử lý gồm các bước sau
- AI tạo phản hồi ban đầu
- AI xác định số vòng suy nghĩ cần thiết
- Ở mỗi vòng, tạo 3 phản hồi thay thế
- Đánh giá tất cả phản hồi
- Chọn phản hồi tốt nhất
- Phản hồi cuối cùng là kết quả được chọn sau quá trình tạo và đánh giá phương án thay thế lặp đi lặp lại
Thử nghiệm và ví dụ
- Đã thử nghiệm bằng cách áp dụng CoRT cho Mistral 3.1 24B
- README cho biết phiên bản có áp dụng CoRT cho kết quả tốt hơn phiên bản không áp dụng, đặc biệt trong tác vụ lập trình
- Ví dụ bao gồm hình ảnh kết quả của Mistral 3.1 24B + CoRT và Mistral 3.1 24B non CoRT
Cách chạy
- Web UI hiện vẫn ở giai đoạn phát triển ban đầu
- Trên Windows, hướng dẫn là mở
start_recthink.bat và chờ cài đặt xong các phụ thuộc
- Quy trình chạy trên Linux như sau
pip install -r requirements.txt
cd frontend && npm install
cd ..
python ./recthink_web.py
- Chạy frontend trong một shell mới
cd frontend
npm start
Chạy trực tiếp và các thành phần
- Để chạy trực tiếp, cài đặt các phụ thuộc, thiết lập
OPENROUTER_API_KEY, rồi chạy script Python
pip install -r requirements.txt
export OPENROUTER_API_KEY="your-key-here"
python recursive-thinking-ai.py
- Bốn yếu tố cốt lõi mà dự án nhấn mạnh là
-
Self-evaluation
- Tạo phương án thay thế mang tính cạnh tranh
- Tinh chỉnh lặp lại
- Độ sâu suy nghĩ động
- Có thể đóng góp qua PR, và giấy phép là MIT
1 bình luận
Ý kiến trên Hacker News
Thường thấy xu hướng cho rằng nếu cho nhiều mô hình đối đầu nhau hoặc chạy thành bầy thì trí tuệ tập thể sẽ xuất hiện như phép màu, nhưng sau khi tự thử nghiệm và xem công trình của ASU/Microsoft Research, tôi đi đến một kết luận đơn giản hơn: LLM là bộ xác minh rất tệ cho các LLM khác
Trong bài thuyết trình “(How) Do LLMs Reason/Plan?” của Subbarao Kambhampati, GPT-4 tự tin tạo ra một chứng minh tô màu đồ thị có thể chứng minh là sai, cho đến khi một bộ giải SAT ký hiệu được đưa vào làm trọng tài https://www.youtube.com/watch?v=0u2hdSpNS2o
Bài báo của Stechly và cộng sự định lượng rằng khi để GPT-4 tự phê bình câu trả lời của mình, độ chính xác lại giảm; còn nếu gắn một bộ xác minh bên ngoài có tính sound thì hiệu năng tăng khoảng 30 điểm phần trăm trên nhiều tác vụ lập kế hoạch và giải đố https://arxiv.org/abs/2402.08115
Tức là với các mô hình tự hồi quy hiện nay, xác minh khó hơn sinh nội dung, và ta cần những bộ kiểm tra thực sự suy luận về thế giới, như compiler, linter, bộ giải SAT, hay dataset đáp án đúng
Vì vậy, cách chồng nhiều LLM lên nhau thường không giúp được mấy. Bài position paper “LLM-Modulo” cũng cho rằng mô hình tự hồi quy không thể tự xác minh hay tự lập kế hoạch dài hạn, mà nên được xem như một bộ sinh ý tưởng có recall cao rồi bọc lại bằng một bộ xác minh duy nhất và sound https://arxiv.org/abs/2402.01817
Khi tự kiểm thử, tôi thấy thay cuộc tranh luận giữa 5 mô hình bằng một mô hình mạnh duy nhất cộng với bộ xác minh cho kết quả ngang bằng hoặc tốt hơn, trong khi độ trễ và gánh nặng điều phối nhỏ hơn nhiều
Sách hoặc phim là ví dụ tốt: nói một nhân vật nông cạn thì dễ, nhưng tạo ra một nhân vật có chiều sâu và thú vị lại khó đáng kinh ngạc
Trong kỹ nghệ phần mềm cũng tương tự: một LLM được prompt tìm lỗ hổng bảo mật có thể chỉ ra các điểm có thể dễ bị tấn công trong mã được sinh ra
Nhưng nếu mong một LLM khác tìm lỗi suy luận trong chứng minh toán học, về cơ bản nó phải làm lại toàn bộ suy luận, nên tôi nghi ngờ liệu có cải thiện hiệu năng đáng kể hay không
Nó cũng đã ăn sâu vào việc đánh giá pipeline RAG trong các framework như LangChain hay LlamaIndex https://arxiv.org/abs/2411.15594
Tôi tò mò liệu cách để LLM tạo cả unit test cho đoạn mã nó sinh ra, rồi chạy toàn bộ cả các unit test sẵn có của ứng dụng thì sẽ ra sao
Nếu kiểm tra được mã có compile không và unit test có pass không, ta có thể có một mức xác minh có căn cứ nhất định, và AI có thể đọc kết quả test để sửa lỗi của chính nó
Huấn luyện trên dữ liệu ngữ liệu có thể tạo ra các bước nhảy ở quy mô một chữ số, nhưng huấn luyện trên dữ liệu tương tác có vòng lặp OODA, có thể quan sát và thích nghi, thì mạnh hơn nhiều
Nếu tôi đang làm AI, có lẽ tôi cũng sẽ làm như vậy. Tuy nhiên thực tế thì tôi đang làm BrowserBox
Generate-and-test (sinh-và-kiểm tra) đặc biệt hữu ích khi có một thuật toán kiểm tra đáng tin cậy, tương đối nhanh và tiết kiệm bộ nhớ, còn thuật toán sinh chính xác chỉ tạo đáp án đúng thì chậm hoặc tốn nhiều bộ nhớ
Ở đây, bộ sinh là LLM, còn bộ kiểm tra hay “bộ xác minh” là compiler, linter, bộ giải SAT, dataset đáp án đúng, v.v.
Generate-and-test cũng liên quan đến thử-và-sai, và thử-và-sai có lẽ đã tồn tại từ thời đồ đá cũ
Một cách thỉnh thoảng tôi dùng là trước hết để mô hình chat AI đưa ra đáp án cho vấn đề, rồi bắt nó viết thành báo cáo giải thích vì sao đáp án đó đúng sao cho cả người không biết bài toán ban đầu hay lĩnh vực kỹ thuật đó, hoặc cả AI, cũng có thể hiểu được
Sau đó, để một mô hình AI thứ hai không biết vấn đề chấm điểm báo cáo, yêu cầu những phần giải thích mà mô hình ban đầu chưa cung cấp hoặc viết báo cáo chỉ ra các điểm bất nhất trong logic
Trả báo cáo này về cho mô hình ban đầu, yêu cầu viết lại câu trả lời có phản ánh thông tin cần thiết hoặc các chỉnh sửa, rồi lặp lại cho đến khi mô hình thứ hai bị thuyết phục hoặc mô hình thứ nhất đã phản ánh mọi yêu cầu thay đổi
Cách này rất thô sơ, nhưng trong những lần tôi thử thì cho kết quả khá tốt
Kế hoạch cuối cùng thường cân bằng và được cân nhắc kỹ hơn nhiều
Điều thú vị là kỹ thuật này cũng hoạt động tốt khi tự áp dụng cho chính mình. Việc tìm lỗi trước khi xem lại kế hoạch thực sự có ích
Ví dụ, một cuộc tập trung vào kỹ thuật, một cuộc tập trung vào marketing, và một cuộc khác chứa ngữ cảnh liên quan đến mục tiêu cá nhân
Đưa cùng một câu hỏi vào các cuộc chat có ngữ cảnh khác nhau giống như nhìn cùng một vấn đề từ nhiều góc độ, và kết luận cũng có thể khác nhau khá nhiều tùy theo ngữ cảnh
Trông có vẻ là một ý tưởng khá hay, nhưng có lẽ sẽ làm lượng token sử dụng tăng mạnh
Ngoài ra, tôi cũng lo rằng nếu LLM dùng làm giám khảo ngay từ đầu không thể tạo ra câu trả lời đủ tốt, thì nó cũng có thể gặp khó khăn trong việc chấm điểm chính xác
Tôi muốn thử làm kiểu này ở quy mô lớn hơn, như một thượng viện tranh luận luôn bật
Thay vì trả lời prompt theo từng lần, ta đưa vào một danh sách công việc có thể có hạn chót, để thượng viện xử lý, chia thành các nhóm cho những tác vụ con, thách thức kết quả và đề xuất phương án
Xa hơn nữa, có thể tạo một cây nhà phân tích, trong đó nút cha chỉ đẩy đề xuất lên trên khi nó đánh giá rằng phân tích cấp dưới đặc biệt sâu sắc
Tôi chắc chắn đã thấy rằng việc chỉ đạo mô hình tiếp cận vấn đề từ một góc nhìn cụ thể có thể làm kết quả tốt lên hoặc tệ đi. Nếu tạo ra nhiều góc nhìn đa dạng cùng với phân tích phê phán về các kết quả đó, có thể đạt được kết quả ấn tượng
Cách này sẽ tạo ra số lượng token khổng lồ, nhưng chi phí trên mỗi token đang đi theo hướng khiến điều đó trở nên khả thi. Cũng có khả năng tạo một máy chủ IRC chuyên cho AI, nơi ai cũng có thể kết nối mô hình của mình vào và dùng như một phòng thảo luận chung
Sau khi mất thời gian thử rồi bị kẹt và quay lại, nó nhẹ nhàng nói “Đúng rồi, bạn tìm ra tốt lắm! Bạn gần xong rồi! Bước tiếp theo là X và Y”, rồi đưa ra cùng một hướng dẫn chi tiết như trước, chỉ thay đổi chút ít những phần như flag từng sai
Cảm giác như đang làm việc với một thực tập sinh quá nhiệt tình cứ ném việc ra mà không kiểm tra, và có vẻ sẽ khá hơn nhiều nếu đặt một bot thứ hai trước bot thứ nhất để hỏi “cậu thật sự chắc chứ?”
Tôi làm nó phỏng theo khái niệm cố vấn trong Civilization II, và nó hoạt động khá ổn, nhưng có phần bị hạn chế vì bị buộc vào một LLM duy nhất là Mistral
Và nó nặng đến mức như muốn đốt cháy máy tính của tôi
Sẽ rất thú vị xem nó tạo ra được gì nếu cho đủ thời gian và token
Một chiến lược đơn giản và hạn chế hơn nhiều mà tôi thường dùng là thêm vào cuối tin nhắn: “Trước khi trả lời, hãy suy nghĩ một lần trong thẻ, tự phê bình một lần trong thẻ, rồi cuối cùng viết câu trả lời cuối cùng”
Nó hoạt động khá tốt. Tương tự, chỉ cần nói “hãy tìm 5 vấn đề lớn nhất trong đề xuất” cũng ổn, nhưng nếu ép phải có 5 vấn đề thì đa phần nó sẽ tìm ra cái gì đó, dù không mấy liên quan
Bước 1 để nó lập kế hoạch, bước 2 để nó chỉ ra khiếm khuyết của kế hoạch, bước 3 để cập nhật kế hoạch có phản ánh các khiếm khuyết
Những câu hỏi khác tôi hay hỏi là “chúng ta đã bỏ sót điều gì?”, “các cân nhắc về hiệu năng, bảo mật, pháp lý, chi phí là gì?”
Cũng có thể lặp lại vài lần các prompt gợi mở kiểu “còn gì nữa không?”, đặc biệt tốt nếu hướng dẫn rõ các chủ đề cần cân nhắc. Mỗi lần kết thúc thì bắt nó cập nhật kế hoạch có phản ánh các cân nhắc đó
Hơi khác so với những gì tôi kỳ vọng từ tiêu đề. Tôi cứ tưởng nó sẽ là một quy trình đối lập rõ ràng
Tôi chưa trực tiếp thử cách này và cũng không biết nó có hoạt động không. Nhưng việc hỏi ChatGPT bằng các prompt riêng như “XYZ là đúng, hãy giải thích lý do” và “XYZ là sai, hãy giải thích lý do”, rồi xem bên nào thuyết phục hơn, thì có ích
https://github.com/evalstate/fast-agent
Tôi không hiểu vì sao lại có người nghĩ đây là thứ mới. Có lẽ nó cũng cho thấy tình trạng của HN
Bản thân cách tiếp cận này có vẻ tốt, nhưng tuyệt đối không được trực tiếp ám chỉ “bạn sai”. Thường thì nó sẽ chỉ mặc định rằng chính nó sai
Ngược lại, những lúc nó thực sự phản bác và tự bảo vệ mình theo kiểu này lại khá ấn tượng
Vì những thử nghiệm như thế này khá thú vị, tôi đang làm một trình biên tập đồ thị kiểu blueprint của Unreal Engine để mọi người có thể thiết kế các workflow như vậy
Prompt của người dùng đi vào một agent để tạo nỗ lực ban đầu, rồi lịch sử hội thoại đó được chuyển sang một “agent” khác có system prompt khác để đóng vai nhà phê bình nghiêm khắc, đưa tín hiệu đạt/không đạt, sau đó lặp cho đến khi nhà phê bình cho là đạt rồi mới xuất kết quả cho người dùng
Lý tưởng là một website nhỏ có thể gọi endpoint LLM của chính bạn và cho phép lưu, tải, chia sẻ đồ thị workflow
Mistral Small 3.1 và Gemma 3 có cảm giác như những mô hình đầu tiên chạy cục bộ mà có năng lực được một nửa, nhưng năng lực đó chỉ là hạt giống, và cần một framework để giữ chúng luôn đi đúng quỹ đạo
Nếu trong vòng lặp lặp lại, bạn cấp quyền chạy Python và bảo nó khám phá thế giới, nó sẽ bắt đầu tải xuống và đọc những thứ như tin tức
Ví dụ, nếu bảo GPT cư xử khó chịu, thì ở một mức nào đó có thể bắt chước trên GPT khả năng của Gemini trong việc chỉ ra những điều nhảm nhí hoặc suy nghĩ lỏng lẻo. Sự lịch sự dường như lọc bỏ rất nhiều thứ có giá trị
Nhưng kết quả trở nên khó chịu khi đọc. Gemini có vẻ đã giải quyết bằng cách xử lý việc này thành hai bước trong quá trình học và biến bước đầu thành “suy nghĩ” không công khai
Vì vậy, tôi nghĩ thứ cần thiết là một cách tiếp cận hai bước, trong đó đầu ra “khó chịu” kia được chỉnh lại cho dễ tiếp nhận hơn với con người. Làm việc theo kiểu đó quá một thời gian ngắn là khá mệt
Một UI chat nhóm có các tính cách LLM khác nhau cũng có vẻ rất giá trị. Định dạng đối tượng tin nhắn dường như đã tính đến nhiều người dùng và nhiều AI, chẳng hạn mỗi tin nhắn có tên, nhưng tôi vẫn chưa thấy UI như vậy
Hỗ trợ nhiều nhà cung cấp thì càng tốt. Vì mỗi bên có điểm mạnh khác nhau, nó giống như lấy thêm ý kiến thứ hai
consortium gửi cùng một prompt song song tới nhiều mô hình, rồi gửi tất cả phản hồi cho một mô hình trọng tài để đánh giá. Trọng tài quyết định có cần lặp thêm không
Cũng có thể ép lặp thêm cho đến khi đạt ngưỡng độ tin cậy hoặc số vòng lặp tối thiểu
Với PR tôi làm cho llm-openrouter, bạn có thể lưu alias mô hình gồm nhiều tùy chọn mô hình. Ví dụ có thể tạo một chuyên gia nghiên cứu trực tuyến như
llm openrouter save -m qwen3 -o online -o temperature 0, system "research prompt" --name qwen-researcherCó thể để thành viên khác trích xuất thực thể ở chế độ JSON, và thành viên khác nữa viết bản nháp mù. Trọng tài tổng hợp câu trả lời tốt bằng cách tận dụng tất cả những thứ đó
Cần nhanh chóng tìm cách chạy các GPU này bằng điện xanh. Nếu không, các AI sẽ tranh luận với nhau về lời giải tối ưu cho tic-tac-toe rồi làm Trái Đất tan chảy mất
Đôi khi đó là cách dễ nhất để hoàn thành một tác vụ rất nhỏ, nhưng chênh lệch chi phí backend hẳn là khá lớn. Cuối cùng người dùng sẽ hoàn toàn không bận tâm, vì nó không có cảm giác thực tế
Việc AI cần phải liên tục chạy đối đầu với chính nó đã được xem như một sự thật rồi
Tôi nghĩ đây là cách để các mô hình học máy nảy ra ý tưởng mới
Thông qua tự tranh luận, chúng thực hiện phép chéo hóa trên mọi ý tưởng đã từng được thử và loại bỏ, đồng thời vẫn duy trì một số ràng buộc nhất quán nhất định. Tất nhiên nói thì dễ hơn làm rất nhiều
Giống Conway's Game of Life, nhưng thay vì các ô vuông màu có quy tắc, là những LLM với trọng số nào đó liên tục nói chuyện với nhau, rồi ở đâu đó trồi lên thành lời nói hoặc hành động
https://news.ycombinator.com/item?id=43835798
Chuyện này sẽ đi xa đến đâu? Liệu sẽ xuất hiện đội scrum gồm các AI agent họp stand-up vài giờ một lần không?
Liệu chúng ta sẽ tái tạo bộ máy quan liêu của chính phủ bằng các agent tranh luận về một chủ đề suốt ngày để tìm ra quan điểm tốt nhất không?
Các AI agent với những vai trò khác nhau vận hành một đội scrum, prompt của từng agent đều được thiết kế để phản đối mọi người hoặc trình bày quan điểm của mình theo cách rất phê phán, và quyết định cuối cùng do một người điều phối đưa ra
Người thuyết trình khẳng định rằng cách này hiệu quả với họ
Con người có những trải nghiệm và góc nhìn khác nhau, còn LLM thì ở mức độ thấp hơn. Dù vậy đôi khi chỉ cần đội thêm một chiếc mũ khác là đủ. Chẳng hạn như khác biệt giữa người review code và người viết code
Một ngày nào đó sẽ có điểm mà hiệu quả trở nên đi ngang, và hẳn sẽ có cả một ủy ban AI để xác định điểm đó
Vì chắc họ không muốn “đun sôi cả đại dương” đâu
Thật tốt khi họ làm cho thứ này dễ fork để mang về nghịch
Tôi vừa bắt đầu vòng lặp của mình: thêm Nash Equilibrium và tái cấu trúc “prompt engineering” thành đàm phán đa tác nhân. Tò mò không biết mọi người nghĩ sao
https://github.com/faramarz/NECoRT/
Tôi cho rằng LLM cho doanh nghiệp sẽ không gặp vấn đề lớn với chi phí tính toán bổ sung, và sẽ thiên về việc điều chỉnh các bài toán tài chính phức tạp thông qua nhiều tối ưu hóa mô hình hơn
Tôi không thật sự quen với kho mã nguồn công khai và việc đóng góp, nên nếu tôi đang làm sai thì mong có ai đó chỉ ra
Ý định là fork codebase gốc để kiểm thử lý thuyết, rồi cuối cùng gửi lên thành PR