الجري والردود الطويلة

المكاسب:

• يمكن أن يشرح ما هو البث وأنواع الأحداث وسبب الحاجة إليه.
• يستوعب max_tokens المهلة وعلاقة الإخراج الطويلة البالغة 128 كيلو بايت
• يمكن الاختيار الصحيح بين طلبات البث وغير التدفق وفقًا لحجم العمل

ربما لاحظت أنه في واجهة الدردشة، يتم "كتابة" الرد كلمة بكلمة. هذا ليس ازدهارًا بصريًا؛ إنها نتيجة لتقنية تسمى التدفق وغالبًا ما تكون إلزامية لتكامل LLM بجودة الإنتاج. في هذه الوحدة، سوف تتعلم ما هو التدفق، وما هي الأحداث التي يتكون منها، وعلاقته بالمخرجات الطويلة والمهلة، ومتى يجب استخدام التدفق ومتى لا يستخدم. سنغطي الموضوع من خلال المهام الحقيقية للمساعد المباشر المحترف، وإنشاء التقارير الطويلة، ومعالجة الدفعات.

ما هو التدفق؟

مع الطلب غير المتدفق (المتزامن)، تنتظر حتى ينتج النموذج الاستجابة بأكملها؛ عندما يكون الجواب جاهزا، فإنه يصل في قطعة واحدة. في طلب التدفق، يرسل الخادم الاستجابة قطعة قطعة أثناء إنشاء النموذج. من الناحية الفنية، يتم ذلك من خلال الأحداث المرسلة من الخادم (SSE — الأحداث المرسلة من الخادم، وهي طريقة يرسل فيها الخادم أحداثًا صغيرة متتالية عبر اتصال مفتوح).

يصبح الفرق واضحًا في تجربة المستخدم: في الاستجابة التي تستغرق 8 ثوانٍ، يحدق المستخدم غير المتدفق في شاشة فارغة لمدة 8 ثوانٍ؛ يرى مستخدم البث الكلمات الأولى في حوالي 0.5 ثانية ويبدأ النص بالتدفق. يتم تقليل زمن الوصول المتصور - الانتظار الذي يشعر به المستخدم - بشكل كبير، بينما يظل الوقت الإجمالي دون تغيير.

أنواع الأحداث من التدفق

التدفق هو سلسلة من الأحداث. من الناحية النظرية، يسير التدفق النموذجي على النحو التالي:

حادثة

معنى

message_start

بدأ الرد؛ وصلت معلومات الرأس مثل الطراز والمعرف.

content_block_start

بدأت كتلة من المحتوى (مثل النص).

content_block_delta

وصلت قطعة صغيرة من النص (دلتا)؛ قمت بجمع هذه

content_block_stop

اكتملت الكتلة

message_delta

تحديث معلومات النهاية مثل stop_reason والاستخدام

message_stop

الرد انتهى

يجمع الكود الخاص بك بشكل تسلسلي أجزاء من النص في أحداث content_block_delta؛ ينتهي بك الأمر بنفس النص الدقيق للرد غير المتدفق. عادة ما يكون الاستخدام (الأرقام المميزة) واضحًا في نهاية التدفق — يمكنك تتبع التكاليف بمجرد انتهاء التدفق.

نصيحة: توفر معظم حزم SDK الرسمية (مجموعة أدوات تطوير البرامج - المكتبة الجاهزة للموفر) مساعدًا يجمع البث لك (على سبيل المثال،stream.get_final_message()). ليس عليك إدارة كافة المسارات يدويًا؛ استخدم هذا المساعد إذا كنت تريد النص الكامل ومعالجة الأحداث الفردية ولكن للطباعة المباشرة.

الاستجابات الطويلة والحد الأقصى للرموز والمهلة

السبب الثاني والأكثر تقنية للبث هو انتهاء المهلة. إذا لم يتم إكمال طلب HTTP خلال فترة زمنية معينة، فسيقوم العميل بقطع الاتصال. عندما تطلب مخرجات كبيرة من النموذج (على سبيل المثال، تقرير بـ 40000 رمز مميز)، قد تتجاوز المكالمة غير المتدفقة هذا الحد وتنقضي المهلة - سيفشل الطلب، وسيتعين عليك الدفع مقابل الرموز المميزة التي تم إنشاؤها.

