AutoThink: Cải thiện hiệu năng LLM cục bộ bằng suy luận thích ứng

 (news.ycombinator.com)
2 điểm bởi GN⁺ 2025-05-29 | 1 bình luận | Chia sẻ qua WhatsApp
  • Đây là một kỹ thuật giúp LLM cục bộ điều chỉnh token suy luận theo độ khó của truy vấn, để tạo ra câu trả lời hiệu quả hơn với cùng lượng tài nguyên
  • Thay vì cho mọi truy vấn cùng một “thời gian suy nghĩ”, hệ thống chia thành mức phức tạp HIGH/LOW và phân bổ 70~90% token cho suy luận phức tạp, 20~40% cho truy vấn đơn giản
  • Sử dụng steering vector dựa trên Pivotal Token Search từ bài báo về Microsoft Phi-4 để dẫn dắt các mẫu suy luận như độ chính xác số học, tự sửa lỗi và khám phá kỹ lưỡng
  • Trên DeepSeek-R1-Distill-Qwen-1.5B, GPQA-Diamond tăng từ mức cơ sở 21.72% lên 31.06%, tương đương cải thiện tương đối 43%, còn MMLU-Pro tăng từ 25.58% lên 26.38%
  • Hoạt động trên các mô hình suy luận cục bộ như DeepSeek, Qwen và các mô hình fine-tuning tùy chỉnh, đồng thời không phụ thuộc API và dùng ít token hơn so với cách tiếp cận cơ sở

Điều chỉnh tài nguyên suy luận theo từng truy vấn

  • AutoThink là một kỹ thuật phân bổ tài nguyên thích ứng giúp phân phối tài nguyên suy luận của LLM cục bộ khác nhau cho từng truy vấn
  • Trước tiên, hệ thống phân loại truy vấn thành mức phức tạp HIGH hoặc LOW, sau đó điều chỉnh tỷ lệ token suy luận theo độ phức tạp
    • Suy luận phức tạp: 70~90% tổng số token
    • Truy vấn đơn giản: 20~40% tổng số token
  • Steering vector được suy ra từ Pivotal Token Search và dẫn hướng mô hình trong quá trình sinh
    • Các hành vi được thúc đẩy gồm độ chính xác số học, tự sửa lỗi và khám phá kỹ lưỡng
  • Việc triển khai gồm hai trục chính
    • Khung phân loại thích ứng có thể học các danh mục độ phức tạp mới mà không cần huấn luyện lại
    • Triển khai mã nguồn mở của Pivotal Token Search

