สิ่งที่ได้เรียนรู้จากการสร้างฟีเจอร์ที่ขับเคลื่อนด้วย AI

• แนวทางที่เป็นระบบตั้งแต่การเลือกฟีเจอร์ที่เหมาะสม ไปจนถึงการลงมือทำและปรับปรุง โดยอ้างอิงจาก ประสบการณ์จริงของ PostHog ที่พัฒนาฟีเจอร์ AI อย่าง Max AI ตลอด 12 เดือน
• ฟีเจอร์ AI อาจทำให้ผลิตภัณฑ์แย่ลงได้ หากเข้าไป แก้ปัญหาที่ช้า ไม่น่าเชื่อถือ หรือไม่มีความหมาย และควรอาศัยแพตเทิร์นที่ผ่านการพิสูจน์แล้ว เช่น การค้นหา/สรุปข้อมูล, ตัวสร้างเนื้อหา, และการใช้เครื่องมือ
• ในขั้นตอนการพัฒนา บริบทและการจัดการสถานะของแอปคือหัวใจสำคัญ โดยใช้การวางแผนคิวรีและ conditional routing เพื่อนำ AI ไปในทิศทางที่ถูกต้อง พร้อมเตรียมรับความล้มเหลวด้วยการมอนิเตอร์และ guardrail
• เพื่อ ปรับความเร็วให้เหมาะสม ควรติดตาม model benchmark อย่างต่อเนื่อง ใช้ทั้งโมเดลเร็วและโมเดลช้าผสมกันตามลักษณะงาน และใช้การประมวลผลแบบ asynchronous
• เพื่อ ประเมินและพัฒนาอย่างต่อเนื่อง ควรใส่ eval ตั้งแต่ช่วงต้น ทำ A/B test และป้องกันไม่ให้ความรู้ด้าน AI กลายเป็นไซโล โดยกระจายความเชี่ยวชาญ AI ไปทั่วทั้งทีม

---

การเลือกว่าจะสร้างอะไร

• ต้องตระหนักว่า AI อาจทำให้ผลิตภัณฑ์แย่ลงได้ และไม่ควรสร้างฟีเจอร์ผิดๆ ที่ไปแก้ปัญหาซึ่งช้าเกินไป ไม่น่าเชื่อถือเกินไป หรือไม่มีใครสนใจ

1. เรียนรู้แพตเทิร์นที่ AI ทำได้ดี

• คัดลอกแพตเทิร์น AI ที่ผ่านการพิสูจน์แล้ว โดยผสาน UX ที่ผู้ใช้คุ้นเคยเข้ากับสิ่งที่ AI ทำได้ดีจริง
  • แพตเทิร์นแรก: "คุยกับเอกสาร/ข้อมูล/PDF" - AI เก่งเรื่องค้นหาและสรุป และสามารถนำไปใช้สร้างรายงานกับคำแนะนำได้ (เช่น Fin ของ Intercom, แชตเอกสารของ Mintlify)
  • แพตเทิร์นที่สอง: ตัวสร้าง หลายประเภท - สร้างหัวข้อ, โค้ด, เอกสาร, SQL, รูปภาพ, ฟิลเตอร์ ฯลฯ (เช่น Lovable, Bolt.new, Figma, Rippling, Notion)
  • แพตเทิร์นที่สาม: การใช้เครื่องมือ - AI ใช้เครื่องมือที่กำหนดไว้อย่างชัดเจนเพื่อทำ workflow ให้เป็นอัตโนมัติและดีขึ้น (เช่น MCP server, Zapier, Atlassian, Asana)
• Max AI ของ PostHog ใช้หลายแพตเทิร์นร่วมกัน
  • คุยกับข้อมูลและเอกสาร
  • สร้าง SQL insight และฟิลเตอร์
  • ใช้เครื่องมืออย่างการสร้างแบบสำรวจและ insight ด้านการวิเคราะห์
  • ในอนาคตมีแผนขยายการใช้เครื่องมือ เช่น ดูและวิเคราะห์ session recording โดยอัตโนมัติ

2. ระบุปัญหาที่ AI สามารถแก้ได้

• โฟกัสที่ คุณค่าที่ AI สามารถมอบให้ได้ แล้วทบทวนงานต่างๆ ทั่วทั้งผลิตภัณฑ์
  • งานเดี่ยวที่ชัดเจน ซึ่งใช้เวลามากกว่า 30 วินาที - เช่น กรอกฟอร์มยาวๆ, ป้อนข้อมูลด้วยมือ, ตั้งค่า integration, ติดตั้ง SDK
  • กรณีที่ผู้ใช้ต้อง ใช้ภาษาหรืออินเทอร์เฟซที่ตนไม่เข้าใจ - เช่น UI ที่ซับซ้อน, SQL query, การสร้างแอป
  • งานที่ทำซ้ำเกิน 20 ครั้ง - เช่น เขียนคำอธิบาย, เขียนสรุป, สร้างรายการ
