กระบวนการย้าย AI Agent สำหรับโปรดักชันไปใช้ GPT-5.6 จนเร็วขึ้น 2.2 เท่าและถูกลง 27%

 (ploy.ai)
1 คะแนน โดย GN⁺ 7 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Ploy ย้าย agent ที่วางแผน สร้าง และตรวจสอบเว็บไซต์การตลาดสำหรับโปรดักชันจาก Claude Opus 4.8 ไปเป็น GPT-5.6 Sol และกำหนดเป็นโมเดลเริ่มต้นของทุกเวิร์กสเปซ
  • หลังแก้สมมติฐานเฉพาะโมเดลใน evaluation harness แล้ว งานสร้างหน้าโฮมเพจใหม่มีเวลาเฉลี่ยในการรันลดจาก 8 นาทีเหลือ 3 นาที 42 วินาที ค่าใช้จ่ายลดลง 27% จาก $3.06 เหลือ $2.22 และคะแนนด้านภาพเพิ่มเป็น 0.970
  • GPT-5.6 เติมพารามิเตอร์แบบ optional ทั้ง 25 รายการของ tool call ด้วยค่าที่สุ่มขึ้นมา ทำให้การอ่านไฟล์ 52~64% ส่งคืนผลลัพธ์ว่าง แต่เมื่อเปลี่ยนฟิลด์ optional เป็น required และ nullable การอ่านว่างลดเหลือ 0% และจำนวน tool call ลดลงราว 30%
  • จากความแตกต่างด้านขอบเขตแคชและโครงสร้าง throughput ของ OpenAI กับ Anthropic ทำให้ตอนแรก GPT-5.6 ถูกวัดว่าแพงกว่าประมาณ 50% แต่เมื่อใช้ cache key ระดับเวิร์กสเปซ และ breakpoint แบบเป็นชั้น อัตรา cache hit ในการเรียกครั้งแรกเพิ่มจาก 0% เป็น 83.7% และจำนวน input token ที่ไม่โดนแคชลดลง 28%
  • ต้นทุนและประสิทธิภาพของการเปลี่ยนโมเดลไม่ได้ขึ้นกับตัวโมเดลเท่านั้น แต่ขึ้นกับงบประมาณการประเมิน, tool schema, โครงสร้างแคช และวิธี replay reasoning ด้วย ดังนั้นต้องหาและแก้ สมมติฐานเฉพาะ provider ที่ถูกปรับให้เข้ากับโมเดลเดิมก่อน จึงจะเปรียบเทียบได้อย่างน่าเชื่อถือและรันระบบได้เสถียร

GPT-5.6 Sol ที่มาแทน Claude Opus

  • Ploy agent วางแผนเพจของเว็บไซต์การตลาดสำหรับโปรดักชัน อ่าน codebase สร้างคอมโพเนนต์และรูปภาพ ตรวจผลลัพธ์ด้วย screenshot แล้วตัดสินว่างานเสร็จหรือไม่
  • หลายเดือนที่ผ่านมาไม่มีโมเดลใดผ่านเกณฑ์ที่จะมาแทน Claude Opus ได้ และโมเดลเริ่มต้นยังคงเป็น Opus 4.7 และ 4.8 ตามลำดับตลอด 4 เดือน
  • GPT-5.6 Sol เป็นโมเดลแรกที่แซง Opus ในการประเมินแบบตัวต่อตัวบนงานเดียวกัน และกลายเป็นโมเดลเริ่มต้นของทุก Ploy workspace
  • แม้ในการประเมินช่วงแรก เวลารันของ build ที่เสร็จสมบูรณ์ก็ต่ำกว่าครึ่ง ค่าใช้จ่ายต่ำลง 27% และทำคะแนนได้เท่ากับหรือสูงกว่าโมเดลเดิม จึงมีเหตุผลเพียงพอให้เริ่ม migration
  • Ploy ใช้ Vercel AI SDK แต่ระหว่างเปลี่ยนโมเดลพบว่าใน stack ทั้งหมดยังมี สมมติฐานเฉพาะ provider เกี่ยวกับการประกอบอาร์กิวเมนต์ของ tool, prompt caching และการ replay reasoning ระหว่าง turn หลงเหลืออยู่
  • การ migration ดำเนินไปด้วยการแก้ evaluation harness, tool schema, prompt caching และ reasoning replay ตามลำดับ