Kết quả benchmark và phạm vi áp dụng

  • Trên DeepSeek-R1-Distill-Qwen-1.5B cho thấy các kết quả sau
    • GPQA-Diamond: 31.06%, cải thiện tương đối 43% so với mức cơ sở 21.72%
    • MMLU-Pro: 26.38%, tăng so với mức cơ sở 25.58%
    • Sử dụng ít token hơn so với cách tiếp cận cơ sở
  • AutoThink có thể áp dụng rộng rãi cho các mô hình suy luận cục bộ
    • Ví dụ mô hình: DeepSeek, Qwen, các mô hình fine-tuning tùy chỉnh
    • Không phụ thuộc API
  • Tài liệu liên quan

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-05-29
Ý kiến trên Hacker News

  • Tôi xin nói rõ rằng động lực của AutoThink bắt đầu từ trải nghiệm nhìn thấy các mô hình suy luận hiện có lãng phí tài nguyên tính toán—sự kém hiệu quả hiện ra rất rõ khi chúng tiêu tốn lượng “thời gian suy nghĩ” cho cả những câu hỏi cực dễ như “2+2 bằng mấy?” ngang với các chứng minh toán học phức tạp. Điều đáng ngạc nhiên là khi kết hợp hai hướng tôi đang thử riêng—phân loại thích ứng (có thể học danh mục mới mà không cần huấn luyện lại) và Pivotal Token Search được Microsoft công bố mã nguồn mở trong bài báo Phi-4—rồi áp dụng thêm phân bổ ngân sách token động, mức cải thiện hiệu năng lại lớn hơn dự kiến rất nhiều. Trên thực tế, số token dùng trung bình còn giảm xuống, vì các truy vấn đơn giản thực sự kết thúc nhanh hơn nhiều và chỉ các truy vấn phức tạp mới được cấp thêm tính toán. Một vài điểm kỹ thuật là: steering vector rất nhỏ, dưới 1MB cho mỗi pattern nên hầu như không có overhead bộ nhớ; quá trình phân loại chỉ thêm khoảng 10ms độ trễ (mức có thể bỏ qua); và việc chọn target layer là rất quan trọng (ở đa số mô hình, các layer giữa khoảng 15~20 cho kết quả tốt nhất). Điều tôi muốn nhận phản hồi là—kinh nghiệm với các cách tiếp cận thích ứng tương tự, các reasoning pattern có thể steer hữu ích hơn, và ý tưởng tự động phát hiện target layer tối ưu. Nếu có gì thắc mắc về phần triển khai hay kết quả thì cứ hỏi

    • Giờ thì cũng không hẳn vậy nữa. Bạn đã thử Gemini 2.5 Pro chưa—với câu hỏi đơn giản thì nó gần như không “nghĩ”, còn với câu hỏi lập trình thì viết câu trả lời dài như một bài luận logic. Có vẻ o3 cũng vậy

    • Xin chúc mừng! Mọi nỗ lực về tăng hiệu quả cho LLM đều rất đáng hoan nghênh. Từ trước đến nay tôi tối ưu kiểu lười biếng bằng cách chỉ xử lý truy vấn đơn giản bằng mô hình MLX trên Mac Mini M4, còn truy vấn phức tạp thì gửi sang Nvidia 4090—hiệu quả của M4 thực sự đáng kinh ngạc nếu so với Nvidia. Tôi nghĩ Apple đang đi đúng hướng với MLX. Tôi dự định sẽ đọc thêm về AutoThink và tích hợp nó vào workflow cá nhân

    • Tôi nghĩ đáng để thử cách chèn “câu trả lời của non-reasoning model” vào sau prompt người dùng—ví dụ như “Sau đây là nội dung mà non-reasoning model đã nghĩ ra: ... Đây có phải là kết quả người dùng mong muốn không?”. Khi bản non-reasoning là đủ, reasoning model cũng có thể đưa ra câu trả lời nhanh hơn

    • Ngay cả Claude Sonnet 3.5 (chứ chưa nói đến 3.7 hay 4 mới hơn) cũng cho thấy thời gian xử lý khác nhau rất rõ theo độ phức tạp của truy vấn—có thể thấy nó đang điều chỉnh thời gian xử lý một cách động

  • Tôi thắc mắc làm sao có thể phân loại câu hỏi thành “phức tạp” và “đơn giản”. Một câu hỏi trông đơn giản bề ngoài cũng có thể cực kỳ khó trên thực tế. Ví dụ, nghiệm nguyên của x³+y³+z³=42 là một bài toán đã tiêu tốn hơn 100 năm tài nguyên tính toán. Hoặc phương trình x/(y+z)+y/(z+x)+z/(x+y)=4 cũng trông có vẻ đơn giản nhưng lại có những nghiệm cực lớn cần đến lý thuyết đường cong elliptic. Liên kết tham khảo lời giải

    • Phân loại độ khó của bài toán tự nó đã là một kỹ năng riêng—một năng lực có thể học tách biệt với việc giải thật. Ví dụ, khi nhìn phương trình trên thì phải nhận ra ngay ba điểm khó: miền số nguyên, 3 biến, phương trình bậc 3. Ba yếu tố này kết hợp lại làm độ khó tăng vọt. Nếu là số thực hay số phức, ít biến hơn hoặc bậc thấp hơn thì sẽ dễ hơn nhiều. Tất nhiên như vậy không có nghĩa là chắc chắn khó, nhưng có thể đó là bài toán chưa được giải. Tôi thực ra không có năng lực để giải, nhưng đã luyện được cảm giác nên tìm thông tin ở đâu, nên có thể nhận ra ngay “cái này rất khó”. Tôi nghĩ LLM cũng có thể học các gợi ý kiểu đó để phát triển khả năng phân loại độ khó mà không cần giải thật bài toán (hoặc có lẽ chúng đã học rồi)

    • Trong ngữ cảnh này, độ khó của truy vấn được định nghĩa dựa trên lượng token mà mô hình tiêu tốn để tạo ra câu trả lời đúng trên các bộ dữ liệu có đáp án chuẩn (như GSM8k). Bộ phân loại thích ứng được huấn luyện trên bộ dữ liệu này và dùng để phân loại trong giai đoạn suy luận

  • Khi extended thinking toggle xuất hiện trên Claude 3.7, tôi cũng đã làm một POC autothink tương tự—thậm chí tên cũng là autothink
    github.com/NiloCK/autothink
    blog think-toggles-are-dumb
    Phiên bản của tôi có cấu trúc gồm một lượt đầu để LLM chấm độ khó của truy vấn theo thang 0~100, rồi phân bổ ngân sách suy nghĩ tuyến tính theo điểm đó. Rõ ràng nó đơn giản hơn công trình của OP, nhưng tôi thật sự vui khi thấy kết quả định lượng—một thành phẩm rất tốt!

  • Đây có vẻ là một tối ưu hóa hiển nhiên, nên tôi khá ngạc nhiên là sự thay đổi này chưa xảy ra từ sớm hơn. Cách giải thích và phần tự triển khai đều rất ấn tượng

  • Với các reasoning model như QwQ hay Qwen 3, thành thật mà nói tôi không dành nhiều thời gian để cải thiện kết quả, mà chủ yếu thử hạn chế đầu ra reasoning token bằng nhiều loại prompt khác nhau. Gemma 3 27B QAT không phải reasoning model, nhưng khi dùng trong chuỗi hoặc route LLM thì khả năng tuân thủ chỉ thị của nó rất tốt, nên có thể đưa vào bước phân loại trước/tối ưu ngôn ngữ rồi dùng cho reasoning thật ở giai đoạn sau. Cũng có thể cho xen kẽ các câu trả lời trung gian giữa nhiều thinking tag. Trong các thí nghiệm kiểu này, “token đang suy nghĩ” được định nghĩa tách biệt với kết luận, là toàn bộ token đóng vai trò bậc thang trung gian cho từng bước giải quyết vấn đề. Tôi từng thấy rằng nếu chỉ thị mô hình ưu tiên dùng một số token hay cách diễn đạt nhất định thì kết quả nhìn chung được cải thiện, và cách AutoThink tự động dùng những token có hiệu năng tốt nhất trên dataset có vẻ có thể trở thành một tối ưu hóa tổng quát hơn và hiệu quả hơn. Tuy nhiên, nếu dùng quá nhiều pivot token thì có nguy cơ overfit vào các câu hỏi benchmark, nên tôi muốn theo dõi thêm xem cách này tổng quát hóa đến đâu. Cá nhân tôi xem việc lựa chọn từ/token cẩn thận là một tối ưu hóa chi phí thấp nhưng hiệu quả cao giúp nâng chất lượng kết quả lên đáng kể, nên rất kỳ vọng vào khả năng tổng quát hóa của AutoThink

  • Thật tuyệt khi nhờ các mô hình nhỏ mà những nhóm nhỏ và các nhà nghiên cứu cá nhân cũng có thể dễ dàng chứng minh các cách tiếp cận hay thử nghiệm đổi mới mà trước đây chỉ các phòng lab AI lớn mới làm được. Càng cạnh tranh ở mảng SML (Small Language Model) tăng lên, những gì có thể triển khai on-device càng mở rộng vượt xa tưởng tượng

    • Tôi nghĩ tên gọi đúng nên là SLM thay vì “small language models (SML)”

  • Nếu bạn đang host mô hình cho người khác dùng, thì việc tiết kiệm tài nguyên tính toán cho những câu hỏi cực kỳ đơn giản cũng là điều tốt. Trong trường hợp đó, có thể có nhược điểm là mô hình xử lý hời hợt những câu quá dễ đánh giá, nhưng tôi không phải người gánh chi phí đó. Ngược lại, nếu tôi trực tiếp dùng mô hình trên PC của mình thì, sau khi đã đầu tư nhiều tiền vào GPU, tôi lại muốn tận dụng tài nguyên tối đa—thậm chí không muốn giảm tính toán cho cả các truy vấn đơn giản

  • Một ý tưởng rất đáng suy ngẫm! Bên tôi cũng đang định bàn nội bộ về việc trong thiết kế AI crawler, cần nhận biết linh hoạt nên gửi nhiều hay ít truy vấn hơn tùy từng website được ghé thăm. Nhân tiện, bên tôi là samaritanscout.org, một dự án công cụ tìm kiếm tổng hợp mọi cơ hội tình nguyện tại địa phương được đăng trên nhiều website phi lợi nhuận khác nhau

  • Tôi chỉ mới bước vào lĩnh vực LLM và AI gần đây, nhưng cảm thấy dự án này cực kỳ hấp dẫn. Việc AutoThink điều chỉnh nỗ lực tính toán để AI “suy nghĩ thông minh hơn” theo độ khó của bài toán nghe rất trực quan—giống như con người giải ngay các phép như 2+2 và chỉ dành thời gian thật sự suy nghĩ cho bài khó. Tôi chưa hiểu rõ các yếu tố kỹ thuật như ngân sách token hay steering vector, nhưng rất bị cuốn hút bởi cách tiếp cận vừa nhanh hơn vừa thông minh hơn này. Tôi sẽ tiếp tục theo dõi

  • Tôi nghĩ trong LLM thì tốt hơn nên tránh dùng các từ như “nghĩ” hay “suy luận”—cả hai đều có ý nghĩa riêng và nền tảng triết học nhất định, trong khi thực tế LLM không hề tư duy hay suy luận như vậy mà gần hơn với việc chỉ dùng nhiều tính toán hơn (thời gian xử lý của bộ xử lý) để tạo ra kết quả

    • Chuyện đó giờ đã qua rồi. Cũng như từ “computer” ngày xưa từng chỉ người làm phép tính nhưng giờ nghĩa đã chuyển hẳn sang máy móc, ở đây thuật ngữ cũng đã thay đổi như vậy

    • Có thể ví như “ping”—khi nói “ping” một địa chỉ IP thì không phải thật sự phát sóng âm vào thân tàu kim loại, nhưng từ này vẫn được dùng theo nghĩa ẩn dụ phù hợp với hành vi thực tế. Nếu là một ẩn dụ hữu ích thì trong đời thường đâu cần khớp 1:1 với hiện thực

    • Thế giới quan của tôi về nguyên tắc là duy vật và mang tính quyết định luận. Nhưng trong đời sống hằng ngày, tôi lại pha thêm chủ nghĩa hiện sinh và một chút cảm quan tâm linh. Từ góc nhìn thực dụng, nếu tạm thời gán cho những công cụ này một số thuộc tính mang tính nhân hoá, thì dòng hội thoại sẽ dễ hơn và việc nắm bắt công cụ cũng trực quan hơn. Cách này đôi khi bộc lộ giới hạn, nhưng khi cần tôi nghĩ ta vẫn có thể dễ dàng chuyển sang một khung phân tích hơn