- Forge là một lớp độ tin cậy cho việc gọi công cụ của các LLM tự lưu trữ, tập trung vào việc tăng độ ổn định của các mô hình cục bộ nhỏ trong quy trình agent nhiều bước
- Các tính năng cốt lõi gồm rescue parsing để khôi phục các lệnh gọi công cụ sai, cơ chế gợi ý thử lại, ép buộc các bước bắt buộc, ngân sách token theo nhận thức VRAM, và nén ngữ cảnh phân tầng
- Hiện tại, cấu hình tự lưu trữ hàng đầu là Ministral-3 8B Instruct Q8 trên llama-server, đạt 86.5% trong 26 kịch bản đánh giá và 76% ở tier khó nhất
- Có ba cách sử dụng: giao toàn bộ vòng lặp agent cho
WorkflowRunner, đưa Guardrails middleware vào vòng lặp điều phối hiện có, hoặc áp dụng minh bạch bằng proxy server tương thích OpenAI
WorkflowRunner quản lý system prompt, thực thi công cụ, nén ngữ cảnh và guardrail, còn SlotWorker bổ sung hàng đợi ưu tiên và khả năng preemption tự động cho các slot suy luận GPU dùng chung- Proxy server được chạy bằng
python -m forge.proxy, đứng giữa các client tương thích OpenAI như opencode, Continue, aider và máy chủ mô hình cục bộ để áp dụng guardrail
- Proxy tự động chèn công cụ tổng hợp
respond vào các yêu cầu có công cụ để buộc mô hình gọi respond(message="...") thay vì xuất văn bản thuần, rồi loại bỏ nó khỏi phản hồi để phía client vẫn thấy như một phản hồi văn bản bình thường
- Các backend được hỗ trợ gồm Ollama, llama-server (llama.cpp), Llamafile và Anthropic; llama-server cung cấp hiệu năng và khả năng kiểm soát tốt nhất, Ollama dễ thiết lập, Llamafile chạy bằng một binary duy nhất, còn Anthropic dùng cho baseline frontier và quy trình lai
- Có thể cài đặt bằng
pip install forge-guardrails, thêm client Anthropic bằng pip install "forge-guardrails[anthropic]"; yêu cầu là Python 3.12+ và một backend LLM đang chạy
- Bộ khung đánh giá đo độ ổn định gọi công cụ nhiều bước của các tổ hợp mô hình và backend qua 26 kịch bản, được chia thành tier chuẩn OG-18 và 8 tier advanced_reasoning
- Cấu hình kiểm thử bao gồm 865 bài kiểm thử đơn vị mang tính xác định không cần backend LLM và bộ khung đánh giá chạy trên backend thực
- Khung guardrail Forge và nghiên cứu ablation đã được công bố dưới tên Forge: A Reliability Layer for Self-Hosted LLM Tool-Calling; giấy phép là MIT
1 bình luận
Ý kiến trên Hacker News
Tôi thích làm việc trong lĩnh vực này và thấy nó hữu ích, nhưng tôi tránh LLM chạy trên đám mây và chủ yếu dùng các mô hình local 4B~30A3B tham số
Vì vậy dù tôi không nắm rõ cảm giác về hiệu năng hay độ chính xác của các LLM mới nhất, tôi nghĩ mình hiểu khá rõ mức có thể kỳ vọng và các nút thắt ở mô hình local
Tôi chỉ lướt nhanh bài viết và đọc phần tóm tắt, thấy có nhắc rằng chỉ cần điều chỉnh đơn giản là có thể nhanh hơn hoặc chậm hơn 10 lần, nhưng các chỉ số và dữ liệu dường như gần như chỉ tập trung vào độ chính xác. Cần phải nói về tốc độ
Đặc biệt với workflow kiểu agent và mô hình local, với cá nhân tôi thì độ chính xác gọi hàm/công cụ từ khoảng thời QwenCoder3 đến nay trong 6~12 tháng qua không còn là vấn đề lớn, mà cốt lõi là quản lý ngữ cảnh và tác động về thời gian. Nếu agent thay prompt thường xuyên thì các tối ưu thời gian như prompt caching sẽ bị phá vỡ
Có vẻ ở đây còn thêm các lớp và wrapper như guardrail với retry, mà với mô hình local, nhất là dùng cho agent, độ trễ có thể khiến nó trở nên không dùng nổi
Nếu bài đã xử lý trực diện chuyện này thì xin lỗi, nhưng vì nói quá ít về ảnh hưởng tới thời gian nên tôi có cảm giác như mức cải thiện thực tế đang bị che giấu hoặc thổi phồng. Tôi muốn nghe về trải nghiệm tốc độ. Cũng hơi lo vì không thấy người khác nêu vấn đề này, làm tôi tự hỏi có phải mình đang làm sai gì đó, hay là mọi người thực ra không dùng mô hình local
Tôi đã luôn nói rằng chỉ cần có một harness tử tế thì mô hình local nhỏ cũng có thể làm tốt đến mức đáng ngạc nhiên
Nếu đó là một hệ thống có thể thử mọi cách, thì chỉ cần ngăn nó không đưa ra kết quả sai trong quá trình đó là cuối cùng nó sẽ tìm ra đáp án đúng
Nếu tác vụ đủ phức tạp thì ngay cả mô hình mới nhất cũng có vấn đề này, và với mô hình nhỏ thì nó còn bị khuếch đại mạnh hơn
Khả năng suy luận cũng khá ổn, và trong nhiều trường hợp là đủ dùng. Thỉnh thoảng chỉ cần đẩy nó trở lại đúng quỹ đạo là nó tự giải quyết được
Thật vui khi thấy có người làm thứ mà tôi đã muốn dành thời gian để làm, mà còn làm tốt hơn nhiều. Một câu hỏi là, ví dụ trong vòng lặp retry, có dư địa để song song hóa không?
Mô hình local nói chung xử lý khá tốt một số lượng yêu cầu đồng thời hạn chế, cỡ vài chục, ngay cả trên phần cứng tiêu dùng, và như vậy thông lượng token/giây hiệu dụng có thể tăng hơn 10 lần
Tôi đã nghĩ về những workflow tận dụng điều này từ khá lâu, và kiểu “hãy sửa lỗi này” có vẻ là chỗ áp dụng được dù không hoàn hảo. Tôi muốn biết bạn nghĩ sao
Tôi có vài ý tưởng trong mảng này và đang đưa vào harness của mình. Harness của tôi khá đặc thù nên tôi không chắc nó có khái quát được không
Tôi chia vấn đề thành phần thực thi có kế hoạch, rồi cung cấp một kế hoạch ban đầu bao gồm mục tiêu rõ ràng như agent thực thi sẽ gọi công cụ nào và tiêu chí cho một lần thực thi thành công. Harness sẽ thực hiện kế hoạch đó theo thứ tự
Ở mỗi bước có gọi công cụ, tôi tách việc gọi công cụ thành các thành phần. Harness hỏi agent giá trị tham số hợp lệ cho đối số công cụ hiện tại, và trong định nghĩa công cụ có validator cho từng đối số. Nếu xác thực thất bại thì harness tua ngược cuộc hội thoại và chèn lý do thất bại vào lần thử tiếp theo
Khi có phản hồi hợp lệ cho đối số thì chuyển sang đối số tiếp theo, và khi mọi đối số đã được điền thì gọi công cụ. Sau đó nó truyền cả kỳ vọng ban đầu của agent, giá trị thực tế và lỗi phát sinh, rồi hỏi có hài lòng với kết quả không
Nếu không hài lòng thì agent nêu lý do, harness tua ngược hội thoại, thêm lý do retry rồi bắt đầu lại quy trình gọi công cụ từ đầu
Nếu phát hiện lỗi trong kế hoạch ban đầu thì agent có thể yêu cầu lập kế hoạch lại, và nếu thất bại liên tiếp quá nhiều thì harness cũng sẽ thử lập kế hoạch lại
Cách này khá hiệu quả trong việc giảm lỗi gọi công cụ. Một lợi điểm là sub-agent nhận được lịch sử hội thoại hoàn hảo, không có sai sót. Tuy vậy tôi vẫn chưa benchmark xem tỷ lệ hoàn thành công việc thực tế có tốt hơn không
Về phần tua ngược hội thoại, với agent chính tức là agent trò chuyện với người dùng, tôi đã triển khai kiểu gấp lời gọi công cụ tương tự. Khi tác vụ xong thì tôi gấp lại lịch sử gọi công cụ để giữ ngữ cảnh sạch sẽ; việc này gần với vệ sinh hơn là tiết kiệm kích thước
Phần harness chất vấn ngược mô hình thì hơi khác, tôi chưa thử cách đó. Forge dựa vào khả năng tự sửa của mô hình để tránh các chế độ lỗi chuyên biệt, nhưng nếu có thể trừu tượng hóa và tự động hóa quy trình hỏi đáp dựa trên thứ như schema thì có vẻ làm được
Nhìn chung tôi thích khía cạnh giữ lịch sử hội thoại sạch, nhưng với công cụ có nhiều tham số thì có vẻ số vòng qua lại sẽ nhiều hơn rất nhiều so với kiểu “cứ để nó fail trước rồi đẩy nhẹ một lần”. Dù vậy đây là ý tưởng thú vị cho các kịch bản hay tác vụ khó hơn
Nếu với mô hình nhỏ mà đạt hơn 50k token/giây thì sẽ rất đáng kể
Nhưng hiện tại tôi đang bận việc công ty và vài dự án khác, nên mới chỉ thử vài chục prompt để xem có khả thi không
Tuyệt vời. Hiện tại vì chi phí nên tôi chưa thể dùng suy luận local, nhưng khi dùng mô hình nhỏ qua OpenRouter thì tôi vẫn lo về việc gọi công cụ
Tôi đang xây Dokimasia(do-kee-ma-see-ah), một framework kiểm thử đối số theo hướng pytest, và muốn nghe ý kiến: https://github.com/deevus/dokimasia
Có thể kiểm thử đối số không phải thứ Forge cần, nhưng vì bạn đang xây công cụ AI khá sâu nên tôi nghĩ có lẽ bạn sẽ có quan điểm
Có vẻ nó nằm cao hơn Forge một tầng, và gần với việc kiểm thử các workflow thực tế cùng những điểm tích hợp bộc lộ trong đó, ví dụ công cụ nào cung cấp quyền truy cập MCP
Tôi không nghĩ chồng hai thứ lên nhau sẽ có vấn đề gì lớn
Điều tôi tò mò là bạn xử lý tính không xác định của các mô hình này như thế nào. Có lúc nó gọi công cụ đúng, lúc khác lại xuất JSON sai. Bộ test có chạy nhiều lần không?
Sự mơ hồ trong gọi công cụ tôi gặp cả ở các mô hình tuyến đầu. Tôi dùng Claude Code, Codex và Gemini CLI song song mỗi ngày cho công việc phát triển, và chế độ lỗi phổ biến nhất là khi grep/find kết thúc với mã thoát 1, tức là không có kết quả khớp
Mô hình lại đọc điều đó thành “công cụ thất bại” thay vì “lệnh tìm kiếm đã chạy và không tìm thấy gì”, rồi hoặc bỏ cuộc, hoặc thay vì mở rộng phạm vi tìm kiếm thì chỉ đổi nhẹ cú pháp rồi thử lại
Lớp retry-nudge gần như tương ứng 1:1 với việc tôi vẫn đang làm thủ công nhiều lần mỗi giờ. Kiểu như “không, không phải công cụ lỗi đâu, mà là file đó không có pattern đó. Hãy thử X đi”
Có vẻ hướng đúng là mã hóa điều này ở cấp framework
Tôi cũng muốn biết liệu bạn có thấy các guardrail kiểu này thu hẹp khoảng cách với mô hình tuyến đầu nhỏ trong các tác vụ dài không. Theo trực giác của tôi, với Sonnet thì chênh lệch 87→99 có lẽ sẽ không giữ nguyên nếu vượt quá khoảng 50 bước. Sau đó context drift sẽ chi phối nhiều hơn là ngữ nghĩa retry
Để làm rõ, về mặt kỹ thuật forge quan tâm đến thực thi gọi công cụ chứ không phải chất lượng mô hình. Câu trả lời thực tế là thế này
Với các mô hình nhỏ cỡ 14B, yếu tố giới hạn là sự chú ý hiệu dụng. Dù vẫn nằm gọn trong kích thước cửa sổ ngữ cảnh đã huấn luyện, đến một ngưỡng nào đó vẫn bắt đầu thấy hiệu năng giảm. Tôi không có con số chính xác, nhưng các mô hình như Opus có thể đi được lâu hơn nhiều ở điểm này
Tôi cũng đã làm một tính năng gấp lịch sử thông điệp gọi công cụ mà có thể một ngày nào đó sẽ viết trực tiếp vào forge. Về bản chất, nó dọn dẹp lịch sử thông điệp một cách thông minh để mô hình bớt mất dấu hơn
Dù vậy, bộ đánh giá code của harness code kiểu agent vẫn có các tác vụ refactor và bổ sung tính năng, tất cả đều được thực hiện trong các kho sandbox thực tế. Mô hình nhỏ vẫn có thể xử lý được những việc như vậy trong khi bị đẩy tới 50~60 lần gọi công cụ. Nhưng chắc tôi sẽ không giao cho nó hơn hai việc kiểu đó trong cùng một session
Hơi lạc đề một chút, nhưng nếu bạn đang ở Texas Instruments thì tôi tò mò liệu bạn có thể tìm hiểu tình trạng sở hữu trí tuệ của máy Lisp TI Explorer không
Tôi biết ai đang sở hữu IP của Genera, nhưng chưa tìm ra được gì về Lisp OS của TI
Với những người nhìn “stack an toàn cho agent” theo nghĩa rộng hơn, hướng này có cảm giác bổ sung lẫn nhau với những thứ như kontext-cli của Kontext (github.com/kontext-dev/kontext-cli) hay OneCLI (github.com/onecli/onecli)
Có đoạn nói rằng “cùng một trọng số Mistral-Nemo 12B cho ra độ chính xác 7% trong gọi hàm native của llama-server, nhưng 83% trong chế độ prompt của Llamafile”
Tôi cứ nghĩ Llamafile chỉ là đóng gói mô hình và llama.cpp vào một nhị phân duy nhất, nên khác biệt này có phải là do Llamafile chèn system prompt mặc định còn llama-server endpoint thô bị harness gọi trực tiếp hay không?
Nhìn giống như đang so táo với bánh táo, thiếu mất nguyên liệu ở giữa
Nhưng như vậy vẫn không giải thích được chênh lệch khoảng +4 điểm % giữa prompt của Lamaserver và llamafile, hay chênh lệch khoảng +30 điểm % của Ollama, vốn nằm gần như giữa llamaserver native và llamafile
Backend phục vụ ảnh hưởng đến gần như mọi họ mô hình, và đây là phần mà tôi hầu như chưa từng thấy được bàn tới
Đây thực sự là một hướng rất tuyệt. Ngay cả với mô hình bonsai 1-bit mà cũng cho ra kết quả vô lý đến mức tốt, lại còn hợp với lmstudio
Giờ thì chuyện cắm một con 7900XTX vào dàn máy dư, để dưới tầng hầm, ném cho nó một mục tiêu ngớ ngẩn rồi quên luôn đi đã trở thành điều hoàn toàn khả thi