ก่อนเชื่อตัวเลขประเมิน ต้องแก้ harness ก่อน

  • ชุดประเมินรัน production agent บน workspace ทดสอบที่ตรึงไว้ ครอบคลุมหลายร้อยกรณี ตั้งแต่งานสร้างหน้าโฮมเพจตั้งแต่ศูนย์ ไปจนถึงงานตัดสินว่าสามารถทำคำขอ clone ได้อย่างปลอดภัยหรือไม่
  • ในกรณี build ตัวตัดสินด้านภาพจะเปรียบเทียบกับดีไซน์อ้างอิงและทำการตรวจสอบแบบ binary 10 รายการ
    • ตรวจว่า hero area เป็นฉากภาพถ่ายที่กินความกว้างเต็มหน้าจอหรือไม่
    • ตรวจว่า CTA หลักเป็นสี่เหลี่ยมมุมโค้ง ไม่ใช่รูปแบบ pill หรือไม่
  • มีการตรวจเนื้อหา ตรวจเส้นทางการรัน tool และ file assertion ร่วมด้วย และเมื่อ fail จะตรวจ execution trace ทั้งหมด รวมถึง tool call และข้อความของโมเดล

  • ข้อจำกัดที่ถูกปรับให้เข้ากับรูปแบบการเรียกของโมเดลเดิม

    • งบประมาณ tool call เดิมถูกปรับให้เข้ากับวิธีเรียกแบบ sequential ของ Opus แต่ GPT-5.6 ใช้ parallel call จึงเกินงบแม้ในกรณีที่แก้ปัญหาได้ถูกต้อง
    • evaluation runner ไม่รองรับ การอ่านไฟล์แบบ batch ซึ่ง Opus แทบไม่ใช้ แต่ GPT-5.6 ใช้บ่อย
    • ประมาณหนึ่งในสามของ raw failure ที่เกิดขึ้นในการรันครั้งแรกมาจากสมมติฐานของ harness ไม่ใช่พฤติกรรมของโมเดล และไม่ได้กระจายอย่างเท่าเทียมกันระหว่างโมเดล
    • หากไม่จัดประเภท execution trace ของโมเดลท้าชิงและโมเดลเดิมก่อน การประเมินจะยิ่งเข้าข้างโมเดลใหม่เมื่อมันทำตัวเหมือนโมเดลเดิมมากขึ้น

  • threshold คะแนนที่แฝงอยู่

    • dataset ที่ไม่มี minScore จะสืบทอดค่าเริ่มต้น 1.0 โดยไม่มี warning ใดๆ
    • ด้วยเหตุนี้ GPT-5.6 จึงถูกตัดสินว่า fail แม้ได้คะแนน hero 0.98 และ Opus ก็ถูกตัดสินว่า fail ในกรณีที่ผ่านการตรวจย่อยทุกข้อ
    • ผลลัพธ์ทั้งสองเป็นดีไซน์ที่ปกป้องได้ แต่ตกเพราะ threshold ที่แฝงอยู่ ไม่ใช่เพราะโมเดล

ผล benchmark หลังแก้ไข

  • หลังแก้ harness แล้ว ได้รันชุดประเมินใหม่สำหรับการสร้าง brand homepage ให้ตรงกับดีไซน์อ้างอิง
ค่าเฉลี่ยต่อ build ที่เสร็จสมบูรณ์ Claude Opus 4.8 (n=11) GPT-5.6 (n=10)
ค่าใช้จ่าย $3.06 $2.22
เวลารัน 8 นาที 00 วินาที 3 นาที 42 วินาที
input token 2.6 ล้าน 1.7 ล้าน
output token 33,000 17,100
คะแนนด้านภาพ 0.936 0.970
  • GPT-5.6 ทำเพจเสร็จ เร็วขึ้น 2.2 เท่า ค่าใช้จ่ายต่ำลง 27% และใช้ output token เพียงประมาณครึ่งหนึ่ง
  • ปริมาณโค้ดที่สร้างก็น้อยกว่า
    • ในกรณีเปรียบเทียบคู่หนึ่ง Opus สร้าง CSS variable 174 รายการและ globals.css ยาว 17,957 ตัวอักษร รวมถึงชุดสีที่ส่วนใหญ่ไม่ได้ใช้
    • GPT-5.6 ใช้ CSS variable 45 รายการและ 2,508 ตัวอักษร แต่ให้ผล render ใกล้เคียงหรือดีกว่า

  • คุณภาพและความสม่ำเสมอของดีไซน์

    • GPT-5.6 ถนัดเลย์เอาต์ที่สะอาดและเป็น grid แน่น แต่หากไม่ชี้นำอย่างชัดเจนมีแนวโน้มจะลู่เข้าสไตล์นั้น
    • ใน harness เดิมที่ออกแบบมาสำหรับ Opus 4.8 มักสร้าง ผลลัพธ์ที่สะอาดแต่ธรรมดา โดยไม่สนใจ design system เดิม
    • หลังทีมดีไซน์และทีมวิศวกรรมปรับปรุงวิธีชี้นำโมเดล ผลลัพธ์ก็ผ่านมาตรฐานการทำตามแบรนด์ที่จำเป็นสำหรับโปรดักชัน

