เจาะประเด็น
AI / Mobile
ทำแอป AI ให้ลื่นไหลบนมือถือ ไม่ใช่แค่ต่อ API แล้วจบ
เบื้องหลังแชทบอทที่ตอบไวจนคนไม่ทันสังเกตว่ามันคิดอยู่
ทีมข่าว เอไอไทย.com
⏱ อ่าน 4 นาที
ปัญหาจริงของแอป AI บนมือถือไม่ใช่โมเดลฉลาดไม่พอ แต่คือคนรอไม่ไหวก่อนมันจะตอบ
ถ้าคุณเคยลองทำแอปที่ต่อกับ LLM แล้วปล่อยให้ผู้ใช้พิมพ์คุยกับมันบนมือถือ คุณคงรู้สึกแบบเดียวกันหมด — เปิดตัววันแรกดูเท่ดี พอคนใช้จริงเริ่มหงุดหงิด เพราะทุกครั้งที่พิมพ์เสร็จ มันต้องรอโมเดลตอบกลับ ซึ่งบางทีก็หลายวินาที หน้าจอก็ค้างนิ่ง หรือไม่ก็ขึ้น loading หมุนติ้วอยู่ตรงนั้น
Balakrishnan Ramdoss ออกมาแชร์ประสบการณ์ในงาน presentation ผ่าน InfoQ ว่า การสร้างแอปสนทนาที่ขับเคลื่อนด้วย AI แบบ production-grade ในสเกลใหญ่ ไม่ใช่เรื่องของการเรียก API แล้วโยนข้อความกลับไปแสดงผลตรงๆ อีกต่อไป แต่ต้องคิดในระดับสถาปัตยกรรมตั้งแต่ต้น ตั้งแต่เรื่องความหน่วงของโมเดล ไปจนถึงวิธีที่ UI จะถูกสร้างแบบ dynamic ให้เหมาะกับบริบทของแต่ละการสนทนา
ประเด็นแรกที่ Ramdoss ชี้คือ latency ของโมเดล ซึ่งเป็นศัตรูตัวฉกาจของ UX บนมือถือ ผู้ใช้ไม่แคร์ว่าโมเดลคุณเก่งแค่ไหน ถ้ารอ 5 วินาทีแล้วยังไม่มีอะไรขึ้นจอ เขาก็ปิดแอปไปแล้ว วิธีแก้ที่เขาเสนอคือการทำ server-driven UI ร่วมกับ pattern Backend-for-Frontend หรือ BFF คือให้ฝั่งเซิร์ฟเวอร์เป็นคนตัดสินใจว่า UI ควรหน้าตาเป็นยังไงในแต่ละสถานการณ์ แล้วส่งคำสั่งมาให้แอปเรนเดอร์ แทนที่จะให้ตัวแอปต้องคิดเองทั้งหมด
แนวคิดนี้ทำให้แอปสามารถแสดงผลได้หลายรูปแบบตามบริบท — บางทีอาจเป็น text ล้วน บางทีเป็น card มีปุ่มกด หรือเป็นฟอร์มกรอกข้อมูล โดยไม่ต้องออกเวอร์ชันใหม่ทุกครั้งที่อยากเปลี่ยน flow ซึ่งสำหรับทีมที่ต้อง iterate เร็วๆ นี่คือของจริงที่ช่วยชีวิต
อีกจุดที่คนมักไม่ค่อยพูดถึงคือการ optimize prompt ไม่ใช่เพื่อให้ได้คำตอบดีที่สุด แต่เพื่อให้โมเดลเลือก UI component ที่เหมาะสมที่สุดกับสถานการณ์นั้นๆ ฟังดูแปลกแต่จริง — เพราะในแอปสนทนาที่ขับเคลื่อนด้วย AI ตัวโมเดลไม่ได้ทำหน้าที่แค่ตอบคำถาม แต่มันกลายเป็นตัวตัดสินใจว่าผู้ใช้ควรเห็นอะไรต่อ ซึ่งถ้าออกแบบ prompt ไม่ดีพอ มันอาจเลือก UI ผิดแบบ แล้วผู้ใช้ก็งงว่าทำไมอยู่ๆ แอปถามอะไรแปลกๆ
ประเด็นสุดท้ายที่ Ramdoss พูดถึงคือการผสาน on-device AI ที่มีความหน่วงต่ำและเน้นความเป็นส่วนตัวสำหรับแอปมือถือ อันนี้ผมมองว่าสำคัญมาก เพราะมันแก้ปัญหาสองอย่างพร้อมกัน — อย่างแรกคือ latency ที่ลดลงอย่างเห็นได้ชัดเมื่อไม่ต้อง round-trip ไปเซิร์ฟเวอร์ และอย่างที่สองคือเรื่อง privacy ที่ผู้ใช้เริ่มระแวงมากขึ้นทุกวันว่าข้อมูลที่พิมพ์ไปนั้นถูกส่งไปไหนบ้าง
Server-driven UI + BFF
ให้เซิร์ฟเวอร์ตัดสินใจว่า UI ควรเป็นแบบไหนในแต่ละบริบท แล้วส่งคำสั่งมาให้แอปเรนเดอร์ ลดภาระฝั่ง client และแก้เรื่อง latency
Prompt optimization สำหรับ UI selection
ออกแบบ prompt ให้โมเดลเลือก UI component ที่เหมาะกับสถานการณ์ ไม่ใช่แค่ตอบคำถามเก่ง
On-device AI
รันโมเดลบนเครื่องเพื่อลดความหน่วงและรักษาความเป็นส่วนตัวของผู้ใช้
พูดตรงๆ นะครับ สิ่งที่ Ramdoss พูดในงานนี้ไม่ใช่เรื่องใหม่ในเชิงทฤษฎี คนทำ mobile หลายคนรู้จัก BFF กันดีอยู่แล้ว แต่ประเด็นคือการเอามันมาปรับใช้กับงานที่ขับเคลื่อนด้วย LLM ต่างหากที่ยังมีคนทำน้อย และส่วนใหญ่ที่ทำก็ยังทำแบบลวกๆ — ต่อ API แล้วจบ ไม่ได้คิดถึงประสบการณ์ผู้ใช้จริงๆ
ผมมองว่าข่าวนี้สะท้อนความจริงที่เจ็บปวดของวงการ AI บนมือถือในตอนนี้ นั่นคือเรามีโมเดลที่ฉลาดขึ้นเรื่อยๆ แต่ UX ของแอปส่วนใหญ่ยังตามหลังอยู่ไกล หลายทีมยังคิดว่าแค่ใส่ chatbot เข้าไปในแอปก็พอแล้ว ทั้งที่จริงมันเป็นงานวิศวกรรมที่ต้องออกแบบทั้ง stack ตั้งแต่ prompt ไปจนถึงวิธีเรนเดอร์ UI
ถ้าคุณกำลังสร้างแอป AI บนมือถืออยู่ คำถามที่ควรถามตัวเองคือ ผู้ใช้ของคุณต้องรอนานแค่ไหนก่อนจะเห็นอะไรบนจอ และคุณกำลังใช้ on-device AI อยู่หรือยัง ถ้าคำตอบคือ "ยังไม่ได้คิด" ก็ถึงเวลากลับไปดูสถาปัตยกรรมของตัวเองใหม่ได้แล้ว
เรื่องนี้ไม่ใช่แค่เรื่องเทคนิค แต่เป็นเรื่องของประสบการณ์ผู้ใช้ที่ทีมส่วนใหญ่ยังมองข้าม แอป AI บนมือถือจะดีได้ต้องออกแบบทั้ง stack ตั้งแต่ prompt ไปจนถึงวิธีเรนเดอร์ UI ไม่ใช่ต่อ API แล้วหวังว่ามันจะเวิร์กเอง
ที่มา: InfoQ AI/ML — อ่านต้นฉบับ
ความคิดเห็น 6
กำลังโหลดความคิดเห็น...