المكاسب:
- القدرة على إنشاء بنية LLM سحابية آمنة لا تحتفظ بمفتاح API على العميل ولكنها تمر عبر وكيل خلفي
- القدرة على كتابة عمليات تكامل قوية تزيد من السرعة الملموسة من خلال البث والتعامل بلطف مع المواقف مثل المهلات وأخطاء الشبكة وحدود السرعة
- القدرة على تقليل التكلفة عن طريق تقصير الرمز المميز المرسل والتشكيك في ضرورة البيانات الشخصية قبل أن تنتقل إلى السحابة
الذكاء الاصطناعي الموجود على الجهاز قوي ولكنه محدود. عندما تريد إضافة "مساعد محادثة ذكي" حقيقي، أو تلخيص نص طويل، أو إنتاج إبداعي معقد إلى أحد التطبيقات، فإنك تحتاج إلى نماذج كبيرة جدًا بحيث لا يمكن وضعها على الهاتف. هذا هو المكان الذي يلعب فيه الذكاء الاصطناعي السحابي: يتصل تطبيقك بنموذج لغة كبير (LLM) عبر واجهة برمجة التطبيقات (واجهة برمجة التطبيقات - الواجهة القياسية حيث يقوم برنامجان بإرسال واستقبال البيانات لبعضهما البعض). في هذه الوحدة سوف نتعلم كيفية دمج Cloud LLM في تطبيق الهاتف المحمول بطريقة آمنة وسريعة واقتصادية. سيكون التركيز الحاسم على الأمان: قد يؤدي تكامل LLM المثبت بشكل غير صحيح إلى تسرب مفتاح API الخاص بك ويؤدي إلى فواتير تبلغ قيمتها آلاف الجنيهات.
القاعدة الذهبية للهندسة المعمارية: احتفظ بالمفتاح للعميل
إن أخطر خطأ يمكن ارتكابه في تكامل الذكاء الاصطناعي السحابي هو تضمين مفتاح API (كلمة المرور السرية التي تسمح باستخدام الخدمة) مباشرةً في رمز تطبيق الهاتف المحمول. يتم تنزيل تطبيقات الهاتف المحمول على جهاز المستخدم ويمكن قراءة التعليمات البرمجية عن طريق الهندسة العكسية - تحليل التطبيق المجمع ورؤية ما بداخله. إذا كان مفتاحك موجودًا داخل التطبيق، فيمكن لأي شخص استخراجه وتقديم طلبات غير محدودة من حسابك.
البنية الصحيحة هي كما يلي: يرسل تطبيق الهاتف المحمول الطلبات إلى خادم الواجهة الخلفية الخاص بك (الخادم الوكيل الذي تتحكم فيه)؛ المفتاح موجود فقط على الخادم؛ ينتقل الخادم إلى خدمة LLM ويعيد الاستجابة إلى التطبيق. توفر هذه البرامج الوسيطة أيضًا تحديد السرعة ومنع إساءة الاستخدام والتحكم في التكلفة.
النهج
أين هو المفتاح
الأمن
المفتاح موجود في التطبيق (خطأ)
في العميل، الجمهور
يتسرب، وينفجر مشروع القانون
المفتاح موجود في الخلفية (صحيح)
على الخادم، مخفية
آمنة ويمكن السيطرة عليها
تنبيه: عندما تطلب من الذكاء الاصطناعي تكامل Cloud LLM، فقد ينتج عنه مثالًا يكتب المفتاح مباشرةً في رمز التطبيق لراحتك. لا تأخذ هذا على الهواء مباشرة. تأكد من تضمين الجملة "يجب ألا يكون مفتاح API موجودًا على العميل، يجب المرور عبر وكيل الواجهة الخلفية" في الموجه.
الجري: زيادة السرعة المدركة
يمكن أن تكون إجابات LLM طويلة وتستغرق ثوانٍ لإنتاجها بالكامل. يعد ترك المستخدم منتظرًا على شاشة فارغة تجربة سيئة. الحل هو التدفق - عرض الإجابة كلمة بكلمة، كما يتم إنشاؤها. يقوم المستخدم بمراقبة تهجئة النص، كما هو الحال في ChatGPT؛ وهذا يزيد بشكل كبير من السرعة والطلاقة المدركة. التدفق على الهاتف المحمول يعني إضافة أجزاء (الرموز المميزة - قطعة النص التي ينتجها النموذج) من الخادم إلى الواجهة عند وصولها. اطلب التدفق بشكل صريح عند طباعة التكامل مع الذكاء الاصطناعي.
نصيحة: أضف زر "إيقاف مؤقت" في استجابة البث. يجب أن يكون المستخدم قادرًا على إيقاف الإنتاج عندما يحصل على الإجابة التي يريدها؛ يعمل هذا على تحسين التجربة وتقليل التكلفة عن طريق تقليل توليد الرموز غير الضرورية. في منتصف الإجابة الطويلة، ربما يكون المستخدم قد وجد إجابته بالفعل.
التكلفة والتأخير وإدارة الأخطاء
تحمل 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 الخاص بها للخروج بسرعة. بعد ثلاثة أسابيع من إصدار التطبيق، تمت إجراء هندسة عكسية للمفتاح وتم استخدام ما قيمته 2400 دولار بين عشية وضحاها. كان على الفريق إلغاء المفتاح وإعداد وكيل خلفي. الدرس المستفاد: أصبح الاختصار الذي تم اتخاذه من أجل الراحة هو الطريق الأكثر تكلفة.
الحالة 2 - انخفض التسرب مع التدفق. أطلق أحد التطبيقات التعليمية لأول مرة ميزة الأسئلة والأجوبة دون البث المباشر؛ كان المستخدمون يخرجون بعد 6 ثوانٍ من الانتظار الخامل. عند إضافة التدفق، بدأت الكلمة الأولى في الظهور خلال 0.8 ثانية، وانخفض معدل التخلي من 48% إلى 12%. نفس الطراز، نفس السرعة - مجرد اختلاف في العرض.
الحالة 3 - التحكم في التكاليف. كان أحد التطبيقات يرسل سجل الدردشة بالكامل إلى العارضة مع كل رسالة مستخدم؛ وفي المحادثات الطويلة، وصل الطلب الواحد إلى 8000 رمز، مما أدى إلى تضخم التكلفة. ومن خلال إرسال الرسائل القليلة الأخيرة والملخص فقط، قام الفريق بتقليل الرموز المميزة لكل طلب بنسبة 70%، مما أدى إلى خفض الفاتورة الشهرية إلى الثلث. الدرس الثالث: قياس ما ترسله.
موجه ضعيف / موجه قوي
مطالبة ضعيفة: "أضف دردشة مثل ChatGPT إلى تطبيقي."
مطالبة قوية: "أضف مساعد دردشة إلى تطبيق iOS/Swift الخاص بي. الهندسة المعمارية: يرسل التطبيق طلبًا إلى الواجهة الخلفية الخاصة بي، ومفتاح LLM API ليس موجودًا على العميل، بل يمر عبر الوكيل. - تأتي الاستجابة متدفقة، ويتم عرضها كلمة بكلمة - زر "إيقاف" يقاطع الإنتاج - التعامل مع المهلة، وأخطاء الشبكة، والمواقف 429 و500 بأمان - تقصير سجل الدردشة: إرسال آخر 6 رسائل + ملخص (التحكم في التكلفة) شرح المخطط المعماري أولاً، ثم قم بإعطاء رمز العميل والوكيل بشكل منفصل."
قوالب قابلة للنسخ
قالب بنية آمن: "تصميم تكامل LLM السحابي في تطبيق [النظام الأساسي] الخاص بي. القاعدة: مفتاح واجهة برمجة التطبيقات فقط في الواجهة الخلفية. العميل -> الوكيل الخاص بي -> LLM. في الوكيل: المصادقة، حد معدل لكل مستخدم، تسجيل الطلب. أدرج مسؤوليات العميل والوكيل بشكل منفصل، ثم قم بتصدير الكود."
قالب البث: "أضف استجابة متدفقة إلى شاشة الدردشة هذه: - أضف مقتطفات إلى فقاعة الرسائل فور وصولها - أظهر المؤشر/الرسوم المتحركة أثناء الكتابة - اجعل الزر "إيقاف" يلغي الدفق - احتفظ بالنص الجزئي وحذر إذا كان هناك خطأ أثناء انتهاء الدفق [الكود الموجود]"
قالب زمن الوصول للتكلفة:"تقليل التكلفة وزمن الوصول في تكامل LLM هذا: - كيف يمكنني تقليل الرمز المميز المرسل (اختصار التاريخ، ملخص)؟ - في هذه الحالة يكون النموذج الأصغر/الأرخص كافيًا؟ - اقترح مهلة وأعد محاولة الإستراتيجية [الكود]"
قالب التسامح مع الخطأ: "اجعل استدعاء LLM هذا مرنًا: - سلوك منفصل لعدم وجود شبكة، مهلة، 429 (حد المعدل)، 500 (الخادم) - رسالة مهذبة غير فنية للمستخدم - ملاحظة التحقق ضد خطر الهلوسة في الردود الحرجة [الكود]"
الأخطاء الشائعة
- تضمين مفتاح API في التطبيق. أغلى وأخطر خطأ أمني؛ المفتاح يكمن بالتأكيد في النهاية الخلفية.
- عدم استخدام التدفق. سيؤدي ترك المستخدم في انتظار الإجابات الطويلة إلى إبعاد المستخدم.
- إرسال سجل الدردشة بالكامل مع كل طلب. إنه يضاعف تكلفة الرمز المميز ووقت الاستجابة.
- تجاوز شروط الخطأ. إذا لم تتم معالجة 429/500/timeout، فسيتعطل التطبيق أو يتجمد.
- اعتبار إجابة LLM صحيحة بدون سؤال. الهلوسة حقيقية. أضف طبقة التحقق في المنطقة الحرجة.
- إرسال بيانات المستخدم إلى LLM غير الضرورية. اسأل ما إذا كانت البيانات الشخصية مطلوبة أو يجب إخفاؤها قبل نقلها إلى السحابة.
في ملخص
توفر Cloud LLM إمكانات رائعة لا تتناسب مع الجهاز المحمول، ولكنها تتطلب الأمان والانضباط في التكلفة. القاعدة الذهبية: مفتاح واجهة برمجة التطبيقات (API) لا يكون موجودًا على العميل أبدًا، بل يمر عبر وكيل الواجهة الخلفية. يزيد التدفق بشكل كبير من السرعة والاحتفاظ؛ بدعم من زر "إيقاف". يتم تحديد التكلفة عن طريق تقصير الرمز المميز المرسل؛ يتم تحقيق المرونة من خلال التعامل مع جميع حالات الخطأ بأمان. قد تتضمن إجابات LLM الهلوسة؛ في المجالات الحيوية، يعد التحقق أمرًا ضروريًا وتتم مراجعة البيانات الشخصية قبل إرسالها إلى السحابة.
مهمة التطبيق
اطلب تصميم عميل + وكيل خلفي من الذكاء الاصطناعي باستخدام "قالب البنية الآمنة" لميزة "تلخيص النص" أو "الدردشة". تأكد من أن مفتاح API موجود فقط في الواجهة الخلفية للتصميم الذي تم إنشاؤه. ثم قم باستخراج طريقتين على الأقل لتقليل الرمز المميز المرسل باستخدام "نمط تأخير التكلفة" واكتب الرسالة المهذبة التي سيتم عرضها للمستخدم لحالة الخطأ (على سبيل المثال، 429).
قائمة مرجعية
- [ ] لقد تحققت من أن مفتاح API موجود في الواجهة الخلفية وليس على العميل
- [ ] لقد قمت ببث الاستجابة وأضفت زر "إيقاف مؤقت".
- [ ] لقد تعاملت مع المهلة وخطأ الشبكة والمواقف 429 و500
- [ ] لقد قمت بتقليل الرمز المميز المقدم بالاختصار/الملخص السابق
- [ ] لقد فكرت في التحقق من صحة خطر الهلوسة في إجابة LLM
- [ ] لقد تحققت من ضرورة/إخفاء البيانات الشخصية قبل الانتقال إلى السحابة