การจัดการพารามิเตอร์ optional ใน tool call

  • tool code ของ agent มีพารามิเตอร์ระดับบนสุด 25 รายการ โดยมีเพียง action ที่เป็น required ส่วนที่เหลือเป็น optional
  • Claude ส่งเฉพาะพารามิเตอร์ 2~3 รายการที่ใช้ แต่ GPT-5.6 ส่งครบทั้ง 25 รายการทุกครั้ง และเติมฟิลด์ที่ไม่ได้ใช้ด้วยค่าที่ดูสมเหตุสมผล เช่น offset: 0, timeout: 120000, siteId: "00000000-0000-0000-0000-000000000000"
  • execution trace ของ code(read) ในโปรดักชันที่เก็บตลอด 3 วันก็พบรูปแบบเดียวกัน
โมเดล จำนวน call call ที่มีครบทั้ง 25 property
gpt-5.6 6,635 6,635 ครั้ง, 100%
claude-opus-4.8 2,898 4 ครั้ง, 0.1%
claude-sonnet-5 1,933 0 ครั้ง

  • สาเหตุที่เกิดการอ่านไฟล์ว่าง

    • ปัญหาไม่ได้อยู่แค่อาร์กิวเมนต์ยืดยาว แต่คือ implementation การอ่านไฟล์ไม่สามารถแยกค่าที่โมเดลแต่งขึ้นเองออกจากค่าที่ผู้ใช้ตั้งใจส่งได้
    • implementation ประมวลผล offset: 0 เป็นอาร์กิวเมนต์จริง และการอ่านไฟล์ของ GPT-5.6 52~64% ส่งคืนผลลัพธ์ว่าง
    • tool คืน success: true ทั้งในการอ่านที่ถูกต้องและการอ่านว่าง ทำให้โมเดลไม่รู้ว่ากำลังอ่านไฟล์ว่างอยู่
    • เมื่อพยายามชดเชยผลลัพธ์ว่างด้วยการเรียกเพิ่มขึ้น คุณภาพผลลัพธ์ก็แย่ลงด้วย

  • ปัญหาที่ prompt และ strict mode แก้ไม่ได้

    • แม้ใส่คำสั่งในคำอธิบาย tool ให้ละพารามิเตอร์ที่ไม่ได้ใช้ ก็ยังสร้างครบทั้ง 25 รายการ
    • แม้เติม OPTIONAL, omit if unused ให้แต่ละ property พฤติกรรมก็ไม่เปลี่ยน
    • ใน strict mode ของ OpenAI ก็ได้ผลแบบเดียวกัน และหากจะนำมาใช้ต้องลบการตรวจ pattern, format และขนาด array ออกจากทุก schema
    • พฤติกรรมนี้มาจากวิธีที่โมเดลสร้าง function calling ดังนั้นจึงเปลี่ยน schema แทนการเปลี่ยน prompt

  • การแปลง schema ที่ขอบเขตของ provider

    • สำหรับโมเดลตระกูล OpenAI เขียน property optional ทั้งหมดใหม่ให้เป็น property ที่ required และ nullable ในรูป anyOf: [T, null]
    • โมเดลเติมพารามิเตอร์ที่ไม่ได้ใช้เป็น null อย่างชัดเจน และลบ null ออกก่อนตรวจสอบที่ขอบเขต shared tool call
    • ไม่ต้องเปลี่ยน implementation ของ tool เพียงทำให้ schema สำหรับโมเดลสามารถแสดงค่าที่ไม่ได้ใช้ได้
    // ก่อนเปลี่ยน: key ทั้ง 25 รายการถูกเติมด้วยค่าที่สุ่มขึ้นมา
{ "action": "read", "file_paths": ["..."], "offset": 0, "timeout": 120000 }

// หลังเปลี่ยน: ส่งค่าจริง 4 รายการและ null 21 รายการ แล้วลบ null ก่อนรัน tool
{ "action": "read", "file_paths": ["..."], "offset": null, "timeout": null }
    • หลังเปลี่ยน การอ่านไฟล์ว่างลดจาก 52% เหลือ 0%
    • จำนวน tool call ที่ต้องใช้ในงานเดียวกันก็ลดลงประมาณ 30% เพราะไม่มีพฤติกรรมอ่านผลลัพธ์ว่างซ้ำๆ อีก

