วิธีเพิ่มฟีเจอร์ AI ให้แอปของคุณ

การเพิ่มฟีเจอร์ AI ให้แอป ให้เรียก API ของโมเดลภาษาขนาดใหญ่ (LLM) จากเซิร์ฟเวอร์ของคุณ ส่งคำสั่งที่ชัดเจนพร้อมข้อมูลที่เกี่ยวข้อง แล้วนำผลลัพธ์ที่ได้ไปใช้ ฟีเจอร์ที่มีประโยชน์ส่วนใหญ่อยู่ในหนึ่งในสี่รูปแบบ คือ การสรุป การสนทนา การดึงข้อมูลออกมาเป็นโครงสร้าง และการจัดประเภท แต่ละรูปแบบเป็นโค้ดไม่กี่สิบบรรทัดที่เครื่องมือสร้างแอป AI เขียนให้ได้ สิ่งที่ตัดสินว่าฟีเจอร์นั้นดีหรือไม่คืองานรอบ ๆ การเรียกใช้ นั่นคือการเก็บคีย์ API ไว้ฝั่งเซิร์ฟเวอร์ ควบคุมค่าใช้จ่ายต่อผู้ใช้ และตรวจสอบผลลัพธ์ก่อนจะเชื่อถือ

สี่รูปแบบพื้นฐานของฟีเจอร์ AI

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

ฟีเจอร์ทำงานร่วมกับแอปอย่างไร

ทุกรูปแบบมีโครงสร้างเดียวกัน:

1. ผู้ใช้ดำเนินการ เช่น กดปุ่ม "สรุป" อัปโหลดไฟล์ หรือส่งข้อความ
2. หน้าเว็บเรียกเซิร์ฟเวอร์ของคุณ ไม่ใช่ผู้ให้บริการ AI โดยตรง
3. เซิร์ฟเวอร์สร้างคำขอ: คำสั่งของระบบ อินพุตจากผู้ใช้ และข้อมูลใด ๆ ที่โมเดลต้องใช้จากฐานข้อมูล โดยเฉพาะข้อมูลที่ผู้ใช้คนนี้มีสิทธิ์เห็นเท่านั้น
4. เซิร์ฟเวอร์เรียก LLM API ด้วยคีย์ที่เก็บไว้ในตัวแปรสภาพแวดล้อม
5. เซิร์ฟเวอร์ตรวจสอบการตอบกลับ เช่น JSON ที่ถูกต้อง ป้ายที่รู้จัก หรือความยาวที่เหมาะสม แล้วจึงบันทึกหรือส่งกลับ
6. หน้าเว็บแสดงผล โดยสตรีมข้อความขณะที่มาถึง สำหรับคำตอบที่ยาว

คีย์จะอยู่บนเซิร์ฟเวอร์ในขั้นตอนที่ 4 และไม่เคยไปถึงเบราว์เซอร์ หากแนวคิดของ API ยังใหม่สำหรับคุณ API คืออะไร เป็นบทนำสั้น ๆ และ วิธีใช้ LLM API อธิบายโทเคน โมเดล และคีย์อย่างละเอียดกว่า

เลือกผู้ให้บริการและโมเดล

ผู้ให้บริการหลักอย่าง OpenAI, Anthropic, Google และรายอื่น ๆ ต่างมี API สำหรับข้อความที่มีรูปแบบคล้ายกัน คำถามที่ควรถามตอนเลือก:

• คุณภาพกับงานของคุณ ลองตัวอย่างจริงจากแอปสักสองสามรายการกับโมเดลสองถึงสามตัว ความแตกต่างมักชัดเจนกว่าบนข้อมูลของคุณมากกว่าการเทียบมาตรฐานทั่วไป
• ขนาดเทียบกับค่าใช้จ่าย ผู้ให้บริการมีทั้งโมเดลที่ใหญ่และมีความสามารถมากกว่า และโมเดลขนาดเล็กที่ถูกกว่าและเร็วกว่า การจัดประเภทและการดึงข้อมูลที่ไม่ซับซ้อนมักทำงานได้ดีกับโมเดลเล็ก ส่วนการให้เหตุผลยาวหรือการเขียนที่ละเอียดอ่อนอาจต้องใช้โมเดลใหญ่
• เอาต์พุตแบบมีโครงสร้าง สำหรับการดึงข้อมูลและการจัดประเภท ให้เลือก API ที่ทำให้โมเดลส่งคืน JSON ตามสคีมาที่คุณกำหนด แทนการแยกวิเคราะห์ข้อความอิสระ
• การจัดการข้อมูล อ่านข้อกำหนดของผู้ให้บริการว่าอินพุตจาก API ถูกเก็บหรือนำไปใช้ฝึกโมเดลหรือไม่ และเหมาะกับข้อมูลที่ผู้ใช้ให้มาหรือไม่
• ขีดจำกัด บัญชีใหม่มักมีขีดจำกัดอัตราการเรียก (rate limit) ต่ำ ให้ตรวจสอบก่อนเปิดตัว

