การเรียกฟังก์ชันของ LLM ไม่สามารถขยายสเกลได้; การออร์เคสตราด้วยโค้ดนั้นง่ายกว่าและมีประสิทธิภาพกว่า

 (jngiam.bearblog.dev)
8 คะแนน โดย GN⁺ 2025-05-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • วิธีที่ให้ LLM ประมวลผลผลลัพธ์ทั้งหมดจากการเรียกใช้ทูลนั้นช้า มีต้นทุนสูง และไม่เหมาะกับการขยายสเกล
  • ทางเลือกที่เสนอคือให้ LLM ทำหน้าที่ออร์เคสตรา โดย จัดการข้อมูลแบบมีโครงสร้างตาม output schema ด้วยโค้ด
  • แนวทางนี้ เหมาะกับการประมวลผลข้อมูลปริมาณมากผ่านการเชื่อมต่อฟังก์ชันด้วยโค้ดและการจัดการหน่วยความจำด้วยตัวแปร
  • แนวทางประมวลผลข้อมูลบนฐานการรันโค้ด มีความแม่นยำและขยายสเกลได้ดี เพราะ LLM ไม่ต้องสร้างข้อมูลขึ้นมาใหม่โดยตรง
  • การสร้างสภาพแวดล้อม AI runtime ที่ปลอดภัยกำลังกลายเป็นโจทย์ใหม่ และต้องการสภาพแวดล้อมการรันที่ยั่งยืนและคงสถานะได้

LLM function calls don't scale; code orchestration is simpler, more effective.

ข้อจำกัดของวิธีเดิมที่ส่งผลลัพธ์จากการเรียกทูลกลับเข้าไปให้ LLM อีกครั้ง

  • เมื่อใช้ทูล MCP(Machine Context Protocol) โดยทั่วไปจะส่งผลลัพธ์จากทูลให้ LLM ในรูปข้อความเพื่อชี้นำการดำเนินการถัดไป
  • ในกรณีใช้งานจริง MCP server ของ Linear และ Intercom จะส่งกลับ คำตอบ JSON ขนาดใหญ่
  • JSON มีลักษณะคล้าย API แต่ ไม่มี output schema ที่กำหนดไว้ ทำให้ LLM ต้องแบกรับภาระในการ parse ข้อความทั้งหมด
  • ตัวอย่างเช่น ผลลัพธ์การดึงรายการ issue ของ Linear มีขนาด 70,000 อักขระสำหรับ 50 รายการ หรือราว 25,000 โทเค็น ซึ่งใหญ่มาก
  • ฟิลด์ id จำนวนมากแทบไม่มีความหมายแต่กินโทเค็น และ หาก LLM ต้องสร้างสิ่งเหล่านี้ซ้ำตามเดิม ต้นทุนและความผิดพลาดจะยิ่งสูงขึ้น

ความจำเป็นในการแยกการประมวลผลข้อมูลออกจากการออร์เคสตรา

  • วิธีปัจจุบันคือการ ผสมการประมวลผลข้อมูลและการออร์เคสตราไว้ในแชตเซสชันเดียวกัน
  • บางส่วนแก้ปัญหานี้ด้วยการสร้างเธรดอื่นในรูปแบบ "agent" แต่เมื่อ JSON มีโครงสร้างอยู่แล้ว วิธีนี้กลับไม่มีประสิทธิภาพ
  • วิธีที่ดีกว่าคือ ประมวลผลข้อมูลแบบมีโครงสร้างด้วยโค้ดโดยตรง
    • ตัวอย่าง: การจัดเรียง issue ไม่จำเป็นต้องให้ LLM สร้างผลลัพธ์เอง แต่ให้รัน sort ด้วยโค้ดแล้วส่งกลับเฉพาะอาร์เรย์ผลลัพธ์

การประมวลผลข้อมูลบนฐานการรันโค้ด

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

