استخدمنا خدمة OpenAI API للتحقق من عناوين اللوجستيات في أوروبا: وفرنا 32% من التكاليف اليدوية، وتجنبنا أيضًا خطأين فادحين.
في الأسبوع الماضي الأسبوع الأسود لنتهى للتو، وجد فريقنا التقني عندما عقد اجتماع إعادة: هذا العام معدل التحقق التلقائي من العنوان أعلى من 41 ٪ من العام الماضي، قبل ثلاثة خصيصا للتعامل مع العناوين غير العادلة بدوام جزئي، هذا العام تحتاج فقط إلى الاحتفاظ واحد يكفي.
لكن لا أحد يريد أن يذكر المشكلة التي حدثت الشهر الماضي مع خطأ الرقم 429 – خلال الساعات الثلاث الأكثر ازدحامًا في اليوم الأول من العروض الترويجية الكبيرة،١٣٪ من طلبات تحليل العناوين يتم رفضها مباشرةً.الخدمة العملاء انهارت تمامًا، وكاد فريق التشغيل أن يأتي ويقلب مكاتبنا.
لأقول الحقيقة لمن لم يسبق لهم التعامل معها: ما هو بالضبط API من OpenAI؟
إنك لا تحتاج إلى تدريب نماذج كبيرة بنفسك؛ يمكنك ببساطة استدعاء واجهات النماذج المدربة مسبقًا من OpenAI مثل GPT-4o و GPT-3.5-turbo، وإرسال طلبات للحصول على النتائج المرجوة. يتم احتساب التكلفة بناءً على عدد الرموز (tokens) المستخدمة في الطلبات. الإصدار الذي يدعم ما يصل إلى 128 كيلوبايت من السياق لكل طلب متاح الآن بشكل كامل.
السبب في اختيارنا في البداية بسيط للغاية: تنسيق العنوان في البلدان الأوروبية فوضوي للغاية ، والرمز البريدي في المملكة المتحدة والتنسيق الألماني مختلف تمامًا ، وهناك أخطاء تهجئة مختلفة للغات ، وقبل تحديث قاعدة القواعد الخاصة بك 8 مرات في نصف السنة أو تسرب ، واستخدام API للتحليل الدلالي ، طالما أعطيت موجهة ، ومعدل الصحيح مباشرة إلى أكثر من 96٪.
الفوائد الثلاثة التي حصلنا عليها بالفعل، وليست وهمية
- لم نحتاج إلى فريق خاص لتطوير الخوارزميات أو تعديل النماذج؛ استغرق الأمر أسبوعًا واحدًا فقط لربط واجهات البرمجة الخلفية الثلاث معًا، وخلال الشهر الأول من التشغيل، تمكنا من توفير 32% من تكاليف العمالة التي كانت تُدفع للموظفين الثلاثة بدوام جزئي.
- الأخطاء الإملائية وعناوين الاختصارات التي لم يتمكن مكتبة القواعد السابقة من التعرف عليها، يمكن تصحيحها تلقائيًا الآن بنسبة تزيد عن 90٪، مما أدى إلى انخفاض معدل رفض الطلبات بنسبة 28٪ عندما يقوم المستخدمون بإدخال عناوين خاطئة أثناء الطلب.
- يدعم النظام إدخال عناوين بلغات مختلطة؛ حيث يمكن للمستخدمين البولنديين إدخال العناوين باللغة البولندية والمستخدمين الإسبان يمكنهم إدخالها باللغة الإسبانية، ولا حاجة إلى إجراء تعديلات محلية منفصلة. يتم معالجة هذه العناوين مباشرةً وتحويلها إلى صيغة قياسية للخدمات اللوجستية عند إرسالها إلى الواجهة.
لا تنظر فقط إلى الجوانب الإيجابية، لقد وقعنا في هاتين المشكلتين وكدنا نفقد حياتنا بسببهما.

