Forge - गार्डरेल्स के साथ 8B मॉडल को एजेंट कार्यों में 53% से 99% तक ले जाने वाला टूल

• Forge self-hosted LLM के tool calling के लिए एक reliability layer है, जिसका फोकस multi-step agent workflow में छोटे local models की स्थिरता बढ़ाने पर है
• इसकी मुख्य क्षमताओं में गलत tool calls को रिकवर करने वाला rescue parsing, retry को प्रेरित करना, required steps को enforce करना, VRAM-aware token budgeting, और hierarchical context compression शामिल हैं
• वर्तमान शीर्ष self-hosted configuration Ministral-3 8B Instruct Q8 on llama-server ने 26 evaluation scenarios में 86.5% और सबसे कठिन tier में 76% स्कोर किया
• इसे इस्तेमाल करने के तीन तरीके हैं: WorkflowRunner के साथ पूरे agent loop को संभालना, मौजूदा orchestration loop में Guardrails middleware जोड़ना, या OpenAI-compatible proxy server के रूप में इसे transparently लागू करना
• WorkflowRunner system prompt, tool execution, context compression और guardrails को मैनेज करता है, जबकि SlotWorker shared GPU inference slots में priority queue और automatic preemption जोड़ता है
• proxy server python -m forge.proxy से चलाया जाता है और opencode, Continue, aider जैसे OpenAI-compatible clients और local model server के बीच guardrails लागू करता है
• proxy tool वाले requests में synthetic respond tool को अपने-आप inject करता है, ताकि model सामान्य text के बजाय respond(message="...") को call करे, और response में इसे हटाकर client को सामान्य text response जैसा दिखाए
• supported backends हैं Ollama, llama-server(llama.cpp), Llamafile, और Anthropic; इनमें llama-server सर्वोत्तम performance और control देता है, Ollama आसान setup, Llamafile single-binary execution, और Anthropic frontier baseline तथा hybrid workflows के लिए है
• installation pip install forge-guardrails से की जा सकती है, और Anthropic client के लिए pip install "forge-guardrails[anthropic]" जोड़ना होगा; requirements हैं Python 3.12+ और एक चल रहा LLM backend
• evaluation harness 26 scenarios के माध्यम से model और backend संयोजनों की multi-step tool-calling reliability को मापता है, और यह OG-18 standard tiers तथा 8 advanced_reasoning tiers में बंटा है
• test setup में 865 deterministic unit tests शामिल हैं जिन्हें LLM backend की जरूरत नहीं होती, साथ ही वास्तविक backend के लिए evaluation harness भी शामिल है
• Forge guardrails framework और ablation study को Forge: A Reliability Layer for Self-Hosted LLM Tool-Calling के रूप में प्रकाशित किया गया है, और इसका license MIT है

[GN⁺]

Hacker News टिप्पणियाँ

• मुझे इस क्षेत्र का काम पसंद है और यह मददगार भी है, लेकिन मैं cloud-based LLM से बचता हूँ और ज़्यादातर 4B~30A3B parameter वाले local models इस्तेमाल करता हूँ
  इसलिए हो सकता है कि मुझे नवीनतम LLM performance या accuracy का पूरा अंदाज़ा न हो, लेकिन local models से क्या उम्मीद की जा सकती है और bottlenecks कहाँ आते हैं, इसका अच्छा अनुभव है
  मैंने लेख को सरसरी तौर पर देखा और abstract पढ़ा, और उसमें यह तो कहा गया है कि छोटे बदलावों से 10 गुना तेजी या मंदी आ सकती है, लेकिन metrics और data लगभग पूरी तरह accuracy पर केंद्रित लगते हैं। speed को भी कवर करना चाहिए
  खासकर agentic workflow और local models में, मेरे अनुभव में function/tool calling accuracy QwenCoder3 के आसपास से पिछले 6~12 महीनों में कोई बड़ी समस्या नहीं रही; असली मुद्दा context management और time impact है। अगर agent बार-बार prompt बदलता है, तो prompt caching जैसी time optimizations टूट जाती हैं
  ऊपर से इसमें guardrails और retries जैसी layers और wrappers भी जुड़ती दिख रही हैं, और local models में, खासकर agent use case में, latency की वजह से यह इस्तेमाल लायक न रहे, ऐसा हो सकता है
  अगर यह पहले ही सीधे address किया गया हो तो माफ़ी, लेकिन time impact पर इतनी कम बात देखकर लगता है जैसे असली improvement को छिपाया गया है या बढ़ा-चढ़ाकर दिखाया गया है। मैं speed का अनुभव सुनना चाहूँगा। यह भी थोड़ा चिंता की बात है कि और लोगों ने यह मुद्दा नहीं उठाया; कहीं मैं ही कुछ गलत तो नहीं कर रहा, या फिर लोग सच में local models इस्तेमाल ही नहीं कर रहे?

