ملخص
- تتطلب الاستجابات التدفقية تحليل SSE قوي للتعامل مع الأجزاء غير المكتملة وبيانات استخدام الرمز النهائية.
- غالباً ما تنبع إخفاقات وضع JSON من توليد النموذج لنصوص لاحقة خارج مخطط JSON الصارم.
- تُقسم نافذة السياق المكونة من 100 ألف رمز بين الطلب والإكمال، لذا فإن المخرجات الطويلة تقلل من مساحة الإدخال المتاحة.
- يجب أن تأخذ تقدير التكلفة في الاعتبار السعر الأعلى لتوكنات الإخراج مقارنة بتوكنات الإدخال.
لماذا يستجيب التدفق الخاص بك بالتعليق
تعلق استجابة التدفق عندما يفشل العميل في قراءة قطعة الحدث الأخير المرسلة من الخادم (SSE) التي تحتوي على بيانات استخدام الرمز. تقوم واجهة برمجة التطبيقات لدينا بتدفق الرموز بمجرد إنشائها، ولكن لا يتم إغلاق الاتصال بالكامل إلا بعد وصول القطعة الأخيرة. إذا قطع رمز العميل الاتصال مبكرًا أو تجاهل القطعة الأخيرة، فإنك تفقد عدادات الرمز الدقيقة اللازمة للتحقق من الفواتير.
اقرأ كل قطعة حتى ينتهي البث. لا تفترض أن القطعة الأخيرة تحتوي فقط على الرمز النهائي. تتضمن القطعة الأخيرة في بث SSE الخاص بنا usage الحقل الذي يحتوي على إجماليات رموز الإدخال والإخراج. إذا تجاهلت هذا البيانات، فلن تتمكن من تتبع استهلاك رصيدك المدفوع مسبقًا بدقة.
عقبات شائعة
- تجاهل حدث SSE النهائي.
- مهلات الوقت المحددة منخفضة جدًا للتكميلات الطويلة.
- لا يتعامل مع JSON غير المكتمل في وضع التدفق.
استهلك دائمًا التدفق بالكامل للتأكد من معرفة الخادم بأن العميل تلقى الاستجابة الكاملة. يمنع هذا تسرب الموارد من جانبنا ويضمن حصولك على البيانات اللازمة لسجلاتك الخاصة.
معالجة أخطاء وضع JSON في الإنتاج
تحدث أخطاء وضع JSON لأن النموذج قد يولد نصاً بعد القوس المتعرج المغلق، مما ينتهك قواعد تحليل JSON الصارمة. عندما تضبط response_format إلى {"type": "json_object", تحاول النموذج إخراج JSON صالح، لكنها غالبًا ما تضيف حشوًا محادثيًا مثل 'إليك البيانات:' بعد القوس المغلق. ثم يتعطل المفسر الخاص بك بسبب النص الإضافي.
قم بإزالة النص الزائد بعد آخر قوس متعرج مغلق صالح. لا تعتمد على النموذج للتوقف بالضبط في نهاية بنية JSON. يجب عليك تنفيذ خطوة معالجة لاحقة للعثور على آخر '}' أو ']' والتخلص من كل شيء بعده. هذا أمر بالغ الأهمية عند تحليل المصفوفات أو الكائنات المتداخلة.
أفضل الممارسات
- استخدم تعبيراً منتظماً لاستخراج كتلة JSON الأخيرة الصالحة.
- التحقق من السلسلة المستخرجة باستخدام محلل JSON.
- أعد المحاولة بدرجة حرارة أقل إذا كان المخرج فوضويًا.
تضمن هذه النهج بقاء خط أنابيب الإنتاج مستقراً حتى عندما يقرر النموذج أن يكون طويلاً. النماذج غير المُفلترة أقل تقييداً، لذا قد تبدو أكثر 'إبداعاً' في تنسيقها.
فهم حدود نافذة السياق
حد نافذة السياق هو 100,000 رمز للمطالبة والإكمال معًا. هذا يعني أنه إذا كانت مدخلاتك 50,000 رمز، فيمكنك توليد ما يصل إلى 50,000 رمز فقط قبل الوصول إلى الحد. الحد ليس للمدخلات فقط؛ إنه ميزانية مشتركة للطلب بأكمله.
احسب مساحة الإخراج المتاحة لديك عن طريق طرح عدد رموز الإدخال من 100,000. إذا أرسلت مطالمة نظام كبيرة أو تاريخ طويل من الرسائل، فإن مساحة الإخراج المتاحة تتقلص وفقاً لذلك. يعد هذا أمراً حاسماً للتطبيقات التي تحافظ على سجلات محادثات طويلة.
مثال على الحساب
- النافذة الإجمالية: 100,000 رمز.
- رموز الإدخال: 20,000 رمز مميز.
- الحد الأقصى للإخراج: 80,000 رمز مميز.
إذا تجاوزت هذا الحد، يعيد الواجهة البرمجية (API) خطأ. راقب استخدام الرموز عن كثب لتجنب الاقتطاع غير المتوقع لاستجابة النموذج. لا يقوم النموذج بالاقتطاع تلقائيًا؛ فهو ببساطة يرفض الطلب إذا تجاوز المجموع النافذة.
عد الرموز وتقدير التكلفة
يجب أن تأخذ تقدير التكلفة في الاعتبار فرق السعر بين توكنات الإدخال وتوكنات الإخراج. تكلف توكنات الإدخال 0.15 دولار لكل 1M توكن، بينما تكلف توكنات الإخراج 0.50 دولار لكل 1M توكن. توكنات الإخراج أغلى بكثير، لذا فإن توليد استجابات طويلة سيرفع تكاليفك بشكل أسرع من إرسال نصوص إدخال طويلة.
قدر تكاليفك عن طريق ضرب عدد الرموز المتوقعة في السعر المقابل. على سبيل المثال، 10,000 رمز إدخال و5,000 رمز إخراج ستكلف: (10,000/1,000,000 * $0.15) + (5,000/1,000,000 * $0.50). هذا يساوي $0.0015 + $0.0025 = $0.004 لكل طلب.
جدول التسعير
| نوع الرمز | السعر لكل مليون رمز |
|---|---|
| الإدخال | $0.15 |
| المخرجات | $0.50 |
تتبع استخدامك عبر قطعة SSE النهائية أو استجابة واجهة برمجة التطبيقات. يضمن ذلك قدرتك على ميزانية دقيقة للتطبيقات عالية الحجم. الرصيد المدفوع مسبقًا لا ينتهي صلاحيته، لذا يمكنك تخطيط إنفاقك بمرور الوقت دون رسوم شهرية.
حد معدل الطلبات: شرح 300 طلب/دقيقة
يحد تحديد معدل الطلبات من طلباتك بـ 300 طلب في الدقيقة لكل مفتاح API. ينطبق هذا الحد على جميع الطلبات، بغض النظر عن حجم الحمولة أو عدد الرموز. إذا تجاوزت هذا الحد، سيعيد الواجهة البرمجية خطأ 429. يجب عليك تنفيذ استراتيجية التراجع الأسي للتعامل مع هذه الأخطاء بسلاسة.
راقب معدل طلباتك وعدّل التزامن وفقًا لذلك. إذا كنت تستخدم عدة خيوط أو عمليات، فتأكد من مشاركتها لنفس مفتاح API والبقاء ضمن حد 300 طلب في الدقيقة مجتمعة. سيؤدي تجاوز هذا الحد إلى أخطاء مؤقتة حتى يتم إعادة تعيين المعدل.
معالجة أخطاء 429
- تطبيق التخفيف الأسي.
- سجل الطلبات الفشلة للتحليل.
- قلل من التزامن إذا كانت الحدود متكررة.
تم تصميم واجهة برمجة التطبيقات (API) الخاصة بنا للاستخدام عالي الحجم، لكن حد معدل الطلب يضمن الاستخدام العادل بين جميع العملاء. إذا كنت بحاجة إلى حدود أعلى، يمكنك إنشاء مفتاح API جديد، ولكن لاحظ أن كل حساب محدود بمفتاح نشط واحد فقط في كل مرة.
استكشاف أخطاء فشل استدعاء الوظائف
تحدث فشل استدعاء الوظائف عندما لا يتطابق تعريف أداة النموذج مع المخطط المتوقع أو عندما يفشل النموذج في إخراج JSON صالح لحجج الأداة. تأكد من أن تعريفات أدواتك دقيقة وتشمل جميع المعلمات المطلوبة. تؤدي المخططات الغامضة إلى استدعاءات أدوات غير صحيحة.
التحقق من حجج الأداة قبل تنفيذ الوظيفة. قد يولد النموذج حججاً تفتقر إلى الحقول المطلوبة أو تحتوي على أنواع غير صحيحة. يجب أن يتعامل كود العميل الخاص بك مع هذه الأخطاء عن طريق إعادة المحاولة بطلب أكثر وضوحاً أو ضبط تعريف الأداة.
خطوات التصحيح
- تحقق من صيغة تعريف الأداة.
- تحقق من أنواع القيم وقيم الحجج.
- راجع مخرجات النموذج بحثاً عن الحقول المفقودة.
استدعاء الوظائف ميزة قوية، لكنه يتطلب تصميم مخطط دقيق. قد تكون النماذج غير الخاضعة للرقابة أقل اتساقًا مع تعريفات الأدوات من نظيراتها المفلترة، لذا فإن التحقق الدقيق ضروري.
لماذا لا يكون 'غير المقيد' غير محدود تمامًا
يعني الوصف "غير مُرقّب" أن النموذج لا يرفض المواضيع القانونية أو الخيالية أو المثيرة للجدل الخاصة بالبالغين، لكنه لا يزال لديه حد صارم على المحتوى الجنسي الذي يتضمن قاصرين. هذا هو قيد المحتوى الصارم الوحيد الذي ينطبق دائماً. سيتم رفض الطلبات التي تحتوي على مثل هذا المحتوى، حتى لو كان باقي النص التوجيهي صالحاً تماماً.
قد لا تزال تحدث حالات رفض بسبب أخطاء تقنية أو حدود معدل الاستخدام. النموذج ليس سحرياً؛ لا يزال بإمكانه فشل توليد استجابة إذا كان الإدخال معقداً جداً أو تم تجاوز نافذة السياق. افهم أن 'غير مقيد' يشير إلى سياسة المحتوى، وليس الموثوقية التقنية.
حدود المحتوى
- لا محتوى جنسي يتضمن قاصرين.
- محتوى بالغ قانوني مسموح به.
- قد تؤدي الأخطاء التقنية إلى الرفض.
هذا التمييز مهم للتطبيقات التي تحتاج إلى التعامل مع مجموعة واسعة من المواضيع. معرفة الحد المحدد يساعدك على تصميم منطق التصفية الخاص بك بشكل صحيح.
تصحيح أخطاء 400 مقابل 429
تشير أخطاء 400 إلى مشكلة في الطلب نفسه، مثل JSON غير صالح، أو حقول مطلوبة مفقودة، أو تجاوز حد حجم طلب 8 ميجابايت. تشير أخطاء 429 إلى تجاوزك لحد المعدل البالغ 300 طلب في الدقيقة. يساعد التمييز بين هذه الأخطاء على إصلاح المشكلة الصحيحة بسرعة.
بالنسبة لأخطاء 400، تحقق من حمولة الطلب والمخطط. بالنسبة لأخطاء 429، نفذ استجابة متزايدة وقلل من التزامن. إذا تلقيت خطأ 400 مع رسالة حول حجم جسم الطلب، تأكد من أنك لا ترسل الكثير من البيانات في طلب واحد. حد 8 MB صارم.
رموز الأخطاء
| رمز الخطأ | المعنى |
|---|---|
| 400 | طلب غير صالح |
| 429 | تم تجاوز حد معدل الطلب |
يجعل تسجيل هذه الأخطاء مع سياقها (حملة البيانات، الطابع الزمني) تصحيح الأخطاء أسهل بكثير. استخدم هذه البيانات لتحسين التكامل وتجنب الفشل المتكرر.
الخطوات التالية لتحسين نموذج Heretic LLM
يبدأ التحسين بمراقبة استخدام الرمز ومعدلات الخطأ. استخدم بيانات الرمز من شريحة SSE النهائية لتتبع استهلاكك الفعلي. قارن هذا بتكاليفك المقدرة لضمان الدقة. اضبط استراتيجيات التزامن وحدود المعدل بناءً على أنماط الاستخدام التي رصدها.
فكر في استخدام درجة حرارة أقل لإخراج JSON أكثر اتساقاً أو استدعاء الوظائف. إذا كنت تحتاج إلى استجابات أكثر إبداعاً، فقم بزيادة درجة الحرارة ولكن كن مستعداً لمزيد من أخطاء التحليل. جرب معلمات مختلفة للعثور على التوازن الصحيح لحالة الاستخدام الخاصة بك.
نصائح التحسين
- راقب استهلاك الرمز المميز عن كثب.
- اضبط درجة الحرارة للاتساق مقابل الإبداع.
- قم بتنفيذ معالجة أخطاء قوية.
ابدأ بفترة التجربة المجانية لاختبار تكاملك. هذه طريقة منخفضة المخاطر للتحقق من أن كود العميل الخاص بك يتعامل مع التدفق (streaming)، ووضع JSON، وحدود المعدلات بشكل صحيح قبل الالتزام برصيد مسبق.