• คำแนะนำจาก Stephen Whitworth แห่ง incident.io: ให้โฟกัสที่ "สิ่งที่ AI ทำให้งานที่ผู้ใช้ทำวันละ 100 ครั้งดีขึ้นได้" มากกว่า "สิ่งใหม่เจ๋งๆ ที่ AI ทำได้"
  • ตัวอย่าง: ผู้ใช้ชอบสรุป incident ที่สร้างอัตโนมัติมากกว่าการเขียนเอง และตอนนี้ 75% ของสรุป incident ถูกสร้างด้วย AI
• ตัวอย่างการใช้งานใน PostHog
  • AI installation wizard: ลดเวลาติดตั้ง PostHog จากราว 10 นาทีเหลือ 90 วินาที
  • การแปล SQL ของ Max AI: ทำให้เขียน SQL query ที่ซับซ้อนด้วยภาษาธรรมชาติได้ง่ายขึ้น จนแม้ผู้ใช้ที่ไม่คุ้นกับ SQL ก็สร้าง insight แบบกำหนดเองได้

3. ตรวจสอบว่าปัญหานั้นเฉพาะเจาะจงและมีคุณค่าหรือไม่

• ต้องจำกัดขอบเขตให้เป็น ปัญหาที่เฉพาะเจาะจงและมีคุณค่า
• หลุมพรางที่ควรหลีกเลี่ยง
  • เอาแพตเทิร์นเดิมไปใช้กับปัญหาที่ไม่มีคุณค่า: ฟีเจอร์ "คุยกับเอกสาร" อาจไม่จำเป็นในผลิตภัณฑ์เรียบง่ายช่วงเริ่มต้น และอาจกลบปัญหาด้าน usability ที่เป็นแก่นจริงๆ
  • พยายามให้ AI แก้ปัญหาใหญ่เกินไป: AI ไม่ได้ทำให้คุณสร้างรายได้ 1 พันล้านดอลลาร์ได้ในทันที ควรเริ่มจากการแก้ปัญหาแคบๆ ก่อนแล้วค่อยขยาย
• ตอนสร้าง Max ทีมตระหนักได้อย่างรวดเร็วว่าคำถามกว้างเกินไปอย่าง "จะเพิ่มรายได้ได้อย่างไร?" นั้นไม่ได้ผล
  • จึงหันมาโฟกัสที่ ฟีเจอร์ที่เฉพาะเจาะจงซึ่งผสานอยู่ใน PostHog และใช้บริบทของผู้ใช้ใน PostHog ได้
  • ตัวอย่าง: Max เขียน SQL ได้ดีกว่าเพราะรู้ว่ามีตารางอะไรใช้ได้บ้าง และตอบคำถามเกี่ยวกับผลิตภัณฑ์ด้วย visualization แบบ native ได้ เพราะเข้าใจเครื่องมือที่มีอยู่ในระบบ

การนำไอเดียไปสร้างจริง

• ให้โฟกัสที่องค์ประกอบสำคัญเพื่อยืนยันว่าสิ่งที่กำลังสร้างนั้นใช้งานได้จริง

4. บริบทและสถานะของแอปคือหัวใจสำคัญ

• ทุกคนเรียกใช้ OpenAI API ได้ แต่ บริบทของแอปคือสิ่งที่มีเอกลักษณ์
• ข้อมูลที่ใส่เข้าไปได้ เช่น
  • สิ่งที่ผู้ใช้พยายามทำ
  • ใครเป็นคนทำ
  • สถานะของบัญชี
  • ตำแหน่งภายในแอป
  • data schema ของแอป
• เมื่ิอ Max ถูกถามว่า "ทำไมยอดสมัครถึงลดลงเมื่อสัปดาห์ก่อน" ข้อมูลที่ API ได้รับมี เช่น
  • หน้าปัจจุบัน (dashboard, insight ที่แสดงอยู่, ฟิลเตอร์ที่ถูกใช้, บทบาทผู้ใช้)
  • data schema (event ที่ใช้ได้, event property, people property)
  • บัญชี (tier ขององค์กร, เขตเวลา, ระยะเวลาการเก็บข้อมูล)