• मैं लंबे समय से कहता आया हूँ कि अगर आपके पास एक ठीक-ठाक harness हो, तो छोटे local models भी हैरान करने लायक अच्छा काम कर सकते हैं
  अगर सिस्टम हर चीज़ try कर सकता है, तो बस यह सुनिश्चित करना है कि वह बीच में गलत final result न दे, और अंततः वह सही जवाब तक पहुँच सकता है

  • समस्या यह है कि quality कुछ वैसी लगती है जैसे किसी junior को अनलिमिटेड समय दे दिया जाए और कहा जाए कि लक्ष्य तक पहुँचने तक अलग-अलग तरीके आज़माता रहे
    अगर task काफ़ी complex हो, तो नवीनतम models में भी यह समस्या होती है, और छोटे models में यह और ज़्यादा बढ़ जाती है
  • मुझे यह framing पसंद आई। इस तरह के काम में छोटे models काफ़ी प्रभावशाली लगे
    reasoning भी काफी ठीक रहती है और कई मामलों में पर्याप्त होती है। कभी-कभी बस उन्हें वापस track पर थोड़ा धक्का देना पड़ता है, फिर वे खुद हल निकाल लेते हैं
  • अगर मैंने सही समझा है, तो model सही इसलिए कर पाता है क्योंकि उसे पता होता है कि वह कब गलत है

• अच्छा लगा कि किसी ने वह चीज़ मुझसे कहीं बेहतर बना दी, जिसे मैं समय निकालकर खुद बनाना चाहता था। एक सवाल है: उदाहरण के लिए retry loop में parallelization की गुंजाइश है क्या?
  local models आम तौर पर consumer hardware पर भी सीमित संख्या में, लगभग दो अंकों तक, concurrent requests काफ़ी अच्छी तरह संभाल लेते हैं, और इससे effective tokens/sec 10x से भी ज़्यादा बढ़ सकता है
  मैं कुछ समय से ऐसे workflows के बारे में सोच रहा हूँ जो इसका फायदा लें, और “इस error को ठीक करो” भले परफेक्ट न हो, फिर भी यह एक उपयोगी application लगती है। आपका क्या विचार है?