الحفرة الأولى هي الحد الافتراضي للتيار النموذج واحد.قبل أن وصلنا فقط GPT-4o-mini، الدقيقة الافتراضية الحد من التيار كافية فقط للاستخدام العادي، والحفز الكبير تضاعف حجم الطلبات في اليوم 3 مرات، مباشرة تشغيل الحد من التيار، 13٪ من الطلبات تقرير 429، وبعد ذلك إضافة مؤقتة المنطق تخفيض، ونقل الطلبات غير الذروة إلى GPT-3.5-turbo لإنقاذ مرة أخرى.
المشكلة الثانية هي سوء تقييم العناوين الحساسة. في إحدى المرات، قام المستخدم بإدخال عنوان يحتوي على كلمات متعلقة بـ“القواعد العسكرية”, وتم حظره مباشرةً من قبل نظام مراجعة المحتوى الخاص بالواجهة البرمجية الخدمية (API). لم نقم بتوفير حل بديل في حالة الفشل، مما أدى إلى تأخير إرسال الطلب لمدة يومين، وقام المستخدم بتقييم سلبي مباشرةً.
من يجب أن يستخدمه؟ من فضلكم، لا تضيعوا المال هباءً.
إذا كنت مثلنا وتعمل في مجالات تتطلب معالجة دلالية متعددة اللغات وكتابة قواعد لا تنتهي أبدًا، مثل التحقق من العناوين، الردود التلقائية على استفسارات المستخدمين، أو إنشاء محتوى بلغات متعددة، ولا يوجد في فريقك فريق متخصص في الخوارزميات، فإن استخدام خدمات OpenAI API سيكون أكثر فعالية من تدريب النماذج بنفسك.
لكن إذا كنت تعمل في مجالات حيث البيانات الأساسية لا يمكن أن تخرج من النطاق المحلي، مثل معالجة البيانات المالية الحساسة، تحليل البيانات الطبية الخاصة، أو في سيناريوهات بسيطة حيث حجم الطلب ثابت والقواعد واضحة، فلا داعي للمشاركة في هذه الحركة؛ فكتابة القواعد بنفسك أو نشر نماذج صغيرة محليًا يمكن أن يكون أقل تكلفة وأكثر أمانًا.
ثلاث نصائح للمبتدئين، جميعها نتيجة للأخطاء التي ارتكبناها في البداية
- لا تقتصر على استخدام نموذج واحد فقط، بل احتفظ بنموذجين على الأقل من مستويات مختلفة للاستخدام في حالات الطوارئ. استخدم النموذج ذو الدقة العالية للطلبات ذات الأولوية العالية، والنموذج الأقل تكلفة للطلبات ذات الأولوية المنخفضة أو خلال أوقات الذروة. بهذه الطريقة، يمكنك توفير ما لا يقل عن 40% من التكاليف، وكذلك تجنب مشاكل مثل تقييد السرعة الناتجة عن استخدام نموذج واحد فقط.
- يجب تطبيق منطق إعادة المحاولة المكثفة والاحتياطي على جميع الطلبات، ويجب إعداد خطط مسبقة لحالات مثل حجب المحتوى، وتقييد السرعة، والتوقف عن العمل بسبب التأخير، ولا يجب الانتظار حتى تتوقف الواجهة عن العمل للبدء في التعامل معها يدويًا.
- لا داعي لاستخدام أعلى مستويات النماذج من البداية، جرب أولاً النموذج الأرخص (GPT-3.5-turbo) لمعرفة النتائج. إذا لم تكن النتائج مرضية، يمكنك استخدام نموذج أكثر تقدمًا. في معظم السيناريوهات البسيطة، النماذج الصغيرة كافية تمامًا.
في النهاية، دعونا نتحدث عن سؤالين شائعين يطرحهم الجميع.
س: هل سيكون هناك تأخير كبير عند الاتصال من منطقة أوروبا؟
نحن نستخدم عقدة فرانكفورت، ومعظم الطلبات تتم في غضون 15 مللي ثانية، وفقط نسبة ضئيلة جدًا قد تزيد فجأة إلى أكثر من 200 مللي ثانية. إضافة ذاكرة تخزين مؤقتة (كاش) يمكن أن تحل هذه المشكلة، ولن يؤثر ذلك على الأعمال على الإطلاق.
س: هل من الممكن أن تكون نتائج التحليل غير صحيحة؟
نعم، نحن الآن نحول النتائج التي تقل درجة ثقتها عن 80% إلى مراجعة يدوية، وبعد إضافة هذه القاعدة، أصبحت معدلات الأخطاء تقريبًا غير ملحوظة.
هل كان هذا مفيدًا؟