Prompt caching ที่ปรับให้เข้ากับวิธีของ OpenAI

  • provider ทั้งสองรายมี prompt caching แต่ implementation ต่างกัน
  • ก่อนสะท้อนความแตกต่างนี้ GPT-5.6 ดูเหมือนแพงกว่า Opus ราว 50% แต่สาเหตุไม่ใช่ราคาโมเดล หากเป็น การตั้งค่าแคช

  • แคชระดับองค์กรของ Anthropic

    • prompt ของ agent เริ่มด้วย static prefix ราว 29,000 token ซึ่งประกอบด้วย tool schema และ core system prompt และเหมือนกันในทุก conversation
    • ใน Claude จะทำเครื่องหมาย cache breakpoint ด้วย cache_control และแชร์ prefix ทั่วทั้งองค์กร
    • conversation จาก workspace ใดก็ใช้รายการ shared item เดียวกันได้ และไม่มีข้อจำกัด throughput ต่อ key
    • อัตรา cache hit อยู่ที่ 92~96%

  • พฤติกรรมแคชที่เปลี่ยนไปใน GPT-5.6

    • GPT รุ่นก่อนหน้า cache การ match partial prefix แบบ implicit แต่ GPT-5.6 ยกเลิกการ match partial prefix
    • implicit cache สร้างรายการ prompt ทั้งหมดโดยอิงจากข้อความล่าสุด ดังนั้น conversation ใหม่ที่แชร์ static prefix 29,000 token เดียวกันก็มี cache hit 0% ในการเรียกครั้งแรก
    • ทำให้แต่ละ conversation ถูกคิดค่าบริการ prefix ทั้งหมดซ้ำในราคาแบบไม่แคช
    • ไม่ว่าแอปพลิเคชันจะใช้แคชหรือไม่ GPT-5.6 จะคิด ค่าเพิ่ม 1.25 เท่าสำหรับการเขียนแคช กับ prompt ที่ไม่โดนแคชทั้งหมด

  • ข้อจำกัดของ explicit cache key

    • explicit caching ต้องใช้ prompt_cache_breakpoint และ prompt_cache_key ที่จำเป็น
    • key เป็นส่วนหนึ่งของตัวตนแคชด้วย ดังนั้นแม้ prompt เหมือนกัน แต่ key ต่างกันก็ไม่ hit
    • แต่ละ key จะ map ไปยัง cache node ที่รองรับคำขอประมาณ 15 รายการต่อนาที หากเกินกว่านั้น OpenAI จะกระจายทราฟฟิกไปยัง node อื่นที่มี cold cache แยกกัน
    • ดังนั้นการกำหนด key ในหน่วยใดจึงเป็นการตัดสินใจด้าน design ที่สำคัญ
    • key ต่อ conversation: conversation ใหม่ไม่ hit shared prefix ทำให้อัตรา hit ในการเรียกครั้งแรกเป็น 0%
    • key global เดียว: ทุก request ถูก hash ไป node เดียว และเมื่อทราฟฟิกโปรดักชันเกิน 15 rpm ก็ overflow ไปยัง cold node
    • key ต่อ workspace: conversation ทั้งหมดของ customer workspace แชร์ item กันได้ ขณะเดียวกันทราฟฟิกต่อ key ยังอยู่ในระดับต่ำ

  • แคชแบบลำดับชั้นระดับ workspace

    • การตั้งค่าจริงใช้ key ระดับ workspace ในรูป ws:{workspaceId} และแบ่ง system prompt เป็นชั้น breakpoint
    • รายการ A เก็บ tool และ static prefix เพื่อลดค่าใช้จ่ายในการเรียกครั้งแรกของ session
    • รายการ B เพิ่ม workspace context เข้ากับ static prefix
    • รายการ C คือ prompt chain ทั้งหมดของ session นั้น ตั้งแต่ turn แรกจนถึงข้อความล่าสุด
    • เมื่อ workspace memory เปลี่ยน รายการ B จะ miss แต่รายการ A ยัง hit อยู่ จึงต้องเขียนใหม่เฉพาะขนาด context ที่เปลี่ยน ไม่ใช่ static prefix ทั้ง 29,000 token
    • รายการ C ใช้ implicit full prompt chain ของ OpenAI ภายใน session ได้ เพราะ prompt เป็นโครงสร้าง append-only อย่างเคร่งครัด
    • เนื่องจาก key partitioning ของ OpenAI จึงไม่สามารถแชร์ static prefix ระหว่าง workspace ได้
    • ในทางกลับกัน Anthropic ใช้แคชระดับองค์กรที่ไม่มี key partitioning จึงแชร์ prefix ได้
    • ใน GPT-5.6 แต่ละ workspace จะ cold-write 29,000 token หนึ่งครั้งต่อช่วงเวลาที่ idle และมีค่าใช้จ่ายประมาณ $0.18
    • ค่าใช้จ่ายนี้มีขอบเขตจำกัดและคาดการณ์ได้

  • ผลหลังแก้แคช

    • อัตรา cache hit ในการเรียกครั้งแรกเพิ่มจากประมาณ 0% เป็น 83.7%
    • input token ที่ไม่โดนแคชทั้งหมดลดลง 28%
    • ค่าใช้จ่ายต่อ evaluation suite ของ GPT-5.6 ต่ำกว่า Opus และความต่างด้านค่าใช้จ่ายช่วงแรกทั้งหมดเกิดจากการตั้งค่าแคชผิด
    • การเปรียบเทียบค่าใช้จ่ายระหว่างโมเดลที่ทำโดยให้มีเพียงโมเดลเดียวเริ่มจาก cold cache นั้นใช้ไม่ได้