แนวคิดหลัก

  • ใช้ตัวแปรเป็นหน่วยความจำ: กำหนดค่า = จัดเก็บ, แสดงผล = เรียกดู, ส่งต่อเป็นอาร์กิวเมนต์เมื่อเรียกฟังก์ชัน
  • รองรับการเชื่อมต่อฟังก์ชัน: ผสานการเรียกหลายฟังก์ชันแบบ ขนาน/ลำดับ และแสดงความสัมพันธ์แบบพึ่งพากันผ่านลำดับการไหลของโค้ดอย่างเป็นธรรมชาติ
  • ประมวลผลข้อมูลจำนวนมากได้อย่างขยายสเกล: เมื่อนำไปรวมกับ NumPy, pandas เป็นต้น ก็สามารถจัดการข้อมูลหลักพันถึงหลักหมื่นรายการได้ง่าย
  • สามารถเรียก LLM อื่นเพิ่มเติมได้: ภายในโค้ดที่ LLM เขียนยังสามารถเรียก LLM อื่นเพื่อ จัดการข้อมูลแบบไม่มีโครงสร้าง ได้

MCP พร้อมแล้วหรือยัง?

  • สเปกของ MCP มีการกำหนด input schema ไว้อยู่แล้ว และล่าสุดก็มีการยื่น PR สำหรับ output schema ด้วย
  • หาก output schema กลายเป็นมาตรฐานทั่วไป ก็จะสามารถนำไปใช้ได้ในลักษณะต่อไปนี้:
    • แดชบอร์ดสถานะ issue
    • รายงานตั๋วที่เสร็จสิ้นประจำสัปดาห์
    • ให้ AI ติดตามตั๋วที่ค้างนิ่งและส่งการแจ้งเตือนแบบ push

ความท้าทายของสภาพแวดล้อมการรันโค้ด

  • ความปลอดภัยคือประเด็นหลัก: เพราะต้องรันโค้ดที่ AI/ผู้ใช้สร้างขึ้น จึง จำเป็นต้องออกแบบเพื่อป้องกันการเปิดเผย API key และข้อมูล
  • ในกรณีของ Lutra สภาพแวดล้อมการรันถูกออกแบบแบบ sandbox และให้เอกสารการเรียก API แก่โมเดลเท่านั้น
  • สภาพแวดล้อมการรันแบบคงสถานะ (เช่น Jupyter) มีต้นทุนสูง และสำหรับเซสชันระยะยาวจำเป็นต้องมีคุณสมบัติ stateless + persistent
  • สิ่งนี้กำลังก่อรูปเป็นหมวดหมู่ใหม่ของ AI runtime และยังอยู่ในช่วงที่มีการออกแบบอย่างคึกคัก