• ตัวอย่างโค้ดสำหรับจัดรูปแบบ UI context
  • ข้อมูล dashboard (ชื่อ, insight ที่แสดง, ฟิลเตอร์ที่ใช้, ช่วงวันที่)
  • ข้อมูล insight (ชื่อ, ประเภทคิวรี, event ที่วิเคราะห์, การจัดกลุ่ม)
• การจัดการ "บริบท" (สถานะ) ภายใน workflow ก็จำเป็นเช่นกัน
  • ต้องไม่ให้บริบทสูญหายระหว่างบทสนทนา โดยเฉพาะเมื่อมีหลาย sub-agent
  • เก็บและส่งต่อบริบทในทุกส่วนของ workflow
• การปรับบริบทให้เหมาะสมและการเลือกโมเดล มีประสิทธิภาพและมีประโยชน์กว่าการ fine-tune โมเดล

5. ใช้การวางแผนคิวรีและ conditional routing เพื่อนำ AI ไปสู่ความสำเร็จ

• หากปล่อย AI ไว้โดยไม่มีข้อจำกัด มันจะ แสดงพฤติกรรมที่คาดไม่ถึงสารพัดแบบ จึงต้องมีแนวทางนำไปสู่ความสำเร็จ
• การพัฒนาควรทำโดย orchestrate และเชื่อมหลายขั้นตอนเข้าด้วยกัน: query planning → data retrieval → visualization
• นอกจากการจัดการสถานะแล้ว ยังต้องมี
  • ให้ AI รับรู้เครื่องมือและข้อมูล ที่มันใช้ได้
  • ให้มัน เลือกเครื่องมือและข้อมูลที่ถูกต้อง ตามงานที่ตั้งใจจะทำ
  • ตรวจสอบให้แน่ใจว่าเครื่องมืออย่างการรันคิวรีและการจัดรูปแบบ ทำงานได้จริง
• ตัวอย่าง router ระดับบนสุดของ PostHog
  • ตัดสินใจว่าจะสร้าง insight หรือไม่
  • ตัดสินใจว่าจะค้นหาเอกสารหรือไม่
  • ตัดสินใจว่าเกี่ยวข้องกับการเรียกเก็บเงินหรือไม่
• แต่ละ router node มีเงื่อนไขของตัวเองที่เชื่อมไปยังข้อมูลและเครื่องมือที่เหมาะกับงานนั้น
  • ช่วยให้ AI มีองค์ประกอบที่จำเป็นต่อการทำงานให้เสร็จ จึงเพิ่มโอกาสสำเร็จ

6. เตรียมรับความล้มเหลวด้วยการมอนิเตอร์, guardrail และการจัดการข้อผิดพลาด

• แม้โครงสร้างที่สร้างขึ้นจะช่วยลดความล้มเหลวได้ แต่สุดท้าย AI ก็จะชนกับ guardrail อยู่ดี จึง ต้องมี guardrail ให้พร้อม

การมอนิเตอร์

• ใส่การมอนิเตอร์ตั้งแต่แรก เพื่อให้รู้ว่าเมื่อไรเริ่มเกิดปัญหา
• คำแนะนำจาก Georgiy ในทีม Max AI
  • การมอนิเตอร์ production trace เป็นสิ่งจำเป็น
  • ทีมได้สร้างเครื่องมือมอนิเตอร์สำหรับ dogfooding และหวังว่าอยากมีมันตั้งแต่แรก
  • เมื่อขยายสเกล การมอนิเตอร์ trace จะยากขึ้น จึงคิดว่า online eval จะช่วยได้มาก (เป็นลำดับถัดไป)
  • การตรวจบทสนทนา 100 รายการก็ยากแล้ว และการตรวจ 1,000 รายการต่อวันแทบเป็นไปไม่ได้
  • บทสนทนาเหล่านี้คือคำถามและปัญหาจริงจากผู้ใช้ และมอบ insight ทั้งหมดที่จำเป็นต่อการสร้าง agent

การป้องกัน hallucination

• ทุกสิ่งที่ AI สามารถ hallucinate ได้ มันจะ hallucinate ดังนั้นต้องระบุข้อมูลที่ต้องตั้งค่าเองและกฎที่ต้องปฏิบัติตามให้ชัดเจน
• ตัวอย่างกฎของ AI installation wizard
  • ห้าม hallucinate API key เด็ดขาด แต่ให้ใช้ API key ที่ถูกเติมไว้ในไฟล์ .env เสมอ
  • ห้ามเพิ่มคอมเมนต์ placeholder เช่น "// ในแอปจริง..."
  • ห้ามแก้ไข business logic ที่มีอยู่หรือเพิ่มโค้ดจำลองการทำงาน
  • ห้าม import package หรือ library ใหม่ที่ยังไม่ได้ใช้งานอยู่
  • ห้ามสมมติว่าใช้งาน auth library (เช่น Clerk, Auth.js) ได้