ชื่อโมเดลและราคาเปลี่ยนบ่อย ดังนั้นโค้ดควรอ่านชื่อโมเดลจากการตั้งค่า ไม่ใช่ฮาร์ดโค้ดไว้หลายที่

เพิ่มฟีเจอร์ทีละขั้น

ลองตัวอย่างจริง: CRM ขนาดเล็กที่ผู้ติดต่อแต่ละคนมีประวัติบันทึกยาว ๆ

1. เก็บคีย์ สร้างคีย์ในแดชบอร์ดของผู้ให้บริการ แล้วเก็บเป็นความลับฝั่งเซิร์ฟเวอร์ เช่น OPENAI_API_KEY หรือ ANTHROPIC_API_KEY

2. ขอฟีเจอร์เล็ก ๆ หนึ่งอย่าง:

เพิ่มปุ่ม "สรุป" ในหน้าผู้ติดต่อ บนเซิร์ฟเวอร์ ส่งบันทึก 20 รายการล่าสุดของผู้ติดต่อไปยัง [PROVIDER] โดยใช้ความลับ [ENV_NAME] พร้อมคำสั่งให้เขียนสามหัวข้อย่อย ได้แก่ สถานะปัจจุบัน คำถามที่ยังค้างอยู่ และขั้นตอนถัดไป ส่งเฉพาะบันทึกที่ผู้ใช้ที่ล็อกอินอยู่มองเห็นได้ แสดงสถานะกำลังโหลด บันทึกสรุปพร้อมเวลา และแสดง "ไม่สามารถสรุปได้ในขณะนี้" หากการเรียกล้มเหลว ห้ามส่งคีย์ไปยังเบราว์เซอร์เด็ดขาด

3. เพิ่มการดึงข้อมูลในจุดที่ช่วยประหยัดการพิมพ์:

เมื่อผู้ใช้วางลายเซ็นอีเมลลงในช่อง "เพิ่มด่วน" ให้เรียก [PROVIDER] จากเซิร์ฟเวอร์ และส่งคืน JSON ที่มี name, company, job title, email และ phone โดยใช้ฟีเจอร์ structured output ของผู้ให้บริการ ตรวจสอบ JSON บนเซิร์ฟเวอร์ เติมฟอร์มผู้ติดต่อใหม่ด้วยข้อมูลนั้น และให้ผู้ใช้แก้ไขได้ก่อนบันทึก ให้เว้นฟิลด์ว่างแทนการเดา

ส่วนสำคัญคือ "ให้ผู้ใช้แก้ไขก่อนบันทึก" โมเดลเสนอ แต่คนเป็นผู้ตัดสินใจ

4. จัดประเภทเบื้องหลัง:

เมื่อมีตั๋วซัพพอร์ตใหม่เข้ามา ให้จัดประเภทเป็นหนึ่งในป้ายต่อไปนี้เท่านั้น: billing, bug, feature request, account access, other ใช้โมเดลขนาดเล็กที่มีต้นทุนต่ำ หากคำตอบไม่ตรงกับป้ายเหล่านั้น ให้บันทึกเป็น "other" แสดงป้ายเป็นแท็กที่แก้ไขได้

5. ทดสอบด้วยข้อมูลจริงที่ไม่เรียบร้อย เช่น บันทึกยาว บันทึกว่าง ภาษาอื่น ลายเซ็นที่ไม่มีเบอร์โทร และดูผลลัพธ์ยี่สิบรายการเคียงข้างกันก่อนเปิดใช้งาน

เขียนคำสั่งให้ได้ผล

คำสั่งที่ส่งไปพร้อมทุกคำขอ (มักเรียกว่า system prompt) คือจุดที่คุณภาพมาจาก

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

