تستخدم Discourse AI الآن المخرجات المنظمة للمحتوى، ولكن المخرجات المنظمة لم تدعمها العديد من موفري واجهات برمجة التطبيقات، فمعظم موفري الذكاء الاصطناعي في بلدي مثل DeepSeek أو Qwen لا يفعلون ذلك. يؤدي استخدام المخرجات المنظمة إلى خيارات محدودة جدًا لواجهات برمجة التطبيقات تقتصر على عدد قليل من موفري الذكاء الاصطناعي الرئيسيين.
أعتقد أنه إذا كان على Discourse AI التغلب على القيود الحالية في خيارات الموفرين، فإن التخلي عن المخرجات المنظمة أمر ضروري، ولن ينكسر شيء فعليًا بدونها. كحل، يمكننا استخدام بعض الفواصل الفريدة البسيطة أو مجرد مطالبة الذكاء الاصطناعي بإنشاء JSON من خلال تقديم مخطط JSON أو أمثلة، ولكن عدم استخدام المخرجات المنظمة، فلماذا لا؟
هل يمكنك تجربة Moonshot AI Kimi K2 عبر نقاط نهاية واجهة برمجة التطبيقات الخاصة بهم للصين؟
يبدو أن عنوان URL الأساسي لواجهة برمجة التطبيقات هو https://api.moonshot.cn/v1.
لقد فرضنا متطلبات المخرجات المنظمة لأنني تحملت آلاف الشكاوى حول مشكلات مثل، إضافة النماذج لـ “إليك ملخصك” أو الفشل في التحليل عند الحصول على قائمة بالعناوين المقترحة لمساعد الذكاء الاصطناعي، وما إلى ذلك. الآن مع الترجمة، أصبحت مشكلة أسوأ عندما تضطر إلى الوثوق بملايين استدعاءات نماذج اللغة الكبيرة لعدم إضافة أي شيء إضافي إلى مخرجاتك.
نظرًا للحاجة إلى الموثوقية، والتوافر العام للمخرجات المنظمة، اتخذنا هذا القرار بشأن المزودين حيث يتم دعمه، ولكني سأكون منفتحًا على طلب سحب (PR) يضيف مربع اختيار لتعطيل المخرجات المنظمة من طلب واجهة برمجة التطبيقات لموفر OpenAI.
ثم عدم الاهتمام بأي شيء خارج <START> و <END>، أعتقد أن أغبى نموذج ذكاء اصطناعي إنتاجي يمكنه معالجة التسميات بشكل صحيح.
وطلب من الذكاء الاصطناعي عدم إضافة وصف إضافي؛ ثم تحذير المسؤولين من المشاكل المحتملة إذا فتحوا مربع الاختيار هذا. شكرًا.
أنا لا أعرف كيف يبدو نص طلب Discourse AI. ولكن إذا لم يكن كذلك، فما عليك سوى وضع المطالبات النظامية في الرسالة الأولى التي تقولها دور system، ونتيجة استعلام قاعدة بيانات المتجهات في الرسالة التالية بدور system، ووضع محتوى المنشور أو البيانات الفعلية الأخرى في رسائل دور user.