يمكن للنماذج الحديثة إنتاج ما يصل إلى 128000 رمزًا في طلب واحد. لكن القاعدة الأساسية واضحة: استخدم التدفقات إذا كانت قيمة `max_tokens' مرتفعة (أعلى من 16000 تقريبًا). يحافظ البث على استمرارية الاتصال ويمنع انتهاء المهلات؛ سترى أيضًا التقدم على الفور.

• `max_tokens`: الحد الأقصى لرموز الإخراج التي يمكن للنموذج إنتاجها؛ سقف صعب. في حالة حدوث مقاطعة، يتم إرجاع stop_reason max_tokens.
• نافذة السياق: النافذة التي يجب أن يتناسب فيها مجموع المدخلات + المخرجات. max_tokens هو سقف الإخراج؛ لا تخلط بين الاثنين.

تنبيه: يعد طرح الطلبات غير المتدفقة باستخدام max_tokens الكبيرة خطأً كلاسيكيًا في الإنتاج. وبدون استجابة، ينقطع الاتصال، ويرى المستخدم خطأ، ويتم إهدار تكلفة الرمز المميز. إخراج طويل = تيار.

متى تتدفق ومتى لا؟

الحالة

التفضيل

لماذا

الدردشة الحية / مساعد

تدفق

ينخفض زمن الاستجابة، ويرى المستخدم التقدم

تقرير طويل / إنتاج الوثائق

تدفق

يمنع انتهاء المهلة، ويحمل مخرجات كبيرة بأمان

تصنيف قصير (مثل علامة كلمة واحدة)

لا تدفق

الناتج صغير بالفعل؛ تعقيد إضافي غير ضروري

معالجة الدفعات

تدفق/دفعة

لا تظهر النتائج على الفور. انظر الوحدة 7

خطوة الأتمتة (في الخلفية)

عادة لا يوجد تدفق

يمكنك تمرير النتيجة إلى الخطوة التالية، لا يوجد عرض مباشر

موجه/قوالب قابلة للنسخ

الدفق نفسه ليس مطالبة، ولكن المطالبات ضرورية لإدارة المخرجات التي ينتجها الدفق. في الإنتاجات الطويلة والانسيابية، يؤدي فرض الهيكل من الأمام إلى زيادة الجودة وإمكانية التتبع.

# قسّم التقرير الطويل إلى أقسام (بحيث يكون التقدم مرئيًا في التدفق) اكتب التقرير بالعناوين التالية، بهذا الترتيب الدقيق. ابدأ كل عنوان بـ '##':## الملخص## النتائج## التوصيات## الخطوات التالية

# أعط الطول المستهدف لتجنب الاقتطاع في الإنتاج الطويل. سيكون إجمالي النص حوالي 800 كلمة. حافظ على توازن الأجزاء؛ لا تترك نصف جملة في النهاية.

# أعط الجملة الأولى على الفور لمساعد البث. أعط إجابة مباشرة من جملة واحدة أولاً، ثم انتقل إلى التفاصيل. لذلك يرى المستخدم نتيجة فورية أثناء الانتظار.

# احتفظ بالمخرجات الطويلة منظمة (حتى يمكن تحليلها لاحقًا) قم بإخراج المخرجات في هذه الأقسام ووضع علامة على كل قسم برأس '###' منفصل حتى أتمكن من تحليله برمجيًا: ### مقدمة ### BODY ### SOURCES

موجه ضعيف / موجه قوي (إنتاج طويل)

# ضعيفاكتب تقريرا طويلا ومفصلا حول هذا الموضوع.

# قوياكتب تقريرًا يتكون من 900 كلمة تقريبًا حول هذا الموضوع. العناوين: ## الملخص، ## التحليل، ## المخاطر، ## التوصيات. يجب أن يتكون كل عنوان من 3 فقرات كحد أقصى. لا تترك نصف جملة في النهاية.

نسخة قوية؛ فهو يحدد الطول والهيكل وجودة التشطيب مسبقًا. ومع تدفق الأقسام، يرى المستخدم التقدم بوضوح ويدير الطول بنفسه ضد مخاطر انقطاع النموذج.

ثلاث حالات صغيرة

الحالة 1 - شكوى بشأن الشاشة الفارغة. كان مساعد عميل الفريق الاستشاري يستجيب دون تدفق؛ يستغرق متوسط ​​الاستجابة 7 ثوانٍ، ويسأل المستخدمون "هل يتجمد؟" اشتكى. بمجرد أن بدأت في التدفق، جاءت الكلمة الأولى في حوالي 0.6 ثانية؛ بقي الوقت الإجمالي على حاله، لكن الشكاوى "البطيئة" اختفت تقريبًا.

الحالة 2 - تقرير قديم. كان فريق الشؤون المالية يعد تقريرًا ربع سنويًا مكونًا من 30 صفحة؛ باستخدام max_tokens: 30000، سيتعطل طلب عدم التدفق خلال مهلة العميل لمدة 60 ثانية، وسيفشل الطلب - وستتم كتابة الرموز المميزة التي تم إنشاؤها في الفاتورة. ذهبوا مع التدفق. وظل الاتصال حيًا، وتم تسليم التقرير بالكامل، وتم التخلص من التكاليف المهدرة.

الحالة 3 - التدفق غير الضروري. كان فريق العمليات يصنف رسائل البريد الإلكتروني الواردة على أنها "عاجلة/عادية"؛ كان الناتج عبارة عن كلمة واحدة، لكنهم اعتادوا على استخدام التدفق. لم يقدم التدفق أي فائدة في الاستجابة المكونة من كلمة واحدة، مما يجعل التعليمات البرمجية معقدة بشكل غير ضروري. عندما قمت بالتبديل إلى التدفق غير المتدفق، تم تبسيط الكود وظل السلوك كما هو. الدرس المستفاد: البث ذو قيمة في الإنتاج الطويل/المباشر، وليس في كل مكان.

الأخطاء الشائعة

• عدم استخدام التدفقات في المخرجات الطويلة: المهلة وتكلفة الرمز المميز الضائعة.
• استخدام البث في الإخراج القصير: تعقيد غير ضروري، فائدة صفر.
• عدم التحقق من "stop_reason" في نهاية الدفق: تعتبر الاستجابة المقتطعة باستخدام max_tokens كاملة.
• دمج دلتا بشكل غير صحيح: يؤدي الجمع اليدوي باستخدام مساعد SDK إلى حدوث خطأ في التسلسل/الأجزاء المفقودة.
• محاولة قراءة "الاستخدام" في منتصف البث: عادةً ما تصبح أرقام الرموز المميزة واضحة في النهاية؛ تتبع التكاليف في النهاية.
• الخلط بين البث وخفض التكاليف: يعمل البث على تحسين الخبرة والقدرة على التحمل؛ لا يغير سعر الرمز المميز.

أعمق: فواصل التدفق والمرونة

البث هو اتصال مباشر. وهذا هو مصدر قوته وضعفه. إذا انقطع الاتصال في المنتصف (تقلبات الشبكة، انتهاء مهلة العميل)، فستحتفظ بالنص الذي قمت بتجميعه حتى الآن، لكن الاستجابة ستكون غير مكتملة. يجب أن يكون عميل البث بجودة الإنتاج مستعدًا لهذا: لا يجب أن يتعامل مع النص الجزئي على أنه "استجابة مكتملة"، ولا يجب أن يعتبر الاستجابة منتهية حتى يرى حدث message_stop.

الدقة الثانية هي أن التدفق لا يغير التكلفة. لا يؤثر ما إذا كنت تتلقى ردًا مع البث أو بدونه على سعر الرمز المميز؛ التدفق يحسن الخبرة والتحمل فقط. لذا، "إذا بدأنا البث المباشر، فهل ستكون أرخص؟" الإجابة على السؤال هي لا - بالنسبة للتكلفة، انظر إلى الوحدة الخامسة والسادسة (اختيار النموذج، ذاكرة التخزين المؤقت).

النقطة الثالثة هي تحقيق توازن عملي: مع المساعدين المباشرين، فإن الوصول السريع للكلمة الأولى (التأخير المتصور) يحظى بتقدير كبير؛ ولذلك، فإن مطالبة النموذج بإدخال الإجابة مباشرة وإعطاء نتيجة قصيرة أولاً (عبر موجه النظام في الوحدة الرابعة) يضاعف فائدة التدفق. إذا رأى المستخدم شيئًا ذا معنى في الثانية الأولى، فإنه ينتظر بصبر التفاصيل التالية. من ناحية أخرى، ليس للتدفق أي مساهمة في المهام التي يتم تشغيلها في الخلفية، والتي ينتقل مخرجاتها إلى خطوة الأتمتة التالية؛ المعيار الوحيد هو أن المهمة قد اكتملت بشكل صحيح وكامل.

باختصار

يسترد الدفق الاستجابة قطعة قطعة، مما يقلل من زمن الوصول المتصور ويمنع انتهاء المهلات على معدلات الإنتاجية الكبيرة. إلزامي تقريبًا للمساعد المباشر وإنتاج المستندات الطويلة؛ إنه غير ضروري للعمل القصير/الخلفية. في الإنتاجات الطويلة، يؤدي فرض الهيكل والطول من الأمام بسرعة إلى زيادة الجودة وإمكانية التتبع؛ عند انتهاء التدفق، يتم بالتأكيد التحقق من سبب الإيقاف والاستخدام.

مهمة التطبيق

اختر سيناريوهين: أحدهما مباشر/طويل (على سبيل المثال، تقرير إلى العميل)، والآخر قصير/خلفية (على سبيل المثال، وضع العلامات). (1) قرر وتبرير ما إذا كنت ستستخدم التدفق لكل منها. (2) اكتب موجهًا يفرض بنية النص الطويل (العناوين + طول الهدف). (3) تحديد قيم max_tokens. (4) قم بإدراج عمليات التحقق التي ستجريها باستخدام stop_reason والاستخدام في نهاية التدفق.

قائمة مرجعية

• [ ] يمكنني أن أشرح ما هو البث وكيف أنه يقلل من زمن الوصول المتصور.
• [ ] لقد فهمت أنواع الأحداث الأساسية للانضمام إلى الدفق والدلتا.
• [ ] أعرف الحاجة إلى البث باستخدام max_tokens الكبيرة وعلاقة المهلة.
• [ ] يمكنني أن أقرر في أي عبء عمل سأستخدم البث وفي أي منها لن أستخدمه.
• [ ] يمكنني التحقق من سبب الإيقاف والاستخدام في نهاية الدفق.