Forge - เครื่องมือที่ยกระดับโมเดล 8B ในงานเอเจนต์จาก 53% เป็น 99% ด้วย guardrails

 (github.com/antoinezambelli)
1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Forge คือชั้นความน่าเชื่อถือสำหรับการเรียกใช้เครื่องมือของ LLM ที่โฮสต์เอง โดยมุ่งเพิ่มเสถียรภาพของโมเดลโลคัลขนาดเล็กในเวิร์กโฟลว์เอเจนต์หลายขั้นตอน
  • ความสามารถหลักประกอบด้วย rescue parsing สำหรับกู้คืนการเรียกใช้เครื่องมือที่ผิดพลาด, การกระตุ้นให้ลองใหม่, การบังคับขั้นตอนที่จำเป็น, งบประมาณโทเค็นที่รับรู้ VRAM และการบีบอัดคอนเท็กซ์แบบลำดับชั้น
  • ปัจจุบันคอนฟิกแบบโฮสต์เองที่ดีที่สุดคือ Ministral-3 8B Instruct Q8 บน llama-server ซึ่งทำได้ 86.5% ในสถานการณ์ประเมิน 26 แบบ และ 76% ในระดับที่ยากที่สุด
  • มีวิธีใช้งาน 3 แบบ: มอบหมายลูปเอเจนต์ทั้งหมดให้ WorkflowRunner, ใส่ Guardrails middleware เข้าไปในลูป orchestration เดิม, หรือใช้งานแบบโปร่งใสผ่านพร็อกซีเซิร์ฟเวอร์ที่เข้ากันได้กับ OpenAI
  • WorkflowRunner จัดการ system prompt, การรันเครื่องมือ, การบีบอัดคอนเท็กซ์ และ guardrails ส่วน SlotWorker เพิ่มคิวตามลำดับความสำคัญและความสามารถในการแย่งใช้ล่วงหน้าอัตโนมัติให้กับสล็อต inference GPU ที่ใช้ร่วมกัน
  • พร็อกซีเซิร์ฟเวอร์รันด้วย python -m forge.proxy และวางตัวอยู่ระหว่างไคลเอนต์ที่เข้ากันได้กับ OpenAI อย่าง opencode, Continue และ aider กับเซิร์ฟเวอร์โมเดลโลคัลเพื่อใช้ guardrails
  • พร็อกซีจะฉีดเครื่องมือสังเคราะห์ respond ให้อัตโนมัติในคำขอที่มีเครื่องมือ เพื่อให้โมเดลเรียก respond(message="...") แทนการส่งข้อความข้อความธรรมดา และจะลบสิ่งนี้ออกจากฝั่งตอบกลับเพื่อให้ไคลเอนต์เห็นเป็นการตอบข้อความปกติ
  • แบ็กเอนด์ที่รองรับได้แก่ Ollama, llama-server (llama.cpp), Llamafile และ Anthropic โดย llama-server ให้ประสิทธิภาพและการควบคุมสูงสุด, Ollama ตั้งค่าได้ง่าย, Llamafile รันได้ด้วยไบนารีเดียว และ Anthropic ใช้เป็นค่าฐานมาตรฐาน frontier และเวิร์กโฟลว์แบบไฮบริด
  • ติดตั้งได้ด้วย pip install forge-guardrails และเพิ่มไคลเอนต์ Anthropic ได้ด้วย pip install "forge-guardrails[anthropic]" โดยต้องใช้ Python 3.12+ และมี LLM backend ที่กำลังรันอยู่
  • evaluation harness ใช้ 26 สถานการณ์เพื่อวัดเสถียรภาพของการเรียกใช้เครื่องมือหลายขั้นตอนของชุดโมเดลและแบ็กเอนด์ โดยแบ่งเป็นระดับอ้างอิง OG-18 และระดับ advanced_reasoning อีก 8 ระดับ
  • ชุดทดสอบประกอบด้วย unit test แบบกำหนดผลตายตัว 865 รายการที่ไม่ต้องใช้ LLM backend และ evaluation harness สำหรับทดสอบกับแบ็กเอนด์จริง
  • เฟรมเวิร์ก Forge guardrails และการศึกษา ablation study ได้รับการตีพิมพ์ใน Forge: A Reliability Layer for Self-Hosted LLM Tool-Calling และใช้ไลเซนส์ MIT

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2 시간 전
ความเห็นจาก Hacker News

  • ฉันชอบงานในสายนี้และคิดว่ามันมีประโยชน์ แต่จะเลี่ยง LLM แบบคลาวด์ และใช้โมเดลโลคัลขนาด 4B~30A3B เป็นหลัก
    เพราะงั้นถึงจะไม่ค่อยมีเซนส์เรื่องประสิทธิภาพหรือความแม่นยำของ LLM รุ่นใหม่ล่าสุด แต่คิดว่าตัวเองพอรู้ดีว่าระดับที่คาดหวังได้จากโมเดลโลคัลและคอขวดอยู่ตรงไหน
    ฉันอ่านบทความแบบคร่าวๆ แล้วดูบทคัดย่อ เห็นว่ามีการพูดถึงว่าการปรับง่ายๆ อาจทำให้เร็วขึ้นหรือช้าลงได้ 10 เท่า แต่ตัวชี้วัดและข้อมูลดูเหมือนจะโฟกัสที่ ความแม่นยำ แทบทั้งหมด ควรพูดถึงเรื่องความเร็วด้วย
    โดยเฉพาะกับเวิร์กโฟลว์แบบเอเจนต์และโมเดลโลคัล สำหรับฉันความแม่นยำของการเรียกฟังก์ชัน/เครื่องมือไม่ได้เป็นปัญหาใหญ่มาตั้งแต่ช่วง QwenCoder3 และตลอด 6~12 เดือนที่ผ่านมา ประเด็นหลักคือการจัดการบริบทกับผลกระทบด้านเวลา ถ้าเอเจนต์เปลี่ยนพรอมป์ต์บ่อย การเพิ่มประสิทธิภาพด้านเวลาอย่าง prompt caching ก็พัง
    ดูเหมือนจะมีการเพิ่มชั้นและ wrapper อย่าง guardrail กับการ retry เข้ามาด้วย ซึ่งโดยเฉพาะในโมเดลโลคัลสำหรับงานแบบเอเจนต์ อาจช้าจนใช้งานไม่ได้เพราะ latency
    ถ้าคุณพูดถึงเรื่องนี้ตรงๆ ไปแล้วก็ขออภัย แต่การพูดถึงผลกระทบด้านเวลามีน้อยมากจนรู้สึกเหมือนซ่อนหรือขยายขนาดการปรับปรุงจริง อยากรู้ประสบการณ์ด้านความเร็ว คนอื่นๆ ก็ไม่ค่อยยกประเด็นนี้ขึ้นมาเลยจนแอบกังวลว่าเป็นฉันที่ทำอะไรพลาด หรือจริงๆ แล้วทุกคนไม่ได้ใช้โมเดลโลคัลกันจริงจัง

  • ฉันพูดมาตลอดว่าถ้ามี harness ที่ดีพอ โมเดลโลคัลขนาดเล็กก็ทำได้ดีจนน่าทึ่ง
    ถ้าเป็นระบบที่ลองได้ทุกอย่าง ตราบใดที่กันไม่ให้มันปล่อยผลลัพธ์ผิดๆ ออกมาได้ มันก็จะตอบถูกได้ในที่สุด

    • ปัญหาคือคุณจะได้คุณภาพประมาณเดียวกับการให้เวลารุ่นน้องแบบไม่จำกัด แล้วบอกให้ลองไปเรื่อยๆ หลายวิธีจนกว่าจะไปถึงเป้าหมาย
      ถ้างานซับซ้อนพอ โมเดลรุ่นล่าสุดก็มีปัญหานี้เหมือนกัน และในโมเดลเล็กจะยิ่งถูกขยายให้ชัดขึ้น
    • ฉันชอบกรอบคิดแบบนั้น ตอนทำงานนี้ โมเดลเล็ก หลายตัวน่าประทับใจมาก
      ความสามารถในการให้เหตุผลก็ดีทีเดียว และหลายกรณีก็เพียงพอ แค่ต้องช่วยดันกลับเข้าร่องเป็นครั้งคราว แล้วมันก็แก้ต่อเองได้
    • ถ้าฉันเข้าใจถูก เหตุผลที่โมเดลทำถูกได้คือมันรู้ตัวเมื่อมันผิด

  • ดีใจที่มีคนทำสิ่งที่ฉันอยากหาเวลาสร้างออกมาได้ดีกว่ามาก คำถามหนึ่งคือ อย่างเช่นใน ลูป retry มันมีโอกาสให้ทำขนานกันได้ไหม
    โมเดลโลคัลโดยทั่วไปแม้บนฮาร์ดแวร์ฝั่งผู้ใช้ก็มักรับคำขอพร้อมกันได้จำนวนจำกัด ระดับประมาณเลขสองหลัก และแบบนี้ทำให้ effective token/sec เพิ่มได้มากกว่า 10 เท่า
    ฉันคิดเรื่องเวิร์กโฟลว์ที่ใช้ประโยชน์จากจุดนี้มาสักพักแล้ว และงานประเภท “แก้ error นี้” ถึงจะไม่สมบูรณ์แบบก็น่าจะเป็นเคสใช้งานได้ อยากรู้ว่าคุณมองยังไง

  • ฉันมีไอเดียบางอย่างในพื้นที่นี้และกำลังใส่เข้ากับ harness ของตัวเองอยู่ แต่ harness ของฉันค่อนข้างเฉพาะทาง เลยไม่แน่ใจว่าจะ generalize ได้ไหม
    มันจะแยกปัญหาออกเป็นชุดการรันตามแผน และให้แผนเริ่มต้นที่มีเป้าหมายชัดเจน เช่น execution agent ควรเรียกเครื่องมืออะไร และเกณฑ์ของการรันที่สำเร็จคืออะไร จากนั้น harness จะรันตามแผนนั้นทีละขั้น
    ในแต่ละขั้นที่มีการเรียกเครื่องมือ มันจะแยกการเรียกเครื่องมือออกเป็นส่วนประกอบย่อย Harness จะถามเอเจนต์หาค่าพารามิเตอร์ที่ใช้ได้สำหรับอาร์กิวเมนต์ของเครื่องมือปัจจุบัน และในนิยามของเครื่องมือก็มี validator แยกตามอาร์กิวเมนต์แต่ละตัว ถ้าตรวจไม่ผ่าน harness จะย้อนบทสนทนาและใส่เหตุผลที่ล้มเหลวเข้าไปในการลองครั้งถัดไป
    ถ้าได้คำตอบที่ใช้ได้สำหรับอาร์กิวเมนต์นั้นแล้วก็จะไปตัวถัดไป และเมื่อกรอกครบทุกอาร์กิวเมนต์ก็จะเรียกใช้เครื่องมือ จากนั้นจะส่งทั้งค่าที่เอเจนต์คาดไว้แต่แรก ค่าจริง และ error ที่เกิดขึ้นไปพร้อมกัน แล้วถามว่าพอใจกับผลลัพธ์ไหม
    ถ้าไม่พอใจ เอเจนต์จะอธิบายเหตุผล และ harness จะย้อนบทสนทนา ใส่เหตุผลของการ retry แล้วเริ่มกระบวนการเรียกเครื่องมือใหม่ทั้งหมดตั้งแต่ต้น
    ถ้าเอเจนต์พบข้อบกพร่องในแผนเริ่มต้น ก็สามารถขอ replan ได้ และถ้า harness เห็นว่าล้มเหลวต่อเนื่องมากเกินไป ก็จะลอง replan เหมือนกัน
    วิธีนี้ได้ผลค่อนข้างดีในการลด ความล้มเหลวของการเรียกเครื่องมือ ข้อดีอย่างหนึ่งคือ sub-agent จะได้รับประวัติบทสนทนาที่สมบูรณ์แบบไร้ข้อผิดพลาด แต่ฉันยังไม่ได้ benchmark ว่าอัตราการทำงานสำเร็จจริงๆ ดีขึ้นหรือไม่

    • ฉันก็เคยทดลองด้วยแนวคิดคล้ายกันใน coding harness แบบเอเจนต์ที่ใช้โมเดลเล็ก และสร้างมันไว้บน forge
      เรื่องการย้อนบทสนทนา ฉันทำ การพับการเรียกเครื่องมือ แบบคล้ายกันกับเอเจนต์หลัก ซึ่งก็คือเอเจนต์ที่คุยกับผู้ใช้ พองานจบก็จะพับประวัติการเรียกเครื่องมือเพื่อให้บริบทสะอาดขึ้น ซึ่งใกล้เคียงกับเรื่อง hygiene มากกว่าเรื่องขนาด
      ส่วนที่ harness คอยไล่ถามโมเดลนั้นต่างออกไปนิดหน่อย และฉันยังไม่ได้ลองแนวทางนั้น Forge พึ่งการแก้ไขตัวเองของโมเดลเพื่อเลี่ยงโหมด error แบบเฉพาะทาง แต่ถ้าสามารถทำ abstraction และ automation ของกระบวนการถามโดยอิงจากสิ่งอย่าง schema ได้ ก็ดูน่าจะเป็นไปได้
      โดยรวมแล้วฉันชอบมุมของประวัติบทสนทนาที่สะอาด แต่กับเครื่องมือที่มีอาร์กิวเมนต์เยอะ มันดูมีโอกาสเกิดการโต้ตอบไปกลับมากกว่า “ปล่อยให้พลาดไปก่อนแล้วค่อยช่วยดันทีเดียว” ถึงอย่างนั้นก็เป็นไอเดียที่น่าสนใจสำหรับสถานการณ์หรืองานที่ยากกว่า
    • ฉันใช้ Strix Halo และเพราะมันช้ากับบริบทที่ยาว ฉันก็คิดถึงแนวทางเดียวกันอยู่ วิธีนี้น่าจะช่วยคง บริบทต่ำกว่า 10,000 โทเคน ได้
      ถ้ากับโมเดลเล็กทำได้เกิน 50k token/sec ก็น่าจะมีนัยสำคัญมาก
      แต่ตอนนี้ฉันติดงานบริษัทกับโปรเจกต์อื่นอยู่ เลยเพิ่งลองแค่พรอมป์ต์ไม่กี่สิบอันเพื่อดูว่าทำได้ไหม
    • ด้วยความอยากรู้อยากเห็น ฉันกำลังทำของตัวเองด้วย gemma4 และก็แปลกใจที่มันไปได้ไกลกว่าที่คิดมาก

  • ยอดเยี่ยมมาก ตอนนี้ฉันยังใช้ local inference ไม่ได้เพราะต้นทุน แต่ตอนใช้โมเดลเล็กผ่าน OpenRouter ฉันก็กังวลเรื่องการเรียกเครื่องมืออยู่
    ฉันกำลังทำเฟรมเวิร์กทดสอบอาร์กิวเมนต์แบบ pytest-first ชื่อ Dokimasia (do-kee-ma-see-ah) และอยากฟังความเห็น: https://github.com/deevus/dokimasia
    การทดสอบอาร์กิวเมนต์อาจไม่ใช่สิ่งที่ Forge ต้องการ แต่เพราะคุณกำลังสร้างเครื่องมือ AI แบบลึกๆ เลยคิดว่าน่าจะมีมุมมองบางอย่าง

    • เป็นไอเดียที่น่าสนใจ ดูเหมือนโดยแก่นแล้วมันคือการทำให้ ชั้น abstraction สำหรับการทดสอบการเชื่อมต่อหลายแบบใน ecosystem ของ AI อย่าง MCP หรือ skills กลายเป็นทางการ
      มันดูอยู่เหนือ Forge ขึ้นไปอีกชั้น และใกล้กับการทดสอบเวิร์กโฟลว์จริงกับจุดเชื่อมต่อที่โผล่ออกมาในนั้น เช่น เครื่องมือไหนให้การเข้าถึงแบบ MCP
      การใช้ทั้งสองอย่างซ้อนกันก็คงไม่ใช่ปัญหาใหญ่
      สิ่งที่ฉันสงสัยคือคุณจัดการกับ ความไม่กำหนดแน่นอน ของโมเดลพวกนี้ยังไง บางครั้งมันเรียกเครื่องมือได้ถูกต้อง บางครั้งก็พ่น JSON ผิดๆ ออกมา ชุดทดสอบมีการลองหลายรอบไหม?

  • ฉันเจอความกำกวมของการเรียกเครื่องมือแบบนี้แม้กับโมเดลระดับแนวหน้าด้วยซ้ำ ฉันใช้ Claude Code, Codex และ Gemini CLI ทำงานพัฒนาแบบขนานทุกวัน และโหมดล้มเหลวที่เจอบ่อยที่สุดคือ grep/find จบด้วย exit code 1 ซึ่งหมายถึงไม่มีสิ่งที่ตรงกัน
    โมเดลกลับอ่านว่ามันคือ “เครื่องมือล้มเหลว” แทนที่จะเป็น “การค้นหาทำงานแล้วแต่ไม่เจอ” แล้วก็ยอมแพ้ หรือไม่ก็ retry ด้วยการเปลี่ยน syntax นิดหน่อยแทนที่จะขยายขอบเขตการค้นหา
    ชั้น retry-nudge แทบจะตรง 1:1 กับสิ่งที่ฉันทำเองด้วยมือหลายครั้งต่อชั่วโมงอยู่แล้ว ประมาณว่า “ไม่ใช่ เครื่องมือไม่ได้พัง แต่ไฟล์นั้นไม่มีแพตเทิร์นนี้ ลองทำ X ดู”
    มันดูเหมือนเป็นทิศทางที่ถูกต้องที่จะ encode สิ่งนี้ในระดับเฟรมเวิร์ก
    ฉันสงสัยว่าคุณได้ดูไหมว่า guardrail แบบนี้ช่วยลดช่องว่างกับโมเดลแนวหน้าขนาดเล็กในงานยาวๆ ได้หรือเปล่า สัญชาตญาณฉันบอกว่าความต่าง Sonnet จาก 87→99 คงไม่คงอยู่แบบเดิมเมื่อเกินราว 50 ขั้นตอน เพราะหลังจากนั้น context drift จะเด่นกว่าความหมายของการ retry

    • อย่างน้อยกับโมเดลแนวหน้าขนาดใหญ่กว่า มันนำหน้าอยู่ตรงนั้นชัดเจนแน่นอน เพียงแต่เพราะเรื่องเวลา ฉันยังไม่ได้ทำผลลัพธ์ให้เป็นทางการ
      เพื่อเป็นเบาะแสที่จำเป็น forge สนใจเชิงเทคนิคที่การรันการเรียกเครื่องมือ ไม่ใช่คุณภาพของโมเดล คำตอบจริงคือแบบนี้
      สำหรับโมเดลเล็กระดับ 14B ปัจจัยจำกัดคือ effective attention ถึงจะยังอยู่ในขนาดหน้าต่างบริบทที่ใช้ฝึกมา แต่พอเกินจุดหนึ่งก็เริ่มเห็นประสิทธิภาพตก ฉันไม่มีตัวเลขเป๊ะๆ แต่โมเดลอย่าง Opus ไปต่อได้นานกว่ามากที่จุดนั้น
      ฉันยังทำฟีเจอร์พับประวัติข้อความการเรียกเครื่องมือไว้ด้วย ซึ่งวันหนึ่งอาจเอามาใช้กับ forge โดยตรงได้ มันคือการจัดระเบียบประวัติข้อความอย่างชาญฉลาดเพื่อลดการที่โมเดลหลุดติดตาม
      ถึงอย่างนั้น ในชุดประเมินงานเขียนโค้ดของ harness แบบเอเจนต์ ก็มีทั้งงาน refactor และงานเพิ่มฟีเจอร์ ซึ่งทั้งหมดทำใน sandbox repository จริง โมเดลเล็กก็ยังทำงานพวกนั้นได้ โดยถูกดันไปถึง การเรียกเครื่องมือ 50~60 ครั้ง เพียงแต่ฉันคงไม่อยากมอบหมายงานแบบนั้นมากกว่าสองงานในเซสชันเดียวกัน

  • เปลี่ยนเรื่องนิดหน่อย แต่ถ้าคุณอยู่ที่ Texas Instruments ฉันสงสัยว่าคุณพอจะตรวจสอบสถานะทรัพย์สินทางปัญญาของ TI Explorer Lisp machine ได้ไหม
    ฉันรู้ว่าใครเป็นเจ้าของทรัพย์สินทางปัญญาของ Genera แต่หาไม่เจอเลยว่าสำหรับ Lisp OS ของ TI เป็นอย่างไร

    • ใครถือครองทรัพย์สินทางปัญญาของ Genera?

  • สำหรับคนที่มองสแตก “agent safety” ให้กว้างขึ้น ทิศทางนี้ให้ความรู้สึกว่า เสริมกันได้ กับสิ่งอย่าง Kontext no kontext-cli(github.com/kontext-dev/kontext-cli) หรือ OneCLI(github.com/onecli/onecli)

  • มีส่วนที่บอกว่า “น้ำหนัก Mistral-Nemo 12B ตัวเดียวกัน มีความแม่นยำ 7% ใน native function calling ของ llama-server แต่ได้ 83% ใน prompt mode ของ Llamafile”
    ฉันเคยคิดว่า Llamafile ก็แค่แพ็กโมเดลกับ llama.cpp เป็นไบนารีเดียว ความต่างนี้คือความต่างระหว่างการที่ Llamafile inject system prompt ตั้งต้น กับการเรียก raw llama-server endpoint โดยไม่มี harness ใช่ไหม?
    นี่ดูเหมือนการเปรียบเทียบแบบ แอปเปิลกับแอปเปิลพาย และมีส่วนผสมตรงกลางหายไป

    • ฉันก็แปลกใจเหมือนกัน ในบทความยกตัวอย่างที่ดูสุดโต่งแต่เกิดขึ้นจริง ในกรณีนี้มีโอกาสสูงว่า native function calling template จะทำงาน
      แต่นั่นก็ยังอธิบายความต่างราว +4%p ระหว่าง prompt ของ Lamaserver กับ llamafile หรือความต่างราว +30%p ของ Ollama ซึ่งอยู่เกือบกึ่งกลางระหว่าง llamaserver native กับ llamafile ไม่ได้
      serving backend ส่งผลกับแทบทุกตระกูลโมเดล และแทบไม่เคยเห็นใครพูดถึงส่วนนี้เลยจริงๆ

  • นี่เป็นทิศทางที่ยอดเยี่ยมจริงๆ แม้แต่กับ bonsai model แบบ 1-bit ก็ได้ผลดีเกินคาด และยังเข้ากับ lmstudio ได้ดีด้วย
    ตอนนี้การเสียบ 7900XTX เข้ากับเครื่องเหลือใช้ เอาไปวางไว้ชั้นใต้ดิน แล้วโยนเป้าหมายเพี้ยนๆ ใส่มันก่อนจะลืมไปเลย กลายเป็นเรื่องที่เป็นจริงได้เต็มตัวแล้ว