• मेरे पास इस क्षेत्र के लिए कुछ ideas हैं जिन्हें मैं अपने harness में जोड़ रहा हूँ। मेरा harness काफी specialized है, इसलिए पता नहीं यह generalize हो पाएगा या नहीं
  मैं problem को planned execution में तोड़ता हूँ, और execution agent को एक initial plan देता हूँ जिसमें यह साफ़ होता है कि कौन-से tools call करने हैं और successful execution के criteria क्या हैं। harness उस plan को क्रम में चलाता है
  हर step जिसमें tool call शामिल हो, वहाँ tool call को छोटे components में तोड़ा जाता है। harness agent से current tool arguments के लिए valid parameter values पूछता है, और tool definition में हर argument के लिए validator होता है। validation fail होने पर harness conversation को rewind करता है और failure reason अगली कोशिश में inject करता है
  जब किसी argument के लिए valid response मिल जाता है, तो अगला argument लिया जाता है, और सारे arguments भर जाने पर tool call किया जाता है। agent की initial expectations, actual values और कोई भी errors साथ में देकर उससे पूछा जाता है कि क्या वह result से संतुष्ट है
  अगर वह संतुष्ट नहीं होता, तो agent वजह बताता है, harness conversation को rewind करता है, retry reason जोड़ता है, और tool call process फिर से शुरू करता है
  अगर agent initial plan में flaw पाता है तो वह replanning माँग सकता है, और अगर बहुत लगातार failures हों तो harness भी replanning की कोशिश करता है
  यह तरीका tool calling failures कम करने में काफी असरदार है। एक फायदा यह है कि child agent को बिना गलती वाला, साफ़ conversation history मिलता है। हालांकि, इससे actual task completion rate बेहतर होती है या नहीं, इसका अभी benchmark नहीं किया है

  • मैंने भी छोटे model-आधारित agentic coding harness में इसी तरह की philosophy के साथ experiment किया है, और इसे forge के ऊपर बनाया था
    conversation rewind के संदर्भ में, मैंने primary agent, यानी वह agent जो user से बात करता है, में ऐसा ही tool call folding लागू किया था। task पूरा होने पर tool call history को fold कर देता था ताकि context साफ़ रहे; यह size से ज़्यादा hygiene के लिए था
    harness का model से इतनी probing करना थोड़ा अलग है, और मैंने वह approach नहीं आज़माई। Forge dedicated error modes से बचने के लिए model के self-correction पर निर्भर करता है, लेकिन अगर schema जैसी किसी चीज़ के आधार पर questioning process को abstract और automate किया जा सके, तो यह संभव लगता है
    कुल मिलाकर clean conversation history वाला पहलू अच्छा है, लेकिन जिन tools में arguments ज़्यादा हों, वहाँ “पहले fail होने दो और फिर एक बार nudging करो” की तुलना में कहीं अधिक round-trips हो सकते हैं। फिर भी, कठिन scenarios या tasks के लिए यह दिलचस्प idea है
  • मैं Strix Halo इस्तेमाल कर रहा हूँ और लंबा context होने पर यह धीमा पड़ता है, इसलिए मैं भी यही approach सोच रहा था। इससे शायद 10k tokens से कम context बनाए रखा जा सके
    अगर छोटे models पर 50k tokens/sec से ज़्यादा संभव हो, तो यह काफ़ी बड़ा फर्क होगा
    लेकिन अभी मैं company के काम और दूसरे projects में व्यस्त हूँ, इसलिए यह संभव है या नहीं, देखने के लिए अभी तक सिर्फ़ कुछ दर्जन prompts ही आज़माए हैं
  • मैंने जिज्ञासा में gemma4 के साथ इसे खुद बनाना शुरू किया है, और हैरानी है कि यह उम्मीद से कहीं आगे तक जा रहा है

• शानदार। अभी cost की वजह से मैं local inference इस्तेमाल नहीं कर सकता, लेकिन OpenRouter पर छोटे models चलाते समय tool calling को लेकर चिंता थी
  मैं pytest-first argument testing framework Dokimasia (do-kee-ma-see-ah) बना रहा हूँ और इस पर राय जानना चाहूँगा: https://github.com/deevus/dokimasia
  हो सकता है argument testing Forge के लिए ज़रूरी न हो, लेकिन आप AI tools गहराई से बना रहे हैं, इसलिए लगा कि आपके कुछ विचार होंगे

  • दिलचस्प idea है। मूल रूप से यह AI ecosystem में मौजूद कई integration types, जैसे MCP या skills आदि, को test करने के लिए एक abstraction layer को formalize करने जैसा लगता है
    यह Forge से एक layer ऊपर का काम लगता है, और असल workflows तथा उनमें दिखने वाले integration points, जैसे कौन-सा tool MCP access देता है, उन्हें test करने के ज़्यादा करीब है
    दोनों को साथ में overlap करके इस्तेमाल करना भी शायद कोई बड़ी समस्या नहीं होगी
    मेरी जिज्ञासा यह है कि आप इन models की non-determinism को कैसे handle करते हैं। कभी ये tool call सही करते हैं, और कभी गलत JSON उगल देते हैं। क्या test suite कई बार retry करती है?

