A/B testing

A/B testing คือวิธีตัดสินว่าของสองแบบอันไหนดีกว่า ด้วยการปล่อยทั้งสองแบบออกไปพร้อมกันแล้วให้คนคนละกลุ่มเจอคนละแบบ จากนั้นวัดผลจากตัวชี้วัดที่ตกลงกันไว้ล่วงหน้าว่ากลุ่มไหนให้ผลดีกว่า เอกสารของ Microsoft หน้า Use variant feature flags ของ Azure App Configuration เขียนไว้ว่า flag ที่ตั้งให้มีหลาย variant นั้นใช้ประโยชน์กับการทดลอง feature ได้ ซึ่งเป็นสิ่งเดียวกับที่คนเรียกกันว่า A/B testing ในงาน AI คนเอาวิธีเดียวกันนี้มาเทียบ prompt สองแบบ หรือเทียบ model สองตัว กับผู้ใช้จริงในช่วงเวลาเดียวกัน แทนที่จะนั่งเถียงกันในห้องประชุมว่าคำตอบของฝั่งไหนอ่านแล้วรู้สึกดีกว่า

กลไกที่อยู่ข้างใต้คือการแบ่งผู้ใช้ตามสัดส่วน หน้า Use variant feature flags อธิบายว่า flag แบบนี้มี variant ได้หลายตัว แต่ละตัวมีชื่อของตัวเอง ส่วนค่า configuration นั้นเอกสารระบุว่าจะใส่หรือไม่ใส่ก็ได้ จากนั้นมีกฎ allocation กำกับว่าใครจะได้ variant ไหน ตัวอย่างในหน้านั้นให้ผู้ใช้ที่ตกอยู่ใน percentile 0 ถึง 10 ได้ variant ชื่อ Minimal และผู้ใช้ที่อยู่ใน percentile 10 ถึง 100 ได้ variant ชื่อ Standard นอกจากแบ่งตามสัดส่วนแล้วยังตั้ง override ให้ผู้ใช้หรือกลุ่มที่ระบุชื่อไว้ได้ variant ที่ต้องการโดยไม่ต้องสนสัดส่วนก็ได้ และถ้า variant ตัวใดตัวหนึ่งมีปัญหา หน้าเดียวกันบอกให้ปิด flag ด้วยการตั้งค่า Enabled เป็น false ซึ่งก็คือการใช้ kill-switch ผลคือทุกคนจะได้ variant ที่ตั้งไว้เป็น DefaultWhenDisabled ไม่ว่าเดิมจะตกอยู่ percentile ไหนหรือถูก override ไว้อย่างไร ฝั่งเครื่องมือที่ทำมาสำหรับงาน AI โดยเฉพาะก็วางกลไกคล้ายกัน เอกสาร AgentControl ของ LaunchDarkly นิยาม AgentControl config ว่าเป็น resource ชิ้นเดียวที่สร้างไว้คุมว่าแอปของเราจะใช้ large language model อย่างไร ตั้ง targeting rule ได้ว่าจะส่ง variation ไหนให้ context ไหน แล้วเทียบ variation กันเพื่อดูว่าตัวไหนทำได้ดีกว่าเมื่อวัดจากต้นทุน latency ความพึงพอใจ หรือ metric อื่น จุดที่เอกสารหน้านั้นย้ำไว้คือ LaunchDarkly ไม่ได้เรียกไปหา model provider แทนเรา แอปของเราต้องเรียก provider เองด้วย credential ของตัวเอง โดยใช้ค่า configuration ที่ SDK ส่งกลับมา ฉะนั้น model สองตัวที่เอามาชนกันจะเรียกผ่าน azure-openai หรือ amazon-bedrock ก็ได้ ตัวเครื่องมือทำหน้าที่บอกว่ารอบนี้ผู้ใช้คนนี้ควรได้ prompt และ model ตัวไหน แล้วรวบผลที่วัดได้กลับมาแสดงให้ดู

