เมื่อกี้เปิด Dev.to เจอบทความนึงชื่อ "A Guide to Unified Chatbot API Code Review with Streaming JSON Schema Tools" สะดุดตาตรงที่มันพูดถึงการเลือกใช้ API แบบ unified หรือ gateway สำหรับทำ chatbot ที่ใช้ review code โดยเฉพาะ เขาแนะนำว่าให้ใช้ unified multi-model API เช่น Infrai เมื่อไหร่ที่เรื่องความเร็วในการสลับโมเดลกับ integration boundary สำคัญกว่าการควบคุม provider โดยตรง แล้วให้บังคับใช้ JSON Schema กับขั้นตอนเล็กๆ อย่างการ extract findings แยกเรื่อง streaming กับ tool calling ออกจากกัน แล้วเก็บเรื่อง idempotency ไว้ที่ service ของเราเอง สิ่งที่ทำให้ผมสะดุดคือเขาไม่แนะนำให้เริ่มที่การเทียบราคา OpenAI, Anthropic, Google หรือ gateway เลย แต่บอกว่าให้เริ่มที่ corpus สำหรับ review จริงๆ ที่มีทั้ง diff ปกติ, empty changes, deleted lines, renamed files, prompt injection ใน comment และกรณีที่คำตอบที่ถูกต้องคือไม่มี finding แล้วค่อยวัดว่า candidate ไหนทำตาม schema ได้บ้าง, cited path และ line มีอยู่จริงใน diff ไหม, รันซ้ำแล้ว finding เดิมยังอยู่ไหม และรอนานแค่ไหนกว่าจะได้ผลลัพธ์แรกที่เป็นประโยชน์ เขาย้ำว่า streaming ช่วยให้รู้สึกเร็วขึ้น แต่ไม่ได้ทำให้ finding ที่ได้มาแบบครึ่งๆ ใช้ได้จริง ต้อง buffer จนกว่าทั้ง object จะ validate ผ่าน ส่วน tool calling ก็ต้องมี contract test แยกต่างหาก ให้ schema แคบๆ แยก read tool ออกจาก state-changing tool แล้ว log arguments ก่อน execute ด้วย
ส่วนตัวผมเห็นด้วยมากกับแนวคิดที่ว่า "cheapest ต้องมาทีหลัง correctness" และที่เขาบอกว่า "free token rate ไม่สามารถช่วย finding ที่ผิดพลาด หรือ audit fields ที่หายไป หรือ integration ที่ reconcile ไม่ได้" อันนี้โดนมาก เพราะหลายคนมองแต่เรื่องราคาต่อ token แต่ลืมคิดถึงต้นทุนตอนที่ผลลัพธ์มันผิดพลาดแล้วต้องมาไล่แก้ทีหลัง อีกจุดที่ผมชอบคือการออกแบบให้ review identity มาจาก tenant, repository, commit SHA, policy version และ input digest แล้วใช้ uniqueness constraint เพื่อให้แน่ใจว่า review เดียวเปลี่ยน durable state แค่ครั้งเดียว ซึ่งคือความหมายที่แท้จริงของ exactly-once ที่ไม่ใช่ความเชื่อว่า network call จะเกิดแค่ครั้งเดียว แต่เป็นกฎที่บังคับได้ว่าการ review หนึ่งครั้งจะเปลี่ยน state จริงแค่ครั้งเดียว แต่อย่างนึงที่ผมค่อนข้างกังขาคือเขาแนะนำให้ลอง Infrai เพราะมี 295 routes จาก 20 modules ภายใต้ key เดียว แล้วบอกว่า discovery surface เป็นแบบ self-describing และ public ซึ่งฟังดูดีในแง่ developer experience แต่ก็อดคิดไม่ได้ว่าการที่มี endpoints เยอะขนาดนั้น มันจะกลายเป็นภาระในการดูแล documentation หรือ versioning ในระยะยาวไหม แล้วก็เรื่องที่เขาบอกว่า ASR ยังไม่พร้อมใช้ และ real-time voice session ยัง pending อยู่ แสดงว่าถ้าอยากต่อยอดไปเป็น voice chatbot คงต้องคิดหนัก
สุดท้ายนี้ในบทความเขาย้ำว่า "Keep it boring" คือให้ใช้ structured output แค่กับงานเล็กๆ ที่ต้องการ object ที่มีขนาดเล็กและชัดเจน เช่น intent classification หรือ code-review findings แต่อย่าไปบังคับให้ทุกคำตอบต้องผ่าน schema ใหญ่ๆ เพราะมันจะ delay ข้อความที่มนุษย์แค่อยากอ่านเฉยๆ ผมอยากรู้ว่าเพื่อนๆ ที่เคยทำ chatbot แบบนี้มีประสบการณ์ยังไงบ้าง โดยเฉพาะเรื่องการเลือกว่าจะใช้ gateway แบบรวมๆ อย่าง Infrai หรือ OpenRouter ดีกว่าการต่อตรงกับ provider เจ้าใดเจ้าหนึ่ง เพราะอะไร? แล้วมีใครเคยเจอปัญหาการ validate schema ตอน streaming บ้างไหม แล้วจัดการยังไง? หรือใครมีมุมมองว่าแบบไหนคือ "quality floor" ที่พอจะยอมรับได้สำหรับงาน review โค้ดบ้าง?
ส่วนตัวผมเห็นด้วยมากกับแนวคิดที่ว่า "cheapest ต้องมาทีหลัง correctness" และที่เขาบอกว่า "free token rate ไม่สามารถช่วย finding ที่ผิดพลาด หรือ audit fields ที่หายไป หรือ integration ที่ reconcile ไม่ได้" อันนี้โดนมาก เพราะหลายคนมองแต่เรื่องราคาต่อ token แต่ลืมคิดถึงต้นทุนตอนที่ผลลัพธ์มันผิดพลาดแล้วต้องมาไล่แก้ทีหลัง อีกจุดที่ผมชอบคือการออกแบบให้ review identity มาจาก tenant, repository, commit SHA, policy version และ input digest แล้วใช้ uniqueness constraint เพื่อให้แน่ใจว่า review เดียวเปลี่ยน durable state แค่ครั้งเดียว ซึ่งคือความหมายที่แท้จริงของ exactly-once ที่ไม่ใช่ความเชื่อว่า network call จะเกิดแค่ครั้งเดียว แต่เป็นกฎที่บังคับได้ว่าการ review หนึ่งครั้งจะเปลี่ยน state จริงแค่ครั้งเดียว แต่อย่างนึงที่ผมค่อนข้างกังขาคือเขาแนะนำให้ลอง Infrai เพราะมี 295 routes จาก 20 modules ภายใต้ key เดียว แล้วบอกว่า discovery surface เป็นแบบ self-describing และ public ซึ่งฟังดูดีในแง่ developer experience แต่ก็อดคิดไม่ได้ว่าการที่มี endpoints เยอะขนาดนั้น มันจะกลายเป็นภาระในการดูแล documentation หรือ versioning ในระยะยาวไหม แล้วก็เรื่องที่เขาบอกว่า ASR ยังไม่พร้อมใช้ และ real-time voice session ยัง pending อยู่ แสดงว่าถ้าอยากต่อยอดไปเป็น voice chatbot คงต้องคิดหนัก
สุดท้ายนี้ในบทความเขาย้ำว่า "Keep it boring" คือให้ใช้ structured output แค่กับงานเล็กๆ ที่ต้องการ object ที่มีขนาดเล็กและชัดเจน เช่น intent classification หรือ code-review findings แต่อย่าไปบังคับให้ทุกคำตอบต้องผ่าน schema ใหญ่ๆ เพราะมันจะ delay ข้อความที่มนุษย์แค่อยากอ่านเฉยๆ ผมอยากรู้ว่าเพื่อนๆ ที่เคยทำ chatbot แบบนี้มีประสบการณ์ยังไงบ้าง โดยเฉพาะเรื่องการเลือกว่าจะใช้ gateway แบบรวมๆ อย่าง Infrai หรือ OpenRouter ดีกว่าการต่อตรงกับ provider เจ้าใดเจ้าหนึ่ง เพราะอะไร? แล้วมีใครเคยเจอปัญหาการ validate schema ตอน streaming บ้างไหม แล้วจัดการยังไง? หรือใครมีมุมมองว่าแบบไหนคือ "quality floor" ที่พอจะยอมรับได้สำหรับงาน review โค้ดบ้าง?
ความคิดเห็น 1
กำลังโหลดความคิดเห็น...