สำหรับธุรกิจที่มีเว็บแอปหรือ SaaS อยู่แล้ว การเพิ่ม AI ควรเริ่มจากงานที่ผู้ใช้ทำไม่สำเร็จหรือเสียเวลาทำซ้ำ เช่น หาเอกสารที่เกี่ยวข้อง อ่านประวัติยาวก่อนรับช่วงงาน หรือร่างข้อมูลจากหลายแหล่ง ฟีเจอร์แรกควรช่วยให้งานนั้นเสร็จในระบบเดิมได้ง่ายขึ้น
การตัดสินใจนี้มีผลมากกว่าการเลือกโมเดล เพราะต้องกำหนดว่าใครใช้ข้อมูลใดได้ ผลลัพธ์อยู่ตรงไหน ผู้ใช้ตรวจอย่างไร และจะทำงานต่อเมื่อ AI ไม่พร้อมได้อย่างไร เจ้าของผลิตภัณฑ์ควรประเมินสิ่งเหล่านี้ร่วมกับความต้องการของผู้ใช้ก่อนลงทุน
Talvyn Labs ให้บริการออกแบบและพัฒนา AI Product / Agent ภายในระบบเดิม ตั้งแต่เลือกงานแรก ออกแบบการใช้งาน เชื่อมข้อมูลและสิทธิ์ ไปจนถึงวางวิธีตรวจผล โดยใช้ตัวอย่างงานที่ผู้ใช้ต้องทำเป็นจุดตั้งต้น
เลือกงานที่ผู้ใช้มีเหตุผลจะกลับมาใช้
เริ่มจากข้อมูลการใช้งานหรือคำถามที่ทีมสนับสนุนได้รับ แทนการเริ่มด้วยรายการความสามารถของ AI ระบุผู้ใช้หนึ่งกลุ่ม งานหนึ่งอย่าง และผลที่เขาต้องนำไปใช้ต่อ เช่น ผู้ดูแลโครงการต้องอ่านความคืบหน้าก่อนตอบลูกค้า หรือทีมบริการต้องค้นคู่มือของสินค้ารุ่นที่กำลังดูแล
ใช้ประโยคกำหนดโจทย์ที่ตรวจได้: เมื่อผู้ใช้เปิดงานนี้ เขาต้องการข้อมูลใด เพื่อทำขั้นตอนถัดไปอะไร หากตอบไม่ได้ ฟีเจอร์อาจยังไม่มีตำแหน่งที่ชัดในผลิตภัณฑ์
พิจารณาความถี่ของงาน ความพร้อมของข้อมูล ความสามารถในการตรวจผล และผลกระทบเมื่อผิดพลาดร่วมกัน งานที่เกิดไม่บ่อยแต่ดูน่าตื่นเต้นอาจมีคุณค่าน้อยกว่างานเล็กที่ผู้ใช้ต้องทำทุกครั้ง
สามแนวทางที่ต่างกันทั้งประโยชน์และภาระดูแล
ค้นข้อมูลในบริบทงาน เหมาะเมื่อผู้ใช้รู้ว่าต้องการอะไรแต่หาไม่พบ ผลลัพธ์ควรพากลับไปยังรายการหรือเอกสารที่มีสิทธิ์ดู พร้อมแสดงข้อมูลที่ใช้ตอบ เหมาะกับการเริ่มจากการอ่านข้อมูลโดยยังไม่เปลี่ยนระบบ
สรุปหรือร่างในหน้าที่กำลังทำงาน เหมาะเมื่อข้อมูลกระจายอยู่หลายจุด แต่ผู้ใช้ต้องรวบรวมก่อนตัดสินใจ ตัวอย่างสมมติคือร่างสรุปสถานะโครงการจากบันทึกที่เปิดดูได้ ผู้ใช้ควรแก้ร่างและตรวจแหล่งอ้างอิงได้ก่อนนำไปส่ง
เตรียมการทำรายการหลายขั้นตอน เหมาะเมื่อ AI ต้องเลือกข้อมูลและเรียกเครื่องมือประกอบงาน เช่น เตรียมร่างงานติดตามจากคำขอของลูกค้า ความสามารถนี้ต้องมีขอบเขตสิทธิ์ จุดอนุมัติ และวิธีกู้สถานะเมื่อทำได้เพียงบางขั้นตอน จึงไม่ควรรวมเข้ารุ่นแรกเพียงเพราะเรียกสิ่งนี้ว่า Agent
การเลือกชื่อฟีเจอร์ควรอธิบายผลที่จะได้ เช่น “สรุปประวัติงาน” หรือ “ค้นจากคู่มือ” ผู้ใช้ไม่จำเป็นต้องเข้าใจชื่อโมเดลเพื่อเริ่มทำงาน
วาง AI ในจังหวะที่ผู้ใช้ต้องการความช่วยเหลือ
หากงานเริ่มจากหน้ารายละเอียดลูกค้า ฟีเจอร์ควรเข้าใจบริบทของหน้าที่เปิดและสิทธิ์ของผู้ใช้ โดยไม่ต้องให้คัดลอกข้อมูลไปยังหน้าสนทนาอีกแห่ง แต่ต้องบอกให้เห็นว่ากำลังใช้ข้อมูลรายการใด ไม่ส่งทุกข้อมูลที่เข้าถึงได้เข้าโมเดลโดยอัตโนมัติ
หน้าจอควรแยกผลที่ AI เสนอออกจากข้อมูลที่บันทึกแล้ว ผู้ใช้ควรเปิดต้นฉบับ เปลี่ยนคำสั่ง แก้ร่าง และยกเลิกได้ เมื่อกดใช้ผลลัพธ์ต้องทราบว่าจะเปลี่ยนข้อมูลส่วนไหน โดยเฉพาะการส่งข้อความหรือแก้รายการที่คนอื่นใช้งานร่วมกัน
ตัวอย่างสมมติสำหรับ Customer Portal คือผู้ใช้ขอสรุปความคืบหน้าของโครงการ ระบบค้นเฉพาะเอกสารและบันทึกของโครงการที่ผู้ใช้มีสิทธิ์เห็น แสดงร่างพร้อมลิงก์อ้างอิง และให้ยืนยันก่อนส่งต่อ หากไม่พบบันทึกล่าสุดต้องบอกว่าข้อมูลยังไม่ครบ ไม่เติมความคืบหน้าจากการคาดเดา
สิทธิ์ข้อมูลต้องอยู่ในระบบ ไม่ฝากไว้กับคำสั่ง AI
ระบบที่มีหลายลูกค้าต้องแยกข้อมูลตามบัญชีและสิทธิ์จริง ตรวจสิทธิ์ทั้งตอนค้นเอกสารและตอนเรียกเครื่องมือ ไม่อาศัยข้อความว่า “ห้ามเปิดเผยข้อมูลผู้อื่น” เพียงอย่างเดียว ควรทดสอบด้วยบัญชีที่เข้าถึงข้อมูลต่างกันด้วย
เนื้อหาในเอกสารหรือข้อความลูกค้าอาจมีคำสั่งที่ไม่ควรเชื่อฟัง แนวทางของ OWASP เรื่อง Prompt Injection อธิบายความเสี่ยงที่ข้อมูลภายนอกชักนำพฤติกรรมของระบบได้ ขอบเขตเครื่องมือและจุดอนุมัติจึงต้องบังคับใช้ในแอปพลิเคชัน ไม่ให้เอกสารต้นทางมอบสิทธิ์ทำรายการเอง
สำหรับการเชื่อมระบบของ Talvyn Labs จะเริ่มจากการอ่านข้อมูลและบันทึกการทำงาน ส่วนการเปลี่ยนรายการหรือให้คำมั่นกับลูกค้าต้องมีคนอนุมัติ ตามขอบเขตที่ตกลงไว้
ความพร้อมใช้งานและต้นทุนเป็นส่วนหนึ่งของฟีเจอร์
กำหนดว่าเมื่อรอนาน ข้อมูลไม่ครบ หรือบริการโมเดลขัดข้อง ผู้ใช้จะทำงานต่ออย่างไร หน้าจอควรบอกสถานะ มีทางยกเลิก และกลับไปใช้วิธีเดิมได้โดยไม่สูญเสียงานที่กรอกไว้
หากผู้ใช้กดซ้ำหรือเรียกทำรายการเดิมอีกครั้ง ระบบต้องไม่สร้างผลซ้ำโดยไม่ตั้งใจ การสรุปข้อความกับการแก้ข้อมูลจริงมีผลกระทบต่างกัน จึงต้องออกแบบการลองใหม่แยกกัน
วัดต้นทุนจากงานที่ผู้ใช้ยอมรับและทำต่อสำเร็จ รวมการค้นข้อมูล การเรียกโมเดล การลองใหม่ และการดูแลฟีเจอร์ ทดลองกับภาระงานที่เป็นตัวแทนก่อนตั้งสมมติฐานเรื่องแพ็กเกจหรือค่าบริการ ไม่ใช้ราคาเรียกโมเดลหนึ่งครั้งเป็นต้นทุนทั้งหมดของผลิตภัณฑ์
สิ่งที่ควรได้จากรุ่นแรก
รุ่นแรกควรมีงานเป้าหมายชัดเจน หน้าการใช้งานที่ต่อกับระบบเดิม ขอบเขตข้อมูล ชุดตรวจคำตอบ และผู้ดูแลหลังเปิดใช้ ผลทดลองต้องบอกได้ว่าผู้ใช้ทำงานสำเร็จขึ้นหรือไม่ และข้อผิดพลาดแบบใดยังต้องส่งกลับให้คนทำ
ก่อนเริ่มกับ Talvyn Labs เตรียมหน้าจอของงานปัจจุบัน ตัวอย่างคำขอ ข้อมูลที่อนุญาตให้ใช้ และเงื่อนไขสิทธิ์ของผู้ใช้ เราจะใช้สิ่งเหล่านี้ประเมินฟีเจอร์แรกและจุดเชื่อมระบบ หากยังไม่แน่ใจว่าต้องพัฒนาเฉพาะหรือไม่ อ่าน แนวทางเลือก AI สำเร็จรูปหรือจ้างพัฒนา และใช้ เกณฑ์ทดลอง AI วางการตรวจรับก่อนขยาย
เพิ่ม AI ในผลิตภัณฑ์ที่ลูกค้าของคุณใช้อยู่
ให้ Talvyn Labs ช่วยกำหนดฟีเจอร์แรก ออกแบบการใช้งาน และเชื่อมข้อมูลตามสิทธิ์ เริ่มจากหน้าจอและงานที่ผู้ใช้ต้องทำจริง
ประเมินฟีเจอร์ AI ในระบบเดิม