คนทำงานเจอคำนี้ตอนทีมจะเปลี่ยน prompt-template ของผู้ช่วยตอบลูกค้าอัตโนมัติ หรือจะย้ายไปใช้ model ตัวใหม่ แล้วมีคนถามขึ้นมาว่ารู้ได้อย่างไรว่าดีขึ้นจริง สิ่งที่ต้องระวังมีสามเรื่อง เรื่องแรกคือ non-determinism ของ model ที่ทำให้คำถามเดิมได้คำตอบไม่เหมือนเดิมทุกครั้ง การเปิดดูคำตอบไม่กี่ชิ้นแล้วชี้ว่าฝั่งไหนดีกว่าจึงยังเชื่อไม่ได้ เรื่องที่สองคือจำนวนคนที่ต้องเจอการทดลอง เอกสารหน้า Experiment sample size and run time ของ LaunchDarkly เขียนว่ายิ่งกลุ่มตัวอย่างของการทดลองใหญ่ ก็ยิ่งมั่นใจในผลลัพธ์ได้มากขึ้น และแยกไว้ชัดว่ามีเฉพาะการทดลองแบบ fixed-horizon frequentist เท่านั้นที่ต้องคำนวณ sample size ก่อน ส่วนแบบ sequential frequentist รันได้โดยไม่ต้องคำนวณ sample size ล่วงหน้า ในหัวข้อที่ว่าด้วยการทดลองแบบ Bayesian หน้าเดียวกันแนะนำว่าโดยทั่วไปควรรันการทดลองอย่างน้อยหนึ่งสัปดาห์ และรันสั้นกว่านั้นได้ถ้ามี context เข้ามาเจอการทดลองมากพอจนตัดสินได้แล้วว่า variation ไหนชนะ แปลว่าไม่มีตัวเลขสำเร็จรูปตัวเดียวที่ตอบได้ทุกกรณีว่าต้องเก็บกี่คนถึงจะพอ เรื่องที่สามคือต้องเปลี่ยนทีละอย่าง เอกสารของ Microsoft หน้า Tune prompts using variants (classic) ระบุหลักการทดลองแบบควบคุมตัวแปรไว้ว่าให้เปลี่ยนครั้งละหนึ่งอย่างและคงส่วนที่เหลือไว้เหมือนเดิม ถ้าเปลี่ยน prompt พร้อมกับสลับ model ไปด้วยในรอบเดียว ผลที่ออกมาจะบอกไม่ได้ว่าอะไรทำให้ดีขึ้น และทั้งหมดนี้ตั้งอยู่บนเงื่อนไขว่าต้องเก็บ log ของทั้งสองฝั่งไว้จริง ซึ่งเป็นงานของชั้น observability ส่วนตัวชี้วัดที่เกี่ยวกับคุณภาพของคำตอบมักต้องมี human-review มาช่วยอ่านก่อนจึงจะใช้ตัดสินได้

ตัวอย่างจากบทสนทนาจริง

หัวหน้าฝ่ายบริการลูกค้า: ทีมเขียน prompt ใหม่ให้ระบบตอบแชทลูกค้ามาแล้ว อ่านดูแล้วรู้สึกว่าตัวใหม่สุภาพกว่าเดิมเยอะ เปลี่ยนไปใช้ทั้งหมดเลยได้ไหมคะ

คนดูแลระบบ: ขอเปิดเป็น A/B testing ก่อนดีกว่าครับ ให้ลูกค้าครึ่งหนึ่งเจอ prompt เดิม อีกครึ่งเจอตัวใหม่ในช่วงเวลาเดียวกัน แล้ววัดจากตัวชี้วัดที่เราตกลงกันไว้ก่อนเริ่ม เช่น สัดส่วนเคสที่ต้องโอนให้คนตอบต่อ ถ้าตัวใหม่ดีกว่าจริงค่อยขยายให้ครบทุกคน ถ้าแย่กว่าก็ปิดกลับได้ทันทีโดยไม่ต้องแก้โค้ด

หัวหน้าฝ่ายบริการลูกค้า: แล้วต้องรอนานแค่ไหนถึงจะรู้ผล

คนดูแลระบบ: ขึ้นอยู่กับว่ามีลูกค้าเข้ามาเจอมากแค่ไหนครับ ยิ่งกลุ่มตัวอย่างใหญ่ก็ยิ่งมั่นใจในผลได้มากขึ้น ถ้าตอนนี้แชทเข้ามาวันละไม่กี่สิบเคส แล้วเรารีบสรุปตั้งแต่วันแรก ตัวเลขจะยังแกว่งจนอ่านผิดได้ง่ายครับ

ระวังสับสนกับ

• feature-flag : feature flag คือสวิตช์ที่ตัดสินว่าใครได้เห็นอะไร ส่วน A/B testing คือการเอาสวิตช์นั้นมาแบ่งกลุ่มแล้ววัดผลว่าฝั่งไหนดีกว่า เอกสาร Use variant feature flags ใช้ flag ที่มีหลาย variant เป็นฐานของการทดลองแบบนี้ ฉะนั้นการมี flag อยู่แล้วยังไม่ได้แปลว่ากำลังทำ A/B testing
• evals : eval คือการให้คะแนนคำตอบกับชุดข้อมูลที่เราเตรียมไว้เอง ทำซ้ำกี่รอบก็ได้ตั้งแต่ก่อนปล่อยของ ส่วน A/B testing ตัดสินจากพฤติกรรมของผู้ใช้จริงหลังปล่อยไปแล้ว สองอย่างนี้ใช้คู่กันมากกว่าจะใช้แทนกัน
• regression-testing : regression testing ถามว่าของที่เคยทำได้ยังทำได้เหมือนเดิมอยู่ไหมหลังแก้ ส่วน A/B testing ถามว่าของใหม่ให้ผลดีกว่าของเดิมหรือเปล่าเมื่อวัดกับผู้ใช้จริง