กำไร:
- ความสามารถในการสร้างสถาปัตยกรรม Cloud LLM ที่ปลอดภัยซึ่งไม่ได้เก็บคีย์ API ไว้บนไคลเอนต์ แต่ต้องผ่านพร็อกซีส่วนหลัง
- ความสามารถในการเขียนการบูรณาการที่แข็งแกร่งซึ่งจะเพิ่มความเร็วการรับรู้ด้วยการสตรีม และจัดการกับสถานการณ์ต่างๆ อย่างนุ่มนวล เช่น การหมดเวลา ข้อผิดพลาดของเครือข่าย และการจำกัดความเร็ว
- ความสามารถในการลดต้นทุนโดยการลดโทเค็นที่ส่งและตั้งคำถามถึงความจำเป็นของข้อมูลส่วนบุคคลก่อนที่จะไปยังคลาวด์
AI บนอุปกรณ์ทรงพลังแต่มีข้อจำกัด เมื่อคุณต้องการเพิ่ม “ผู้ช่วยแชทอัจฉริยะ” อย่างแท้จริง การสรุปข้อความยาว หรือการผลิตเชิงสร้างสรรค์ที่ซับซ้อนให้กับแอป คุณต้องมีโมเดลที่ใหญ่เกินกว่าจะใส่ลงในโทรศัพท์ได้ นี่คือจุดที่ Cloud AI เข้ามามีบทบาท: แอปพลิเคชันของคุณเชื่อมต่อกับโมเดลภาษาขนาดใหญ่ (LLM) ผ่าน API (Application Programming Interface - อินเทอร์เฟซมาตรฐานที่ซอฟต์แวร์สองตัวส่งและรับข้อมูลระหว่างกัน) ในหน่วยนี้ เราจะได้เรียนรู้วิธีรวม Cloud LLM เข้ากับแอปพลิเคชันมือถือในลักษณะที่ปลอดภัย รวดเร็ว และคำนึงถึงต้นทุน การเน้นที่สำคัญคือเรื่องความปลอดภัย: การรวม LLM ที่ติดตั้งไม่ถูกต้องอาจทำให้คีย์ API ของคุณรั่วไหลและส่งผลให้มีค่าใช้จ่ายหลายพันปอนด์
กฎทองของสถาปัตยกรรม: เก็บกุญแจไว้ที่ไคลเอนต์
ข้อผิดพลาดที่อันตรายที่สุดที่สามารถทำได้ในการรวม Cloud AI คือการฝังคีย์ API (รหัสผ่านลับที่อนุญาตให้ใช้บริการ) ลงในโค้ดแอปพลิเคชันมือถือโดยตรง แอปพลิเคชันบนมือถือจะถูกดาวน์โหลดลงในอุปกรณ์ของผู้ใช้ และสามารถอ่านโค้ดได้โดยวิศวกรรมย้อนกลับ โดยแยกวิเคราะห์แอปพลิเคชันที่คอมไพล์แล้วและดูว่ามีอะไรอยู่ข้างใน หากคีย์ของคุณอยู่ในแอป บุคคลอื่นสามารถดึงข้อมูลและร้องขอจากบัญชีของคุณได้ไม่จำกัด
สถาปัตยกรรมที่ถูกต้องคือ: แอปพลิเคชันบนมือถือส่งคำขอไปยังเซิร์ฟเวอร์แบ็กเอนด์ของคุณเอง (พร็อกซีเซิร์ฟเวอร์ที่คุณควบคุม) คีย์อยู่บนเซิร์ฟเวอร์เท่านั้น เซิร์ฟเวอร์ไปที่บริการ LLM และส่งคืนการตอบสนองต่อแอปพลิเคชัน มิดเดิลแวร์นี้ยังให้การกำหนดความเร็วสูงสุด การป้องกันการละเมิด และการควบคุมต้นทุนอีกด้วย
แนวทาง
กุญแจอยู่ที่ไหน
ความปลอดภัย
รหัสอยู่ในแอปพลิเคชัน (FALSE)
ในไคลเอนต์สาธารณะ
มันรั่วบิลระเบิด
กุญแจสำคัญอยู่ในแบ็กเอนด์ (TRUE)
บนเซิร์ฟเวอร์ซ่อนอยู่
ปลอดภัยควบคุมได้
ข้อควรระวัง: เมื่อคุณขอให้ AI สำหรับการผสานรวม LLM บนคลาวด์ ระบบอาจสร้างตัวอย่างที่เขียนคีย์ลงในโค้ดแอปพลิเคชันโดยตรงเพื่อความสะดวกของคุณ ไม่เคยถ่ายทอดสดนี้ อย่าลืมใส่ประโยค "คีย์ API ไม่ควรอยู่บนไคลเอนต์ ให้ผ่านพร็อกซีแบ็กเอนด์" ในข้อความแจ้ง
สตรีมมิ่ง: เพิ่มความเร็วการรับรู้
คำตอบของ LLM อาจใช้เวลานานและใช้เวลาไม่กี่วินาทีในการสร้างคำตอบทั้งหมด การปล่อยให้ผู้ใช้รอบนหน้าจอว่างเปล่าถือเป็นประสบการณ์ที่ไม่ดี วิธีแก้ปัญหาคือการสตรีม — แสดงคำตอบทีละคำในขณะที่ถูกสร้างขึ้น ผู้ใช้ตรวจสอบการสะกดข้อความ เช่นเดียวกับใน ChatGPT สิ่งนี้จะเพิ่มความเร็วและความคล่องแคล่วในการรับรู้อย่างมาก Flow บนมือถือหมายถึงการเพิ่มชิ้นส่วน (โทเค็น — ชิ้นส่วนของข้อความที่สร้างโดยโมเดล) จากเซิร์ฟเวอร์ไปยังอินเทอร์เฟซเมื่อมาถึง ขอขั้นตอนอย่างชัดเจนเมื่อพิมพ์การรวมเข้ากับ AI
เคล็ดลับ: เพิ่มปุ่ม "หยุดชั่วคราว" ในการตอบกลับการสตรีม ผู้ใช้ควรจะสามารถหยุดการผลิตได้เมื่อเขาได้รับคำตอบที่ต้องการ สิ่งนี้ทั้งปรับปรุงประสบการณ์และลดต้นทุนโดยการตัดการสร้างโทเค็นที่ไม่จำเป็น ในระหว่างคำตอบยาวๆ ผู้ใช้อาจพบคำตอบแล้ว
การจัดการต้นทุน ความล่าช้า และข้อผิดพลาด
Cloud LLM มีค่าใช้จ่ายด้านเงิน (ค่าธรรมเนียมต่อโทเค็น) และต้นทุนด้านเวลา (เวลาแฝง) ในแต่ละคำขอ วินัยสามประการเป็นสิ่งจำเป็น Cost: limit prompt and response length, do not send unnecessarily long system instructions, default to small and cheap model if possible. เวลาแฝง: ใช้สตรีมมิ่ง, ตั้งเวลา, แจ้งให้ผู้ใช้ทราบหากเครือข่ายช้า ข้อผิดพลาด: เครือข่ายขัดข้อง บริการอาจส่งคืน 429 (คำขอมากเกินไป) หรือ 500 (ข้อผิดพลาดของเซิร์ฟเวอร์) จัดการแต่ละอย่างเบา ๆ อย่าทำให้แอปขัดข้อง นอกจากนี้ LLM บางครั้งให้คำตอบที่ไม่มีความหมายหรือไม่ถูกต้อง (ภาพหลอน) เพิ่มการตรวจสอบคำตอบอีกชั้นในพื้นที่วิกฤติ
มินิเคสสามอัน
กรณีที่ 1 — กุญแจรั่ว สตาร์ทอัพฝังคีย์ OpenAI ลงในแอป React Native โดยตรงเพื่อออกอย่างรวดเร็ว สามสัปดาห์หลังจากแอปเปิดตัว คีย์ได้รับการออกแบบทางวิศวกรรมย้อนกลับและใช้งานได้มูลค่า 2,400 ดอลลาร์ในชั่วข้ามคืน ทีมงานต้องเพิกถอนคีย์และตั้งค่าพร็อกซีแบ็กเอนด์ บทเรียน: ทางลัดที่ใช้สะดวกกลายเป็นเส้นทางที่แพงที่สุด
กรณีที่ 2 — การออกกลางคันลดลงตามการไหล แอปการศึกษาเปิดตัวฟีเจอร์ถามตอบโดยไม่ต้องสตรีมเป็นครั้งแรก ผู้ใช้ออกจากระบบหลังจากรอเป็นเวลา 6 วินาที เมื่อเพิ่มโฟลว์ คำแรกเริ่มปรากฏใน 0.8 วินาที และอัตราการละทิ้งลดลงจาก 48% เป็น 12% รุ่นเดียวกัน ความเร็วเท่ากัน ต่างกันแค่การนำเสนอเท่านั้น
กรณีที่ 3 — การควบคุมต้นทุน แอปหนึ่งส่งประวัติการแชททั้งหมดไปยังโมเดลพร้อมทุกข้อความผู้ใช้ ในการสนทนาที่ยาวนาน คำขอเดียวมีถึง 8,000 โทเค็น ส่งผลให้ต้นทุนสูงขึ้น ด้วยการส่งข้อความและสรุปเพียงไม่กี่ข้อความล่าสุด ทีมงานจึงลดโทเค็นต่อคำขอลง 70% และลดการเรียกเก็บเงินรายเดือนเหลือหนึ่งในสาม บทเรียน: วัดสิ่งที่คุณส่ง
พรอมต์อ่อน / พรอมต์แข็งแกร่ง
ข้อความเตือนที่อ่อนแอ: "เพิ่มการแชทเช่น ChatGPT ลงในแอปของฉัน"
ข้อความแจ้งที่มีประสิทธิภาพ: "เพิ่มผู้ช่วยแชทลงในแอปพลิเคชัน iOS/Swift ของฉัน สถาปัตยกรรม: แอปพลิเคชันส่งคำขอไปยังแบ็กเอนด์ของฉันเอง คีย์ LLM API ไม่ได้อยู่ในไคลเอนต์ แต่จะส่งผ่านพร็อกซี - การตอบสนองมาแบบสตรีม แสดงคำต่อคำ - ปุ่ม 'หยุด' ขัดจังหวะการผลิต - จัดการการหมดเวลา ข้อผิดพลาดของเครือข่าย สถานการณ์ 429 และ 500 อย่างงดงาม - ลดประวัติการแชท: ส่งข้อความ 6 ข้อความล่าสุด + สรุป (การควบคุมต้นทุน) อธิบายไดอะแกรมสถาปัตยกรรมก่อน จากนั้นให้รหัสไคลเอ็นต์และพร็อกซีแยกกัน"
เทมเพลตที่คัดลอกได้
เทมเพลตสถาปัตยกรรมที่ปลอดภัย:"ออกแบบการรวม LLM บนคลาวด์เข้ากับแอปพลิเคชัน [แพลตฟอร์ม] ของฉัน กฎ: คีย์ API เฉพาะในแบ็กเอนด์ ไคลเอนต์ -> พร็อกซีของฉัน -> LLM ในพร็อกซี: การรับรองความถูกต้อง การจำกัดอัตราต่อผู้ใช้ การบันทึกคำขอ แสดงรายการความรับผิดชอบของไคลเอ็นต์และพร็อกซีแยกกัน จากนั้นส่งออกโค้ด"
เทมเพลตการสตรีม: "เพิ่มการตอบกลับแบบสตรีมไปที่หน้าจอแชทนี้:- เพิ่มตัวอย่างลงในฟองข้อความเมื่อมาถึง- แสดงเคอร์เซอร์/ภาพเคลื่อนไหวขณะพิมพ์- ให้ปุ่ม 'หยุด' ยกเลิกการสตรีม- เก็บข้อความบางส่วนไว้และเตือนหากมีข้อผิดพลาดในขณะที่สตรีมกำลังสิ้นสุด[รหัสที่มีอยู่]"
เทมเพลตต้นทุนเวลาแฝง: "ลดต้นทุนและเวลาแฝงในการรวม LLM นี้:- ฉันจะลดโทเค็นที่ส่งได้อย่างไร (ตัวย่อประวัติ สรุป) - ในกรณีนี้โมเดลที่เล็กกว่า/ถูกกว่าก็เพียงพอแล้ว - แนะนำการหมดเวลาและลองกลยุทธ์อีกครั้ง [รหัส]"
เทมเพลตการยอมรับข้อผิดพลาด: "ทำให้การโทร LLM นี้มีความยืดหยุ่น: - แยกพฤติกรรมสำหรับเครือข่ายที่ไม่มี, หมดเวลา, 429 (ขีดจำกัดอัตรา), 500 (เซิร์ฟเวอร์) - ข้อความที่ไม่ใช่ด้านเทคนิคและสุภาพถึงผู้ใช้ - บันทึกการตรวจสอบความเสี่ยงต่อการเกิดภาพหลอนในการตอบกลับที่สำคัญ [รหัส]"
ข้อผิดพลาดทั่วไป
- การฝังคีย์ API ลงในแอปพลิเคชัน จุดบกพร่องด้านความปลอดภัยที่แพงที่สุดและพบบ่อยที่สุด กุญแจสำคัญอยู่ที่ส่วนหลังอย่างแน่นอน
- ไม่ใช้กระแส. การปล่อยให้ผู้ใช้รอคำตอบยาวๆ จะเป็นการผลักผู้ใช้ออกไป
- ส่งประวัติการแชททั้งหมดพร้อมทุกคำขอ มันเพิ่มต้นทุนโทเค็นและเวลาแฝง
- ข้ามเงื่อนไขข้อผิดพลาด หากไม่ได้ระบุ 429/500/timeout แอปพลิเคชันจะหยุดทำงานหรือค้าง
- พิจารณาคำตอบของ LLM ว่าถูกต้องโดยไม่มีคำถาม ภาพหลอนนั้นมีจริง เพิ่มชั้นการตรวจสอบในพื้นที่วิกฤติ
- การส่งข้อมูลผู้ใช้ไปยัง LLM ที่ไม่จำเป็น ถามว่าข้อมูลส่วนบุคคลจำเป็นหรือควรปกปิดก่อนที่จะส่งไปยังคลาวด์
โดยสรุป
Cloud LLM นำความสามารถที่ยอดเยี่ยมที่ไม่เหมาะกับอุปกรณ์มาสู่มือถือ แต่ต้องมีวินัยด้านความปลอดภัยและต้นทุน กฎทอง: คีย์ API ไม่เคยอยู่บนไคลเอนต์ แต่จะผ่านพร็อกซีแบ็กเอนด์ โฟลว์ช่วยเพิ่มความเร็วและการรับรู้การรับรู้อย่างมาก สนับสนุนโดยปุ่ม "หยุด" ต้นทุนถูกกำหนดโดยการลดทอนโทเค็นที่ส่ง ความสามารถในการฟื้นตัวเกิดขึ้นได้จากการจัดการทุกกรณีข้อผิดพลาดอย่างสง่างาม คำตอบของ LLM อาจรวมถึงภาพหลอน ในพื้นที่ที่สำคัญ การยืนยันถือเป็นสิ่งสำคัญและข้อมูลส่วนบุคคลจะได้รับการตรวจสอบก่อนส่งไปยังคลาวด์
งานสมัคร
ขอการออกแบบพร็อกซีไคลเอ็นต์ + แบ็กเอนด์จาก AI โดยใช้ "เทมเพลตสถาปัตยกรรมที่ปลอดภัย" สำหรับคุณสมบัติ "การสรุปข้อความ" หรือ "แชท" ตรวจสอบว่าคีย์ API อยู่ในแบ็กเอนด์ในการออกแบบที่สร้างขึ้นเท่านั้น จากนั้นแยกอย่างน้อยสองวิธีในการลดโทเค็นที่ส่งด้วย "รูปแบบความล่าช้าต้นทุน" และเขียนข้อความสุภาพที่จะแสดงต่อผู้ใช้เพื่อดูเงื่อนไขข้อผิดพลาด (เช่น 429)
รายการตรวจสอบ
- [ ] ฉันตรวจสอบแล้วว่าคีย์ API อยู่ในแบ็กเอนด์ ไม่ใช่บนไคลเอ็นต์
- [ ] ฉันทำการสตรีมการตอบสนองและเพิ่มปุ่ม "หยุดชั่วคราว"
- [ ] ฉันจัดการการหมดเวลา ข้อผิดพลาดของเครือข่าย สถานการณ์ 429 และ 500
- [ ] ฉันลดโทเค็นที่ส่งด้วยตัวย่อ/สรุปที่ผ่านมา
- [ ] ฉันพิจารณาการตรวจสอบความเสี่ยงต่อการเกิดอาการประสาทหลอนในคำตอบของ LLM
- [ ] ฉันตรวจสอบความจำเป็น/การปกปิดข้อมูลส่วนบุคคลก่อนที่จะไปที่ระบบคลาวด์