เปลี่ยน reasoning replay ให้เป็นแบบ self-contained

  • โดยค่าเริ่มต้น GPT-5.6 Responses API replay reasoning ของ turn ก่อนหน้าด้วยการอ้างอิง item ฝั่งเซิร์ฟเวอร์ และใน conversation โปรดักชันเกิดข้อผิดพลาด Item 'rs_...' not found เป็นครั้งคราว
  • เมื่อตั้ง store: false SDK จะร้องขอ เนื้อหา reasoning แบบเข้ารหัส และ replay blob แบบ self-contained แทน pointer ที่ชี้ไปยังสถานะเซิร์ฟเวอร์
  • แม้ byte ที่แอปพลิเคชันส่งจะเป็นโครงสร้าง append-only แต่สถานะ reasoning ฝั่งเซิร์ฟเวอร์ก็สามารถเปลี่ยน prompt ที่มีผลจริงได้
  • GPT-5.6 Sol ที่แก้ evaluation harness, tool schema, prompt cache และ reasoning replay ทั้งหมดแล้ว กำลังทำงานเป็นโมเดลเริ่มต้นสำหรับโปรดักชันของ Ploy

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

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

 
GN⁺ 7 시간 전
ความคิดเห็นบน Hacker News

  • วลีอย่าง “ตัวเลขระดับนี้คุ้มพอจะย้ายโมเดลไปใช้งานจริง” ฟังดูน่าขันเกินไป อยากให้คนที่ให้มันเขียนอย่างน้อยช่วยเกลาสำนวนแบบ LLM ทั่วไปสักหน่อย
    วิธีเอาวลีสั้น ๆ มาต่อกันด้วยโคลอน จุลภาค และจุดก็แย่และอ่านแล้วอึดอัด ถึงจะมีข้อสังเกตที่ดีอย่างเรื่องแคชแบบ prefix match บางส่วนหายไปใน GPT-5.6 แต่ก็ไม่ได้เป็นงานเขียนที่อ่านสบาย

    • เลยต้องมี WRITING.md วางไว้ข้าง ๆ AGENTS.md หรือ CLAUDE.md เสมอ ส่วนใหญ่คนจะบอกโมเดลแค่ว่าให้สร้างอะไร แต่แทบไม่บอกว่าควรเขียนอย่างไร ทั้งที่ LLM ทำตามแนวทางด้านสำนวนแบบชัดเจนได้ดีอย่างน่าทึ่ง
      ผมเขียนกฎไว้ให้หลีกเลี่ยงโคลอนที่ไม่จำเป็น em dash ยาว ๆ เศษประโยคที่ปลอมเป็นการเน้น และข้อผิดพลาดทางไวยากรณ์ที่ผมชอบเผลอทำ รวมทั้งใส่ Brian Kernighan กับ Rob Pike เป็นตัวอย่างอ้างอิงของงานเขียนเชิงเทคนิคที่ชัดเจน เป็นกันเอง และไม่วางท่า เอกสารต้องไม่ใช่แค่อ่านง่าย แต่ต้องทำให้อยากอ่านด้วย
      ถ้าคุณสร้างเอกสารบ่อย การให้เอเจนต์อ้างอิง WRITING.md คุ้มค่ามาก หลายครั้งช่วยเรื่องความอ่านง่ายได้มากกว่าการเปลี่ยนไปใช้โมเดลใหม่ล่าสุดเสียอีก และต่อให้เปลี่ยนโมเดลก็ยังคงสไตล์การเขียนให้สม่ำเสมอได้
    • ถ้าเป็น บริษัท AI ยิ่งดูแย่กว่าเดิมอีก มันอาจแปลได้แค่ว่าใช้โมเดลไม่มากพอจนไม่รู้จักสำนวนเฉพาะตัวของมัน หรือไม่ตระหนักว่าสิ่งนี้สำคัญ หรือไม่เข้าใจภาพรวม หรือไม่ให้ความเคารพผู้อ่าน ซึ่งไม่ว่าข้อไหนก็ไม่ดีทั้งนั้น
    • คุณอ่านผิดวิธี แค่สั่ง LLM ให้ช่วยอ่านและสรุปตามรสนิยมด้านสำนวนของตัวเองก็พอ หรือดียิ่งกว่านั้น ไม่ต้องอ่านเองเลย ให้เอเจนต์แปลงมันเป็น ไฟล์ทักษะ สำหรับใช้อ้างอิงทีหลังก็ได้
    • ถ้าสงสัยว่าบทความไหนเขียนด้วย LLM ผมจะหยุดอ่านทันที แล้วใช้เครื่องมือ LLM ที่ผมใช้อยู่ให้สรุปหรือเขียนใหม่ อย่างน้อยก็ยังพอควบคุม สำนวนของผลลัพธ์ ได้บ้าง
    • ตอนนี้ใน claude.md ที่ใช้อยู่ ผมถึงขั้นแบนคำว่า “load-bearing” ไปเลย เพราะ Claude ชอบคำนี้แบบน่าหงุดหงิด บางทียังแซวในคอมเมนต์ประมาณ “load-be…most specific” เพราะมันชอบใช้คำนี้พร่ำเพรื่อเกินไป

  • ก่อนหน้านี้ผมย้ายเวิร์กโฟลว์ที่หลากหลาย เล็ก และเรียบง่ายหลายตัวจาก 5.4-nano กับ mini ไปเป็น 5.6 แล้วโดยรวมก็ดีขึ้นประมาณช่วงเดียวกับที่บทความบอกไว้ และงานจัดประเภทบางอย่างคุณภาพก็ดีขึ้นด้วย
    สำหรับหลายบริษัท การอัปเกรดโมเดล แบบนี้แทบจะเป็นการแก้โค้ดแค่บรรทัดเดียว เวิร์กโฟลว์หลักเราใช้สถาปัตยกรรม model router ที่ดีมากอยู่แล้ว แต่กับงานง่าย ๆ ไม่มีเหตุผลจะต้องจัดซับซ้อนขนาดนั้น และยังต้องคำนึงถึงปัญหาเรื่องความเสถียรด้วย

    • ประเด็นของบทความนี้คือ การอัปเกรดโมเดล ไม่ได้เป็นการแก้โค้ดแค่บรรทัดเดียว
    • ใช้ SDK ตัวไหน หรือทำเองทั้งหมด?
    • จุดประสงค์แรกที่เราใช้ Sol คือประเมิน 5.6 ในเวิร์กโฟลว์ของเรา ก่อนหน้านี้เราใช้ 5.5 กับทุกงานเพราะโมเดลที่ง่ายกว่าคุณภาพไม่พอ และตอนนี้เราวิเคราะห์ทั้งข้อความและภาพร่วมกันเพื่อดึงข้อมูลที่มีโครงสร้างทั้งแบบชัดเจนและแบบแฝงออกมาจากข้อมูลต้นทางที่เละเทะ
      โดยรวมแล้วมันทำงานได้ตามที่โฆษณาไว้ ตอนนี้เราส่งงานส่วนใหญ่ไปที่ terra ทำให้ต้นทุนลดลงครึ่งหนึ่งและเวลาในการตอบสนองดีขึ้น 50% ส่วน luna ใช้เสริมผลตรวจจับจาก OpenCV ความสามารถจำกัดมากแต่เร็วและแทบจะฟรี Sol ในงานของเราเหนือกว่า terra แค่นิดเดียว
      Sol ultra ก็ทำหน้าที่ประเมินได้ยอดเยี่ยมเหมือนกัน มันสร้างชุดข้อมูลขนาดใหญ่ที่มีทั้งคำแนะนำที่สมเหตุสมผล รายการเอาต์พุตที่ควรตรวจดูและเทียบกันด้วยตนเอง ข้อมูลต้นฉบับ/ข้อมูลที่ประมวลผลแล้ว และ CPM แยกตามแต่ละคิวรี ผลคือหลังจากปล่อยให้มันรันอยู่หลายชั่วโมงโดยไม่เสียเพิ่มนอกจากค่าสมาชิก Pro เกณฑ์ด้านต้นทุนลดลง 50% และปริมาณงานเพิ่มขึ้น 100%

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

    • คุณควรสร้าง แผน failover เป็นส่วนหนึ่งของ LLMOps โดยตรวจสอบเส้นทางการเรียกใช้เครื่องมือและส่วนอื่น ๆ ให้ครบ แบบนี้ก็จัดลำดับโมเดลจากถูกไปแพงเพื่อทำ failover ตามที่ต้องการได้
      ผมเคยเห็นคนทำตารางแมปแบบ model -> {{prompts}, {tools descriptions}, ...} แต่ผมว่ามันสุดโต่งเกินไป ถึงจุดหนึ่งโมเดลควรต้องปรับตัวเข้ากับพรอมป์ต์ของเราได้ และถ้าปรับไม่ได้ก็แค่ตัดมันออกจากตัวเลือกสำหรับ failover แล้วไม่ต้องส่ง API request ไปหา
    • OpenRouter ไม่ได้ failover ไปโมเดลอื่น แต่สลับไปใช้ ผู้ให้บริการรายอื่นที่ให้โมเดลเดียวกัน

  • ก็น่าขันดีที่ใต้บทความซึ่งเต็มไปด้วยข้อสังเกตเชิงอินฟราที่ลึกมาก กลับมีคอมเมนต์ครึ่งหนึ่งมัวแต่บ่นเรื่อง สำนวนที่ดูฝืน ๆ ต่อให้ Claude ช่วยขัดประโยคมาบ้าง ถ้ามันมีพิมพ์เขียวที่หยิบไปใช้ได้ทันทีสำหรับลดงบ API ลง 30% และแก้ปัญหาการอ่านไฟล์ว่าง เท่านี้ก็สำคัญกว่าไม่ใช่หรือ

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

  • พอเห็นบอกว่า “ตั้งแต่วันนี้เอเจนต์ Ploy จะใช้ GPT-5.6 Sol ที่เพิ่งเปิดตัวเมื่อเช้านี้” ก็เลยสงสัยว่า สลับระบบจากการทดสอบแค่ครึ่งวัน เลยเหรอ? บริษัทนี้ให้วัยรุ่นมาบริหารหรือไง?

    • จริง ๆ แล้วทีมงานใกล้เคียงระดับ Staff และ Senior Staff มากกว่า ผ่านความสัมพันธ์กับ YC จึงได้ทดสอบโมเดลพรีวิว GPT-5.6 ล่วงหน้าราวหนึ่งสัปดาห์พร้อมส่งฟีดแบ็ก
      งานประเมินรันบน GitHub CI และสามารถรันชุดประเมินมากกว่า 115 ชุดสำหรับงานออกแบบเว็บและมาร์เก็ตติ้งซึ่งเป็นความเชี่ยวชาญของ ploy.ai ได้ครบภายในราว 15 นาที หลังเปิดโมเดลด้วย PostHog feature flag ก็เฝ้าดูความล้มเหลวอย่างใกล้ชิด
      พวกเขาต้องการถ่ายทอดความรู้จากการทำ Webflow ที่เคยรองรับอินเทอร์เน็ตมากกว่า 1% มาสู่ Ploy ให้ได้มากที่สุด เพื่อรองรับอินเทอร์เน็ตได้มากขึ้น
    • เป็นไปได้มากทีเดียวว่าอาจได้ สิทธิ์เข้าถึงล่วงหน้า ในระดับหนึ่งเพื่อให้ทำการประเมินและเขียนโพสต์แบบนี้ได้
    • ตอนนี้การสร้างชุดประเมินและเบนช์มาร์กแล้วรันบนโมเดลล่าสุดทำได้ค่อนข้างง่าย LLM เปลี่ยนตัวได้ง่าย ดังนั้น ชุดประเมิน ที่ดีจึงมีประโยชน์มาก และบางครั้งการพัฒนาก็ชัดเจนเสียจนแทบไม่ต้องประเมินเลย
    • คาดว่าน่าจะมี ชุดข้อมูลจากโปรดักชันจริง ไว้สำหรับเปรียบเทียบโมเดลใหม่

  • แม้จะบอกว่าเอเจนต์ Ploy สามารถสร้างและแก้ไขเว็บไซต์การตลาดจริง ๆ รวมถึงวางแผน อ่านโค้ดเบส เขียนคอมโพเนนต์ สร้างภาพ ถ่ายผลลัพธ์ของตัวเอง และตัดสินว่างานเสร็จหรือยัง แต่ถึงจะไม่ได้ทดสอบอย่างเข้มงวดก็ยังคาดว่า Fable น่าจะทำเว็บไซต์การตลาดได้ดีกว่า Opus มาก ส่วนการทำสไลด์พรีเซนเทชันนั้นดีกว่าอย่างชัดเจน

    • ในด้านดีไซน์ GPT-5.6 ดีกว่า Fable มาก
    • 4.7 มีแนวโน้มทำตามคำสั่งแบบตีความตามตัวอักษรมากเกินไป ดังนั้นผลลัพธ์ในต้นฉบับก็ดูน่าเชื่อได้เหมือนกัน

  • วิธีแก้แบบเปลี่ยนให้คุณสมบัติที่เลือกได้ทั้งหมดกลายเป็นค่าบังคับ แต่อนุญาต null ด้วย anyOf: [T, null] เฉพาะกับโมเดลสาย OpenAI ดูมีกลิ่นแปลก ๆ เคยใช้แค่ MCP ในรูปแบบดัดแปลง แต่ก็ยังไม่ชัดว่าทำไม type definition ของ TypeScript ถึงไปมีผลต่อ JSON Schema ที่เอเจนต์ส่งไปยัง inference backend
    ในสเปกของ MCP มีฟิลด์สำหรับระบุ optional parameter ไว้อย่างชัดเจน จึงดูเหมือนมีบั๊กอยู่สักที่ระหว่างชั้น TypeScript กับคำอธิบายเครื่องมือที่ส่งจริง อาจเป็นไปได้ว่า inference backend เปลี่ยนจาก “สร้าง tool response ที่ถูกต้อง” ไปเป็น “สร้าง response ที่ถูกต้องตาม JSON Schema ที่ไม่มี optional parameter” แต่ถ้าไม่เห็น request จริงก็คงตัดสินไม่ได้

    • นี่ไม่ใช่บั๊กของ schema generation หรือ TypeScript แต่เป็น พฤติกรรมภายในของ OpenAI function calling เอง น้ำหนักที่ fine-tune มาเพื่อการใช้เครื่องมือจะพยายามส่งออกโครงสร้างข้อมูลที่ครบที่สุดเท่าที่ทำได้ ถ้าโมเดลเห็นชื่อพารามิเตอร์ในบริบทของ system prompt มันก็มักจะพยายามเติมค่า แม้จะไม่ได้อยู่ในอาร์เรย์ required ก็ตาม
    • โมเดล frontier รุ่นใหม่รวมถึง Fable, Opus และ 5.6 มักค่อนข้างหลวมในการเรียกเครื่องมือ และบ่อยครั้งก็ไม่ทำตามสคีมาอย่างเคร่งครัด ตัวอย่างที่ Claude model สร้างพร็อพเพอร์ตีที่ไม่มีอยู่จริงใน Pi edit/replace tool call ดูได้ที่ https://lucumr.pocoo.org/about/
      สาเหตุส่วนหนึ่งดูเหมือนเกี่ยวข้องกับอาการที่ความสามารถลดลงเมื่อใช้ constrained decoding แม้จะรับประกันความถูกต้องตามสคีมาได้ แต่ความสามารถลดลงมาก จึงพอใช้ได้กับงานจัดหมวดหมู่ สรุปความ หรือปรับปรุงพรอมป์ต์ แต่ควรระวังเมื่อใช้กับการวนรันแบบเอเจนต์
      สภาพแวดล้อมรันไทม์อย่าง Claude Code ทำงานเบื้องหลังเยอะมาก เช่น preprocessing, recovery, cleanup ฯลฯ แต่ปกติไม่ค่อยถูกเปิดเผย ในทางปฏิบัติ มักง่ายและดีกว่าถ้าทำให้สภาพแวดล้อมรันไทม์ผ่อนปรนมากขึ้นเพื่อให้เข้ากับลักษณะเฉพาะของแต่ละโมเดล แทนที่จะสมมติและบังคับว่าต้องแม่นยำสมบูรณ์แบบ และโมเดลก็เปลี่ยนทุกเดือนหรือสองเดือนอยู่แล้ว นี่แหละแอปพลิเคชัน AI แบบสร้างตามบรรยากาศ

  • อยากรู้ ตัวเลขคร่าว ๆ ว่าค่าใช้จ่ายจริงต่อการสร้างเว็บไซต์หนึ่งเว็บด้วย Opus กับ Sol อยู่ที่ประมาณเท่าไร

  • พอย้ายเวิร์กโฟลว์ไปที่ Reasonix และใช้ cache hit บน DeepSeek ต้นทุนต่อคำขอก็แทบจะใกล้ศูนย์ แม้จะใช้ผู้ให้บริการในสหรัฐฯ ที่ไม่ได้รับเงินอุดหนุน

    • ใช้การตั้งค่าแบบไหน แล้วถ้า เทียบกับ Pi เป็นอย่างไรบ้าง?

  • แทนที่จะใช้ GPT-5.6 Sol เป็นค่าเริ่มต้นกับทุก Ploy workspace อาจคุ้มที่จะพิจารณา Luna สำหรับงานบางส่วนที่ต้องจับเครื่องมือจริง ๆ มันทั้งเก่งและเร็วอย่างน่าประหลาด
    Sol เด่นมากเรื่องคุยกับคนและประสานการเรียกเอเจนต์ แต่แพงเกินไปหากจะใช้กับทุกงาน ราคาเท่ากับรัน Sol หนึ่งครั้ง สามารถรัน Luna ได้ห้าครั้ง และความต่างระหว่างมีตัวอย่างหนึ่งชิ้นกับห้าชิ้นในเชิงสถิตินั้นมากพอตัว

    • ถ้าแต่ละขั้นของการรัน Luna มีโอกาสถูกต้อง 90% ความน่าจะเป็นที่ทั้งห้าขั้นจะถูกทั้งหมดคือ 0.9^5 = 0.59 หรือ 59% ส่วนความแม่นยำของ Sol หนึ่งครั้งอาจอยู่แถว 95% ตัวเลขจริงอาจต่างออกไป แต่การให้ Sol มาตรวจสอบตอนท้ายอาจถูกกว่า
    • ปัญหาของ sub-agent คือมันถูกแยกจากกันเสมอ ข้อดีคือช่วยให้บริบทเล็กและโฟกัส แต่ถ้าต้องทำงานต่อเนื่องแต่ละตัวก็มักต้องค้นคว้าใหม่เอง จึงมักกิน โทเคนที่ไม่ถูกแคช
      ต้นทุนอาจสูงขึ้นแต่ผลลัพธ์กลับแย่ลงก็ได้ ขึ้นอยู่กับว่าใช้เอเจนต์จำนวนมากแค่ไหนกับงานนั้น