Guardrail สำหรับผู้ใช้

• เมื่อเจอกล่องข้อความว่างๆ ผู้คนมักรู้สึกกลัวและลืมทุกอย่างไปหมด
• วิธีแก้คือเพิ่ม คำแนะนำในการใช้ฟีเจอร์ AI เพื่อชี้นำไปในทิศทางที่ถูกต้อง และเตือนว่ามันช่วยอะไรได้บ้าง

การจัดการข้อผิดพลาด

• เนื่องจาก workflow อาจสะดุดเป็นครั้งคราว จึงควรจัดการอย่างนุ่มนวลด้วย การ retry และ rate limit
• สำหรับผู้ใช้ระดับสูง สามารถตั้งค่า การวิเคราะห์ LLM, การติดตามข้อผิดพลาด, และ feature flag ได้
  • PostHog มีทั้งสามอย่างพอดี (บังเอิญสะดวก)

การปรับปรุงฟีเจอร์

• เนื่องจากโมเดล AI พัฒนาอย่างรวดเร็วและคาดเดาได้ยาก ฟีเจอร์ AI จึงต้องการ การบำรุงรักษาและการปรับปรุงอย่างต่อเนื่องมากกว่าที่คิด

7. ป้องกันไม่ให้ความรู้ด้าน AI กลายเป็นไซโล

• การสร้างฟีเจอร์ AI ไม่ควรกลายเป็นความรับผิดชอบของ "คน AI" เพียงคนเดียวในทีม
• AI ต้องถูกผสานลึกเข้าไปในผลิตภัณฑ์ ซึ่งหมายความว่าต้องอาศัยความเชี่ยวชาญจากคนที่คุยกับผู้ใช้และลงมือสร้างสิ่งต่างๆ ให้พวกเขา
• แนวทางที่แนะนำ
  • สร้าง primitive และทำให้ฟีเจอร์ AI นำมาประกอบกันได้: เพื่อให้ทีมไม่ต้องประดิษฐ์ prompt, streaming, consent, eval, analytics ขึ้นมาใหม่ทุกครั้ง และไปโฟกัสกับฟีเจอร์ AI ที่มีเอกลักษณ์และเพิ่มมูลค่าได้
  • รักษาแพตเทิร์น UX ให้สม่ำเสมอทั้งแอป: ในกรณีของ PostHog คือ Max เพื่อป้องกันความสับสนจาก AI widget นับพันแบบ
  • ส่งผู้เชี่ยวชาญ AI ไปช่วยทีมชั่วคราว: เพื่อช่วยให้ทีมสร้างฟีเจอร์ AI ได้เร็วขึ้น และกระจายความรู้ด้าน AI ไปทั่วทั้งองค์กร (ทีม Max AI ทำเช่นนี้)

8. โฟกัสที่ความเร็ว

• หนึ่งในความท้าทายใหญ่ของฟีเจอร์ AI โดยเฉพาะฟีเจอร์ที่ซับซ้อนคือ ความช้า
• workflow มักหมายถึง การเรียกใช้ผู้ให้บริการ LLM หลายครั้ง ซึ่งนำไปสู่ latency จำนวนมาก
• เรื่องนี้อาจ น่าหงุดหงิดเป็นพิเศษเมื่อมีวิธีอื่นในการทำงานเดียวกันให้เสร็จในแอปหรือเว็บไซต์อยู่แล้ว
• คำแนะนำจาก Rahul Vohra ผู้ก่อตั้ง Superhuman: "ความเร็วคือผู้ชนะ"
  • ตัวอย่าง: Instant Reply หรือ Auto Summarize
  • Gmail และ Outlook ก็มีฟีเจอร์คล้ายกัน แต่ต้องสร้างคำตอบและสรุปเมื่อมีการร้องขอ และผู้ใช้ต้องรอจนกว่าจะเสร็จ
  • ใน Superhuman มีการ precompute สิ่งเหล่านี้ไว้ล่วงหน้าเพื่อให้พร้อมใช้งานทันทีเสมอ และความต่างเล็กๆ นี้ส่งผลมหาศาลต่อประสบการณ์ผู้ใช้

วิธีปรับปรุง

