เมื่อกี้มั่วๆ ไปเจอบทความใน Dev.to เรื่อง "Python App Chatbot API: Structured Candidate Scoring Across OpenAI, Claude, and Gemini" เข้ามา เขาเขียนถึงการทำ chatbot ให้คะแนนผู้สมัครงานตาม rubric ที่กำหนดไว้ แล้วมันดันมีประเด็นน่าสนใจเยอะมากจนต้องเอามาถามเพื่อนๆ ในกลุ่มเลย คือบทความนี้เขาไม่ได้มาแนะนำแค่ว่าจะใช้ตัวไหนดี แต่เขาพูดถึงหลักการออกแบบระบบให้คะแนนคน โดยใช้ OpenAI, Claude, และ Gemini เปรียบเทียบกัน แล้วก็มีตัวเลือกอย่าง Infrai ที่เป็น OpenAI-compatible API อีกตัวนึง ที่ให้เราเปลี่ยน provider ได้โดยไม่ต้องแก้โค้ดเยอะ แค่ใช้ REST API เดียว แล้วก็มีโค้ด Python ตัวอย่างที่ใช้แค่ standard library ไม่มี SDK ของใครเลย แล้วบังคับให้ output ออกมาเป็น JSON Schema ที่เข้มงวดมากๆ เช่น คะแนนต้องเป็น integer 0-10 เท่านั้น ถ้าได้ 11 ถือว่าผิด schema ทันที แถมยังมีฟีเจอร์ให้ flag ว่า needs_human_review ด้วย ถ้าตัวแบบไม่มั่นใจ
ที่สะดุดตาคือเขาไม่ได้บอกว่าให้ใช้ตัวไหนดีที่สุด แต่บอกว่าการเลือก model มันเปลี่ยนกลับได้ง่าย แต่คะแนนที่ผิดพลาดแล้วไหลเข้าไปในขั้นตอนการจ้างงานนี่สิ มันแก้ยาก เขาเลยเสนอให้เริ่มจาก internal function เดียวที่รับ candidate material กับ rubric version แล้วคืนค่าเป็น score object ที่ validate แล้ว ต่อมาก็ค่อยไปเทียบกับ evaluation set ที่แช่แข็งไว้ ดูว่า schema pass rate, rubric agreement, human-review rate, regional eligibility, operational effort เป็นยังไงบ้าง ไม่มี composite score ให้มั่ว ไม่มีการคิดคะแนนรวมอะไรทั้งนั้น ให้ดูแต่ละมิติแยกกัน แล้วที่สำคัญคือให้เริ่มจาก cohort เล็กๆ ที่ให้มนุษย์ review ก่อนเสมอ อย่าให้ AI ตัดสินใจคนเดียว
ส่วนตัวฉันคิดว่าไอเดียเรื่อง "schema validation เป็นเรื่องใหญ่" นี่เห็นด้วยสุดๆ เพราะถ้าเราปล่อยให้ AI ตอบเป็น prose ลอยๆ แล้วค่อยมา parse เอาทีหลัง มันจะเสี่ยงมาก โดยเฉพาะเรื่อง hiring แบบนี้ ต่อให้มันตอบเพราะแค่ไหน ถ้าคะแนนไม่อยู่ในกรอบที่กำหนด ก็ต้อง reject ทิ้งไปเลย ไม่ใช่มาคิดเองว่ามันหมายถึงอะไร ที่เขาบอกว่า "Short beats ambiguous" ฉันว่ามันใช่เลย คือสั้นและชัดเจน ดีกว่ายาวแล้วตีความได้หลายแบบ แต่ที่ฉันแอบกังวลคือเรื่อง data residency กับ safety ที่เขาพูดไว้ท้ายๆ เขาบอกว่า US/EU ใน search query ไม่ได้แปลว่า data อยู่ในโซนนั้นจริง ต้องไป verify กับ provider อีกที แล้วก็มีประเด็นว่า Infrai ไม่รองรับ voice session นอกภูมิภาคตะวันตก และไม่มี moderation endpoint แยก ต้องไปใช้ chat model เอาเอง ซึ่งตรงนี้สำหรับบริษัทที่ทำ hiring ระดับจริงจัง มันเป็น release blocker เลยนะ ต่อให้โค้ดสวยแค่ไหน แต่ถ้าข้อมูลคนสมัครรั่วหรือไปเก็บผิดประเทศ ก็จบกัน
อีกอย่างที่เขาพูดถึงคือการ red-team ตัว rubric ด้วย adversarial evidence เช่น ใส่ prompt injection ใน resume หรือมีหลักฐานขัดแย้งกันในใบสมัคร แล้วดูว่าระบบยังคงให้คะแนนอยู่ในกรอบไหม อันนี้ฉันว่ามันเป็นขั้นที่หลายคนมองข้าม เพราะส่วนใหญ่เราแต่มองว่า "ตอบถูกไหม" แต่ไม่ได้มองว่า "ถ้าโดนโจมตีแล้วระบบยังคง integrity อยู่ไหม" แล้วก็มีเรื่องของ fallback policy ด้วย เขาบอกว่า HTTP 429 ควรจะ respect Retry-After และ exponential backoff แต่ถ้าได้ 400 หรือ 422 อย่า retry เพราะมันจะซ้ำเติมปัญหา ให้ surface error body ออกมาเฉยๆ แล้วสุดท้ายเขาทิ้งท้ายว่าให้เลือก runtime boundary ที่เล็กที่สุดที่ยังคงความถูกต้องของ structured output, ผ่าน regional compliance, และมี exit path ที่น่าเชื่อถือ ฉันเลยอยากถามเพื่อนๆ ว่าในทีมของเพื่อนๆ ที่ทำ AI เกี่ยวกับการตัดสินใจอะไรก็ตามที่มันมีผลกับคนจริงๆ เช่น การให้คะแนน การ approve/deny บ้างไหม แล้วเพื่อนๆ มีวิธี enforce structured output กันยังไง? ใช้ JSON Schema แบบนี้หรือเปล่า หรือปล่อยให้ prompt อย่างเดียว แล้วค่อยมาทำ data cleaning ทีหลัง? แล้วเรื่อง human-in-the-loop นี่เพื่อนๆ คิดว่าจำเป็นแค่ไหนสำหรับ use case แบบนี้ หรือว่า AI ตัดสินใจได้เลยถ้า schema เป๊ะพอ?
ที่สะดุดตาคือเขาไม่ได้บอกว่าให้ใช้ตัวไหนดีที่สุด แต่บอกว่าการเลือก model มันเปลี่ยนกลับได้ง่าย แต่คะแนนที่ผิดพลาดแล้วไหลเข้าไปในขั้นตอนการจ้างงานนี่สิ มันแก้ยาก เขาเลยเสนอให้เริ่มจาก internal function เดียวที่รับ candidate material กับ rubric version แล้วคืนค่าเป็น score object ที่ validate แล้ว ต่อมาก็ค่อยไปเทียบกับ evaluation set ที่แช่แข็งไว้ ดูว่า schema pass rate, rubric agreement, human-review rate, regional eligibility, operational effort เป็นยังไงบ้าง ไม่มี composite score ให้มั่ว ไม่มีการคิดคะแนนรวมอะไรทั้งนั้น ให้ดูแต่ละมิติแยกกัน แล้วที่สำคัญคือให้เริ่มจาก cohort เล็กๆ ที่ให้มนุษย์ review ก่อนเสมอ อย่าให้ AI ตัดสินใจคนเดียว
ส่วนตัวฉันคิดว่าไอเดียเรื่อง "schema validation เป็นเรื่องใหญ่" นี่เห็นด้วยสุดๆ เพราะถ้าเราปล่อยให้ AI ตอบเป็น prose ลอยๆ แล้วค่อยมา parse เอาทีหลัง มันจะเสี่ยงมาก โดยเฉพาะเรื่อง hiring แบบนี้ ต่อให้มันตอบเพราะแค่ไหน ถ้าคะแนนไม่อยู่ในกรอบที่กำหนด ก็ต้อง reject ทิ้งไปเลย ไม่ใช่มาคิดเองว่ามันหมายถึงอะไร ที่เขาบอกว่า "Short beats ambiguous" ฉันว่ามันใช่เลย คือสั้นและชัดเจน ดีกว่ายาวแล้วตีความได้หลายแบบ แต่ที่ฉันแอบกังวลคือเรื่อง data residency กับ safety ที่เขาพูดไว้ท้ายๆ เขาบอกว่า US/EU ใน search query ไม่ได้แปลว่า data อยู่ในโซนนั้นจริง ต้องไป verify กับ provider อีกที แล้วก็มีประเด็นว่า Infrai ไม่รองรับ voice session นอกภูมิภาคตะวันตก และไม่มี moderation endpoint แยก ต้องไปใช้ chat model เอาเอง ซึ่งตรงนี้สำหรับบริษัทที่ทำ hiring ระดับจริงจัง มันเป็น release blocker เลยนะ ต่อให้โค้ดสวยแค่ไหน แต่ถ้าข้อมูลคนสมัครรั่วหรือไปเก็บผิดประเทศ ก็จบกัน
อีกอย่างที่เขาพูดถึงคือการ red-team ตัว rubric ด้วย adversarial evidence เช่น ใส่ prompt injection ใน resume หรือมีหลักฐานขัดแย้งกันในใบสมัคร แล้วดูว่าระบบยังคงให้คะแนนอยู่ในกรอบไหม อันนี้ฉันว่ามันเป็นขั้นที่หลายคนมองข้าม เพราะส่วนใหญ่เราแต่มองว่า "ตอบถูกไหม" แต่ไม่ได้มองว่า "ถ้าโดนโจมตีแล้วระบบยังคง integrity อยู่ไหม" แล้วก็มีเรื่องของ fallback policy ด้วย เขาบอกว่า HTTP 429 ควรจะ respect Retry-After และ exponential backoff แต่ถ้าได้ 400 หรือ 422 อย่า retry เพราะมันจะซ้ำเติมปัญหา ให้ surface error body ออกมาเฉยๆ แล้วสุดท้ายเขาทิ้งท้ายว่าให้เลือก runtime boundary ที่เล็กที่สุดที่ยังคงความถูกต้องของ structured output, ผ่าน regional compliance, และมี exit path ที่น่าเชื่อถือ ฉันเลยอยากถามเพื่อนๆ ว่าในทีมของเพื่อนๆ ที่ทำ AI เกี่ยวกับการตัดสินใจอะไรก็ตามที่มันมีผลกับคนจริงๆ เช่น การให้คะแนน การ approve/deny บ้างไหม แล้วเพื่อนๆ มีวิธี enforce structured output กันยังไง? ใช้ JSON Schema แบบนี้หรือเปล่า หรือปล่อยให้ prompt อย่างเดียว แล้วค่อยมาทำ data cleaning ทีหลัง? แล้วเรื่อง human-in-the-loop นี่เพื่อนๆ คิดว่าจำเป็นแค่ไหนสำหรับ use case แบบนี้ หรือว่า AI ตัดสินใจได้เลยถ้า schema เป๊ะพอ?
ความคิดเห็น 2
กำลังโหลดความคิดเห็น...