บทสรุป

  • วิธีเดิมที่นำผลลัพธ์จากการเรียกทูลไปให้ LLM ประมวลผลต่อมี ข้อจำกัดทั้งด้านต้นทุนและความแม่นยำ
  • การออร์เคสตราบนฐานโค้ดทำให้เกิดการประมวลผลที่ กระชับ ขยายสเกลได้ และแม่นยำ
  • สภาพแวดล้อมรันโค้ด AI กำลังได้รับความสนใจในฐานะ runtime ยุคถัดไปที่ต้องมี ความปลอดภัย ความคงทน และความสามารถในการขยายสเกล

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

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

 
GN⁺ 2025-05-23
ความคิดเห็นจาก Hacker News
  • แชร์ประสบการณ์ที่ตลอด 2 ปีที่ผ่านมาได้ยืนยันว่า "เอเจนต์ที่พัฒนาก้าวหน้ามากพอย่อมแยกไม่ออกจาก DSL" โดยมองว่าแทนที่จะบังคับให้เอเจนต์ซึมซับอัลกอริทึมเข้าไปภายใน การสอน API และขอให้ออกแบบอัลกอริทึมที่ใช้ API นั้น แล้วนำไปรันใน user space เหมาะสมกว่ามาก เชื่อว่าการยัดอัลกอริทึมเข้าไปใน LLM นั้นไม่มีประสิทธิภาพ ยกเว้นบางกรณีมาก ๆ เท่านั้น (ในแง่ต้นทุนหรือความแม่นยำ) พร้อมเปรียบเทียบว่าไม่ต่างจากการขอให้นักพัฒนารันฟังก์ชันอยู่ในหัว
    • ตีความว่านี่เป็นหลักฐานว่าเส้นทางไปสู่ ASI (ปัญญาประดิษฐ์ทั่วไป) ไม่ได้อยู่ที่การขยายความสามารถของ LLM แต่กลับอยู่ที่การดึงและคอมไพล์อัลกอริทึมการพัฒนาตัวเองจากภายนอกให้อยู่ในรูป symbolic application
    • ขอหลักฐานหรือกรณีตัวอย่างว่ามีการใช้คำว่า 'agent' อย่างแพร่หลายในบริบทนี้มาตั้งแต่ 2 ปีก่อนจริงหรือไม่
  • ประสบการณ์สร้างระบบ agentic สำหรับธุรกิจอีคอมเมิร์ซของตัวเองโดยตรง เคยประเมิน smolagents แล้วพบว่ามันสง่างามและน่าสนใจ แต่มีข้อเสียคือเพิ่มความซับซ้อนของระบบอย่างมาก เหมาะสมอย่างยิ่งกับสภาพแวดล้อมที่ต้องจัดเรียงและสรุปข้อมูลแบบไม่มีสคีมา เช่น dynamic reporting แต่สำหรับงานส่วนใหญ่ถือว่าเกินความจำเป็น Gemini และ OpenAI มีความสามารถด้าน Python interpreter ที่ครอบคลุมงานส่วนใหญ่ของ code agent ได้อยู่แล้ว แนวทางที่คอยกองข้อความเรียกใช้ทูลลงในสแตกแบบไม่สิ้นสุดนั้นขยายต่อได้ยากจึงไม่แนะนำ เวิร์กโฟลว์ agentic จริง ๆ มีอายุสั้น และจัดการความซับซ้อนด้วยโครงสร้างและวินัย บทเรียนจากการพัฒนาซอฟต์แวร์แบบเดิมเรื่องการควบคุมสเกลของ function calling และป้องกันความสับสนยังคงเหมือนเดิม หัวใจของการสร้างระบบที่ดีคือการจัดการภาระทางความคิดของนักพัฒนา และโซลูชันที่เรียบง่ายแต่ทำงานได้ดีมักเหนือกว่าวิธีที่แพรวพราวแต่ซับซ้อน การผสม function calling เข้าด้วยกันเป็นตัวอย่างของโซลูชันเรียบง่ายเช่นนี้ และการจัดการข้อมูลแบบมีโครงสร้างก็ใช้วิธี parsing/transform แบบดั้งเดิมได้เพียงพอ เมื่อโครงสร้างยังไม่แน่นอน โมเดลราคาถูกก็ยังทำ parsing ได้ยอดเยี่ยม สุดท้ายแล้วการจัดการความซับซ้อนของระบบ agentic สรุปได้ว่าเป็นปัญหาเรื่องการจัดการ application state อย่างละเอียด สามารถจัดองค์ประกอบ active context ที่จะป้อนให้โมเดลได้อย่างยืดหยุ่นผ่านการจัดการ message stack ซึ่งคล้ายกับการจัดการหน่วยความจำในสภาพแวดล้อมที่มีข้อจำกัด
    • เป็นบทสรุปที่ชี้ trade-off ของระบบ agentic ได้อย่างแม่นยำ เราเองก็เจอปัญหาเดียวกันขณะสร้างโซลูชันค้นหาสินค้าแบบสนทนาสำหรับอีคอมเมิร์ซ (IsarTech) การประกอบฟังก์ชันและข้อมูลแบบมีโครงสร้างคือหัวใจของการควบคุมความซับซ้อน จากประสบการณ์ การส่งออกโดยอิง type schema ที่ชัดเจนช่วยยกระดับความสามารถในการขยายของการเรียกใช้ทูลได้อย่างมาก ด้วย type schema จึงสามารถควบคุมทั้งภาระทางความคิดและความซับซ้อนของระบบได้ พึ่งพาพฤติกรรมแบบกำหนดแน่นอนได้ให้มากที่สุด และใช้ LLM เฉพาะเมื่อมีข้อมูลไร้สคีมาหรือความกำกวม LLM มีประสิทธิภาพมากในการแมปคำขอที่กำกวมไปสู่ระบบแบบกำหนดแน่นอน อย่างไรก็ตาม ต้องรักษาสมดุลระหว่างการลดความซับซ้อนจากอินพุต high-entropy (ไร้โครงสร้าง) กับการเพิ่มความซับซ้อนผ่านสายโซ่ของการเรียกใช้ทูล ในสภาพแวดล้อมคอมเมิร์ซจริง ใช้วิธีใดวิธีหนึ่งเพียงอย่างเดียวได้ยาก และ structured output ก็มีข้อจำกัดเมื่อเจอเจตนาที่กำกวม จึงต้องมีกลยุทธ์เสริม
  • มีข้อสังเกตว่าปัญหาไม่ใช่ function calling เอง แต่เป็นการออกแบบและวิธีใช้ MCP MCP ส่วนใหญ่เป็นแค่การทำซ้ำของ API และมีปัญหาปล่อยข้อมูลไร้ความหมาย มีการซ้อนฟอร์แมต JSON แบบซ้ำ ๆ จนกิน input context โดยไม่จำเป็นและมีข้อมูลไม่เกี่ยวข้องจำนวนมาก จึงควรปรับให้เหมาะสมด้วยการ flatten ข้อมูลและลบฟิลด์ที่ไม่จำเป็น MCP SaaS สุดท้ายก็เป็นเพียง API gateway ปัจจุบัน MCP เป็นตัวการหลักของ noise และยังไม่ได้รับการปรับแต่งดีพอ
    • GraphQL คือเทคโนโลยีที่เหมาะกับจุดประสงค์นี้อย่างยิ่ง เพราะออกแบบมาให้เลือกเฉพาะฟิลด์ที่ต้องการได้ มีการพัฒนา Gateway แบบโอเพนซอร์สที่แปลง GraphQL query หลายชุดให้เป็น MCP server เดียว
    • มีการตั้งข้อสงสัยว่าปัญหาอาจไม่ใช่โมเดลทำตาม JSON schema ที่ซับซ้อนไม่ได้หรือไม่
    • MCP อาจไม่ช่วย แต่การกรองออกทั้งหมดก็ไม่ใช่ทางออกที่ดีที่สุดเสมอไป บางครั้งเอเจนต์จำเป็นต้องประมวลผลข้อมูลจำนวนมาก ในกรณีนี้ การรันโค้ดที่มีทั้งการประเมินข้อมูลง่าย ๆ และคำอธิบายสคีมาเป็นแนวทางที่ขยายได้ดีกว่า แน่นอนว่าเมื่อระบบใหญ่เกินไป ปัญหาคล้ายกันก็จะเกิดขึ้น ทางออกสูงสุดคือการจำลองความแม่นยำระดับการคิดเชิงกำหนดแน่นอนของมนุษย์ด้วยโค้ด แล้วให้ LLM เรียกระบบตัดสินใจนี้ แม้ในทางทฤษฎีจะดูง่าย แต่เน้นว่านำไปทำจริงยากมาก
    • ตอนทดสอบการกลับสตริงด้วย ChatGPT รู้สึกว่ายากมากที่จะทำให้ LLM ให้เพียงผลลัพธ์ง่าย ๆ และความน่าเชื่อถือก็ต่ำ หลังจากประสบการณ์นั้นจึงติดนิสัยให้หลาย LLM ช่วยตรวจสอบเสมอ พร้อมแซวว่าถ้าเป็นแบบนี้ต่อไปอาจต้องเตรียมศูนย์ข้อมูล GPU เองเพื่อจะนับจำนวนอักขระในสตริงธรรมดา
  • ทีม Shopify เพิ่งโอเพนซอร์ส Roast เมื่อไม่นานมานี้ เป็นเครื่องมือที่สามารถแทรกงาน LLM แบบไม่กำหนดแน่นอนเข้าไปในเวิร์กโฟลว์เพื่อทำงานอัตโนมัติกับโค้ดเบสขนาดใหญ่ ซึ่งจำเป็นต่อการทำงานอัตโนมัติที่ซับซ้อน
    • ประทับใจ Roast มาก โดยเฉพาะการผสานระหว่างความกำหนดแน่นอนและไม่กำหนดแน่นอน ยังสับสนเล็กน้อยว่า LLM จะ orchestration การเรียกใช้ทูลหลายตัวและตัดสินลำดับการเรียกอย่างไร ดูเหมือนจะทำงานได้เวลาสั่ง refactor แต่สงสัยว่าเหมาะกับงานผสมอย่าง "ปรับปรุง→ทดสอบซ้ำ" หรือไม่
    • รู้สึกสดใหม่ที่ Ruby ยังทำงานได้อย่างมีความหมายอย่างต่อเนื่องแม้ในยุค AI
    • เป็นแนวทางที่ยอดเยี่ยมจนแค่อ่านเอกสารก็ชวนกระตุ้นความคิด ประทับใจที่แพ็กเกจความสามารถของ LLM ในรูปแบบ declarative
    • ขอให้แชร์กรณีตัวอย่างที่เฉพาะเจาะจงว่าเวิร์กโฟลว์แบบนี้ถูกใช้งานจริงภายใน Shopify อย่างไร
    • เคยทำให้ทั้ง Claude Code Research Preview และ ChatGPT 4.5 Pro Deep Research ล่มมาแล้ว (และมีหลักฐานด้วย) จึงกำลังมองหาเครื่องมือที่ทำงานได้แน่นอน
  • คำตอบที่ดีที่สุดอยู่ที่แนวทางไฮบริด ไม่ใช่สุดโต่งไปด้านใดด้านหนึ่ง มองว่าควรแก้ปัญหาให้ได้มากที่สุดด้วยวิธีแบบกำหนดแน่นอน และใช้ LLM กับส่วนที่ซับซ้อนซึ่งยากต่อการทำเป็นสเปกหรือเทคนิคแบบกำหนดแน่นอน
    • การใช้ LLM เพื่อเน้นสร้างโซลูชันแบบกำหนดแน่นอน (โค้ด) และเมื่อโค้ดนั้นผ่านการตรวจสอบแล้วก็นำกลับมาใช้เป็นโค้ดแบบกำหนดแน่นอนต่อไป เป็นแนวทางที่น่าสนใจ
    • มีความเห็นว่าควรพยายามลดการใช้ LLM ภายในเวิร์กโฟลว์ให้เหลือน้อยที่สุด
  • รู้สึกประหลาดใจที่ในช่วงเวลาแค่กว่าหนึ่งปีที่ออกจากวงการไป การทดลองที่ซับซ้อนเช่นนี้ดูเหมือนจะกลายเป็นเรื่องปกติแล้ว
    • ในความเป็นจริงยังมีเพียงคนส่วนน้อยที่กำลังทดลองอยู่ และยังไม่มีกรณีปฏิวัติวงการ แต่ก็มีบางกรณีที่มีประโยชน์
    • อีกความเห็นหนึ่งบอกว่าถ้าตอนนี้ไม่ทำงานแบบนี้ อีกไม่นานก็คงต้องออกจากวงการอีกครั้ง
    • งานประจำวันของตัวเองตอนนี้เอนเอียงไปที่การออกแบบและทำ automation สำหรับ AI agent บน LLM แล้ว โดยไม่ได้ตั้งใจแต่ก็กลายเป็นแบบนั้นไปเอง
  • สงสัยว่าทำไมถึงใช้ LLM กับการจัดเรียงข้อมูลแบบมีโครงสร้าง
    • เป้าหมายหลักคือการประมวลผลข้อมูลที่ซับซ้อนกว่า เช่น การสร้างแดชบอร์ด การระบุ issue ticket อัตโนมัติ และ quarterly review โดยการจัดเรียงเป็นเพียงตัวอย่างง่าย ๆ ที่ช่วยให้เข้าใจขนาดของปัญหาได้เท่านั้น
  • huggingface smolagent เป็นตัวอย่างเด่นของแนวทางนี้ แต่ก็มาพร้อมปัญหาว่าเมื่อการทำงานล้มเหลวแล้ว การ rollback หรือกู้คืนจริงทำได้ยากมาก แม้จะมีทางแก้ในหลักการ เช่น ครอบ execution block ทั้งหมดด้วย distributed transaction แต่ในทางปฏิบัติ LLM มักพยายามสร้างโค้ดที่ทนทานจนไม่เข้ากับแพตเทิร์นนี้ ทำให้ติดตามข้อผิดพลาดและหาสาเหตุการล้มเหลวได้ยาก
    • เห็นด้วยว่าไอเดียพื้นฐานของ smolagent นั้นดี แต่ปัญหาคือความจริงของการรันและการจัดการข้อผิดพลาด เช่น เมื่อการรันโค้ดหยุดกลางทาง ก็อยากให้สามารถทำต่อจากสถานะนั้นได้ทันที ได้ยืนยันแล้วว่า LLM เขียนโค้ดกู้คืนสถานะได้ดี และตอนนี้ฟีเจอร์ลักษณะนี้ก็ทำงานได้ค่อนข้างดีในผลิตภัณฑ์จริง (Lutra)
  • อีกแนวทางหนึ่งคือชี้นำให้ LLM เขียนโค้ดที่เรียก MCP เสมือนเป็นฟังก์ชัน (ในรูปสคริปต์ Python) พร้อมแชร์โค้ดตัวอย่าง
    • แนะนำ Lutra.ai ในฐานะกรณีใช้งานจริงของวิธีนี้ โดยหัวใจอยู่ที่การออกแบบ code runtime ให้ดีเพียงใด
  • ข้อเท็จจริงที่ว่า LLM อ่อนกับ JSON โดยเฉพาะ JSON ขนาดใหญ่ endpoint จึงไม่จำเป็นต้องคืนข้อมูลเป็น JSON เสมอไป LLM อาจทำงานกับ xml ได้ดีกว่ามาก และยังสามารถใช้เทมเพลตสร้างเป็นข้อความเชิงบรรยายได้ด้วย
    • XML เป็นฟอร์แมตที่มีข้อมูลเชิงความหมายในตัว จึงน่าแปลกใจที่ไม่ได้ถูกใช้เป็นค่าเริ่มต้นกับ LLM อย่างแพร่หลาย หากจำเป็น สามารถแปลง XML เป็น JSON แบบกำหนดแน่นอนแล้วส่งเข้าพายป์ไลน์ได้อย่างมีประสิทธิภาพ
    • มีประสบการณ์ว่าเมื่อคืนข้อมูลให้ LLM ในรูปตารางมาร์กดาวน์ ได้ผลค่อนข้างดี
    • สงสัยว่าเหตุที่ XML ให้ประสิทธิภาพดีกว่า เป็นเพราะปรากฏในข้อมูลฝึกของ LLM บ่อยกว่า หรือเพราะมีจำนวน text token มากกว่า พร้อมกล่าวว่าก้อนข้อความอาจให้บริบทกับ LLM ได้มากกว่า