• tool calling की ambiguity तो frontier-scale models में भी देखने को मिलती है। मैं Claude Code, Codex और Gemini CLI को हर दिन parallel में development के लिए इस्तेमाल करता हूँ, और सबसे आम failure mode तब होता है जब grep/find exit code 1 के साथ खत्म होता है, यानी कोई match नहीं मिला
  model इसे “search चला और कुछ नहीं मिला” की तरह पढ़ने के बजाय “tool fail हो गया” मान लेता है, और हार मानने या search scope बढ़ाने के बजाय syntax थोड़ा बदलकर फिर retry करता है
  retry-nudge layer लगभग 1:1 उस चीज़ से मेल खाती है जो मैं खुद हर घंटे कई बार manually करता हूँ। जैसे, “नहीं, tool fail नहीं हुआ; उस file में वह pattern है ही नहीं। X करके देखो”
  framework level पर इसे encode करना सही दिशा लगती है
  क्या आपने यह भी देखा कि ऐसे guardrails लंबे tasks में छोटे frontier models और बड़े models के बीच का gap कम करते हैं? मेरा अंदाज़ा है कि Sonnet में 87→99 का फर्क शायद 50 steps से आगे वैसा नहीं रहेगा। उसके बाद context drift, retry semantics से ज़्यादा प्रभावी हो जाती है

  • कम-से-कम बड़े frontier models में तो वे उस बिंदु पर साफ़ तौर पर आगे रहते हैं। बस समय की कमी के कारण मैं उन नतीजों को formalize नहीं कर पाया
    एक ज़रूरी संकेत के तौर पर, forge तकनीकी रूप से model quality नहीं, बल्कि tool call execution में रुचि रखता है। असली जवाब यह है
    14B-क्लास छोटे models में limiting factor effective attention था। training context window के भीतर पर्याप्त होने पर भी, एक बिंदु के बाद performance गिरती दिखने लगती थी। मेरे पास सटीक संख्याएँ नहीं हैं, लेकिन Opus जैसे models उस बिंदु के बाद भी काफी देर तक बेहतर चलते रह सकते हैं
    मैंने tool call message history folding भी बनाई थी, जिसे शायद कभी forge में सीधे इस्तेमाल किया जा सके। मूल रूप से यह message history को बुद्धिमानी से tidy करता है ताकि model कम track खोए
    फिर भी, agentic coding harness की coding eval suite में refactoring tasks और feature-addition tasks शामिल हैं, और वे सब असली sandbox repositories में किए जाते हैं। छोटे models को भी 50~60 tool calls तक धकेलकर ऐसे tasks कराए जा सकते हैं। हालांकि, मैं शायद एक ही session में उन्हें ऐसे दो से अधिक काम नहीं दूँगा

• थोड़ा अलग विषय है, लेकिन अगर आप Texas Instruments में हैं, तो क्या आप यह पता लगा सकते हैं कि TI Explorer Lisp machine की intellectual property की स्थिति क्या हुई?
  मुझे पता है कि Genera की intellectual property किसके पास है, लेकिन TI के Lisp OS के बारे में मैं पता नहीं लगा पाया

  • Genera की intellectual property किसके पास है?

• जो लोग “agent safety” stack को थोड़ा व्यापक नज़रिए से देखते हैं, उनके लिए यह दिशा Kontext के kontext-cli(github.com/kontext-dev/kontext-cli) या OneCLI(github.com/onecli/onecli) जैसी चीज़ों के साथ complementary लगती है

• इसमें एक हिस्सा कहता है, “उसी Mistral-Nemo 12B weights ने llama-server के native function calling में 7% accuracy दी, जबकि Llamafile के prompt mode में 83%”
  मैं समझता था कि Llamafile तो बस model और llama.cpp को एक single binary में पैक करता है, तो क्या यह फर्क Llamafile द्वारा default system prompt inject करने और raw llama-server endpoint को बिना harness के call करने के बीच का है?
  यह मुझे सेब और apple pie की तुलना जैसा लगता है, जिसमें बीच की सामग्री गायब है

  • मैं भी चौंक गया था। लेख में extreme लेकिन वास्तविक examples दिए गए थे। इस मामले में संभावना है कि native function calling template ही काम कर गया हो
    लेकिन इससे Lamaserver prompt और llamafile के बीच लगभग +4%p का फर्क, या native llamaserver और llamafile के लगभग बीच में आने वाले Ollama के लगभग +30%p फर्क की व्याख्या नहीं होती
    serving backend ने लगभग हर model family को प्रभावित किया, और यह ऐसा हिस्सा था जिसके बारे में मैंने वास्तव में लगभग कोई चर्चा नहीं देखी थी

• यह सच में शानदार दिशा है। 1-bit bonsai models पर भी बेतुके स्तर तक अच्छे results मिल रहे हैं, और lmstudio के साथ भी यह बढ़िया काम करता है
  अब यह पूरी तरह यथार्थवादी लगता है कि कोई spare machine में 7900XTX लगाकर उसे basement में रख दे, कोई हास्यास्पद goal दे दे, और फिर उसे भूल जाए