• ติดตาม model benchmark และการออกรุ่นใหม่ของโมเดล: เมื่อมีโมเดลที่ดีกว่าและเร็วกว่าออกมา ก็ทดสอบและนำมาใช้เพื่อให้ได้การพัฒนาที่ดีที่สุดทั้งด้านฟังก์ชันและความเร็ว (ใช้การวิเคราะห์ LLM)
• ผสมใช้โมเดลเร็วและโมเดลช้าตามลักษณะงาน
  • ใช้ โมเดลเร็ว (gpt-4.1-mini, gpt-4.1-nano) กับการสร้างหัวข้อ, ฟิลเตอร์สำหรับ session replay, สรุปแบบสำรวจ, และการค้นหา insight
  • ใช้ โมเดลช้า (gpt-4.1) กับการสร้าง schema, การจัดการบทสนทนา, และการจัดการบริบท
• ใช้การประมวลผลแบบ asynchronous: งาน AI ที่ซับซ้อนอย่างการสรุป session และการดึงรูปแบบ จะรันแบบ asynchronous ผ่าน Temporal workflow โดยไม่บล็อกการโต้ตอบของผู้ใช้ จากนั้นแคชไว้ใน Redis เพื่อรองรับการลองใหม่โดยไม่ต้องคำนวณซ้ำ

9. มอนิเตอร์และประเมินประสิทธิผลอย่างต่อเนื่อง

• ฟีเจอร์ใหม่ไม่ควรถูกตัดสินอย่างหละหลวมเพียงเพราะมันเป็น ✨ AI ✨
• ไอเดียที่ไม่ดีอาจทำให้ผลิตภัณฑ์แย่ลง และการเปลี่ยนแปลงของโมเดลอาจส่งผลลบต่อประสบการณ์โดยที่ผู้ใช้ไม่ทันรู้ตัว

วิธีประเมินประสิทธิผล

• เพิ่ม eval ตั้งแต่เนิ่นๆ: แม้จะเป็น golden dataset หรือ synthetic dataset ขนาดเล็ก ก็ช่วยเพิ่มประสิทธิภาพได้อย่างมากเมื่อเทียบกับวงจรพัฒนาปกติ และเมื่อลงมือในระดับสเกลจริงก็พบว่าทำได้ง่ายกว่าที่คิด อีกทั้งยังช่วยให้การสร้างฟีเจอร์ในอนาคตเร็วขึ้น
• ทำ A/B test: เปรียบเทียบฟีเจอร์ AI กับประสบการณ์ปกติ รวมถึงทดสอบ prompt, บริบท, workflow ที่หลากหลาย
• ตรวจดูอัตราการใช้งาน AI ของลูกค้าหลายประเภท (เช่น ผู้ใช้ฟรี vs ลูกค้า enterprise, ฝั่ง product vs sales)
  • การค้นพบว่า product manager และ marketer ใช้ Max บ่อยกว่าวิศวกรผลิตภัณฑ์ ซึ่งเป็นกลุ่มลูกค้าในอุดมคติ ทำให้ต้องกลับมาทบทวน roadmap
• ให้ผู้ใช้ประเมินคำตอบ AI ว่าดี/ไม่ดีได้: หากผู้ใช้ให้คะแนนไม่ดี ให้ขอรายละเอียดเพิ่มเติมเพื่อนำไปปรับบริบท, prompt, และ workflow
• เปรียบเทียบการใช้งาน AI กับไม่ใช้ AI: ใช้ตัวชี้วัดด้าน activation และ retention ที่มีอยู่เพื่อทำความเข้าใจว่า AI เหมาะจะอยู่ตรงไหนในผลิตภัณฑ์และวงจรชีวิตผู้ใช้ รวมถึงส่งผลเชิงบวกจริงหรือไม่

สรุป

• บทเรียนทั้ง 9 ข้อนี้ไม่ได้แยกขาดจากกัน แต่ ทำงานร่วมกัน
• การคิดว่าข้ามทุกอย่างไปแล้วไปโฟกัสที่การปรับ eval ตอนท้าย = การสร้างผลิตภัณฑ์ที่ยอดเยี่ยม นั้นเป็นความเข้าใจที่ผิด
• เป้าหมายคือ สร้างสิ่งที่มีคุณค่าให้ผู้ใช้ ไม่ใช่เดโมเทคโนโลยีที่ดูหวือหวา
• การเป็น AI ไม่ได้หมายความว่าผู้ใช้จะเห็นคุณค่าโดยอัตโนมัติ
• บทเรียนทั้งหมดที่เราเคยเรียนรู้เกี่ยวกับการสร้างผลิตภัณฑ์ที่ยอดเยี่ยมยังคงใช้ได้เหมือนเดิม
  • คุยกับผู้ใช้
  • ออกของให้เร็ว
  • ทำการทดลอง
  • ทำซ้ำ