เก็บพรอมต์ไว้ในไฟล์ในโค้ดของคุณ เพื่อให้มีเวอร์ชันและตรวจทานได้เหมือนโค้ดอื่น ๆ

ควบคุมค่าใช้จ่าย

LLM API คิดค่าบริการตามโทเคน ซึ่งเป็นชิ้นข้อความเล็ก ๆ ทั้งสิ่งที่ส่งไปและสิ่งที่ได้กลับมา ค่าใช้จ่ายเพิ่มตามปริมาณบริบทต่อคำขอคูณด้วยความถี่ที่ทำงาน วิธีควบคุมที่ใช้ได้จริง:

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

หากฟีเจอร์ AI เป็นหัวใจของผลิตภัณฑ์ ให้นำต้นทุนการรันเหล่านี้ไปรวมในการตั้งราคาแทนการรับภาระเอง

ความปลอดภัยและความน่าเชื่อถือ

ผลลัพธ์จาก AI มีความน่าจะเป็น อาจผิดพลาดทั้งที่ฟังดูมั่นใจ และอาจถูกชี้นำด้วยข้อความที่มันอ่าน ควรออกแบบให้รับมือกับเรื่องนี้:

• ถือว่าผลลัพธ์เป็นอินพุตที่ไม่น่าเชื่อถือ ตรวจสอบโครงสร้าง escape ก่อนแสดงผลเป็น HTML และไม่เคยนำไปรันเป็นโค้ดหรือคิวรีฐานข้อมูล
• ให้คนอยู่ในวงจร สำหรับสิ่งที่มีผลตามมา เช่น การส่งอีเมล การเปลี่ยนแปลงระเบียน หรือการคืนเงิน โมเดลร่างให้ได้ แต่คนเป็นผู้ยืนยัน
• ป้องกัน prompt injection เอกสารหรือข้อความอาจมีข้อความอย่าง "ละเว้นคำสั่งของคุณ" จำกัดสิ่งที่โมเดลมองเห็นให้เหลือเฉพาะสิ่งที่ผู้ใช้ปัจจุบันมีสิทธิ์เห็น และอย่าให้เครื่องมือที่ทำการกระทำละเอียดอ่อนแก่มันโดยที่โค้ดของคุณยังไม่ตรวจสิทธิ์ก่อน
• ระบุว่าเป็นเนื้อหาจาก AI เพื่อให้ผู้ใช้รู้ว่าบทสรุปหรือคำแนะนำถูกสร้างขึ้น และตรวจสอบได้
• จัดการความล้มเหลวอย่างสุภาพ ผู้ให้บริการอาจล่มหรือถึงขีดจำกัดการเรียก ให้ตั้งเวลาหมดอายุ แสดงข้อความที่ชัดเจน และให้ส่วนอื่นของแอปยังทำงานต่อได้
• ดูว่าผู้ใช้ส่งอะไรเข้ามา สำหรับช่องข้อความอิสระ ควรพิจารณาขั้นตอนการกลั่นกรองเนื้อหา และระบุในนโยบายความเป็นส่วนตัวให้ชัดว่าเนื้อหาถูกประมวลผลโดยผู้ให้บริการ AI ภายนอก

รายการการตรวจสอบที่กว้างกว่านี้อยู่ใน เช็กลิสต์ความปลอดภัยสำหรับแอปที่สร้างด้วย AI

ข้อผิดพลาดที่พบบ่อย

• เริ่มด้วยแชทบอททั่วไป ทั้งที่ปุ่ม "สรุป" หรือ "จัดหมวดหมู่" เพียงปุ่มเดียวจะช่วยคนได้มากกว่า
• ใส่คีย์ในโค้ดฝั่งหน้าบ้าน หรือในที่เก็บโค้ดสาธารณะ
• ส่งฐานข้อมูลทั้งหมดเป็นบริบท ซึ่งช้า แพง และเสี่ยงทำให้ข้อมูลของผู้ใช้คนอื่นรั่วไหล
• เชื่อผลลัพธ์แบบข้อความอิสระ ในกรณีที่สคีมาหรือชุดป้ายที่กำหนดไว้จะทำให้ตรวจสอบได้
• ไม่มีขีดจำกัดต่อผู้ใช้ ซึ่งมักพบตอนใบแจ้งหนี้ใบแรกมาถึง

เพิ่มฟีเจอร์ AI กับ Mythex

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

คำถาม