লাভ:
- স্ট্রিমিং কি, ইভেন্টের ধরন এবং কেন এটি প্রয়োজন তা ব্যাখ্যা করতে পারে।
- max_tokens টাইমআউট এবং 128K দীর্ঘ আউটপুট সম্পর্ক বুঝতে পারে
- কাজের চাপ অনুযায়ী স্ট্রিমিং এবং নন-স্ট্রিমিং অনুরোধের মধ্যে সঠিক পছন্দ করতে পারে
আপনি হয়তো লক্ষ্য করেছেন যে একটি চ্যাট ইন্টারফেসে, প্রতিক্রিয়াটি শব্দ দ্বারা শব্দ "টাইপ" হয়। এটি একটি চাক্ষুষ বিকাশ নয়; এটি স্ট্রিমিং নামক একটি কৌশলের ফলাফল এবং প্রায়শই উত্পাদন-মানের LLM ইন্টিগ্রেশনের জন্য বাধ্যতামূলক। এই ইউনিটে, আপনি শিখবেন প্রবাহ কী, এতে কী কী ইভেন্ট রয়েছে, দীর্ঘ আউটপুট এবং সময়সীমার সাথে এর সম্পর্ক এবং কখন প্রবাহ ব্যবহার করতে হবে এবং কখন নয়। আমরা একজন পেশাদার - লাইভ সহকারী, দীর্ঘ প্রতিবেদন তৈরি, ব্যাচ প্রক্রিয়াকরণের বাস্তব কাজের মাধ্যমে বিষয়টি কভার করব।
প্রবাহ কি?
একটি নন-স্ট্রিমিং (সিঙ্ক্রোনাস) অনুরোধের সাথে, মডেলটি সম্পূর্ণ প্রতিক্রিয়া তৈরি না হওয়া পর্যন্ত আপনি অপেক্ষা করুন; উত্তর প্রস্তুত হলে, এটি এক টুকরোতে আসে। একটি স্ট্রিমিং অনুরোধে, সার্ভারটি মডেল তৈরি করার সাথে সাথে টুকরো টুকরো প্রতিক্রিয়া পাঠায়। প্রযুক্তিগতভাবে, এটি সার্ভার-প্রেরিত ইভেন্টগুলির সাথে করা হয় (SSE — সার্ভার-প্রেরিত ইভেন্ট, একটি পদ্ধতি যেখানে সার্ভার একটি খোলা সংযোগের মাধ্যমে পরপর ছোট ঘটনা পাঠায়)।
পার্থক্যটি ব্যবহারকারীর অভিজ্ঞতায় স্পষ্ট হয়ে ওঠে: একটি প্রতিক্রিয়া যা 8 সেকেন্ড সময় নেয়, নন-স্ট্রিম ব্যবহারকারী 8 সেকেন্ডের জন্য একটি ফাঁকা স্ক্রিনের দিকে তাকায়; স্ট্রিমিং ব্যবহারকারী ~0.5 সেকেন্ডের মধ্যে প্রথম শব্দ দেখতে পায় এবং পাঠ্যটি প্রবাহিত হতে শুরু করে। অনুভূত লেটেন্সি—ব্যবহারকারীর বোধ করা অপেক্ষা—প্রচুরভাবে কমে গেছে, যখন মোট সময় অপরিবর্তিত থাকে।
প্রবাহের ইভেন্ট প্রকার
প্রবাহ হল ঘটনার একটি ক্রম। ধারণাগতভাবে, একটি সাধারণ প্রবাহ এই মত যায়:
ঘটনা
অর্থ
বার্তা_শুরু
প্রতিক্রিয়া শুরু হয়; হেডারের তথ্য যেমন মডেল এবং আইডি এসেছে।
content_block_start
বিষয়বস্তুর একটি ব্লক (যেমন পাঠ্য) শুরু হয়েছে৷
content_block_delta
পাঠ্যের একটি ছোট টুকরা (ডেল্টা) এসেছে; তুমি এগুলো সংগ্রহ করো
content_block_stop
ব্লক সম্পন্ন
বার্তা_ডেল্টা
আপডেট করা শেষ তথ্য যেমন stop_reason এবং ব্যবহার
বার্তা_স্টপ
উপর উত্তর
আপনার কোডটি ক্রমানুসারে content_block_delta ইভেন্টগুলিতে পাঠ্যের টুকরোগুলিকে একত্রিত করে; আপনি নন-স্ট্রিমড প্রতিক্রিয়া হিসাবে একই সঠিক পাঠ্যের সাথে শেষ করবেন। ব্যবহার (টোকেন নম্বর) সাধারণত প্রবাহের শেষে পরিষ্কার হয় — প্রবাহ শেষ হয়ে গেলে আপনি খরচের ট্র্যাক রাখেন।
টিপ: বেশিরভাগ অফিসিয়াল SDK (সফ্টওয়্যার ডেভেলপমেন্ট কিট — প্রদানকারীর তৈরি লাইব্রেরি) একটি সাহায্যকারী প্রদান করে যা আপনার জন্য স্ট্রীম সংগ্রহ করে (যেমন stream.get_final_message())। আপনাকে ম্যানুয়ালি সমস্ত ট্র্যাক পরিচালনা করতে হবে না; আপনি যদি সম্পূর্ণ পাঠ্য চান তবে এই সহায়কটি ব্যবহার করুন, পৃথক ইভেন্টগুলি প্রক্রিয়া করুন তবে লাইভ মুদ্রণের জন্য৷
দীর্ঘ প্রতিক্রিয়া, সর্বোচ্চ_টোকেন এবং টাইমআউট
স্ট্রিমিংয়ের দ্বিতীয় এবং আরও প্রযুক্তিগত কারণ হল টাইমআউট। যদি একটি HTTP অনুরোধ একটি নির্দিষ্ট সময়ের মধ্যে সম্পূর্ণ না হয়, ক্লায়েন্ট সংযোগ ড্রপ করে। আপনি যখন মডেল থেকে একটি বড় আউটপুট অনুরোধ করেন (যেমন 40,000 টোকেনের একটি প্রতিবেদন), নন-ফ্লো কল এই সীমা অতিক্রম করতে পারে এবং সময় শেষ হতে পারে — অনুরোধটি ব্যর্থ হবে, এবং আপনাকে জেনারেট করা টোকেনের জন্য অর্থ প্রদান করতে হবে।
আধুনিক মডেলগুলি একক অনুরোধে 128,000 টোকেন পর্যন্ত আউটপুট করতে পারে। কিন্তু থাম্বের নিয়মটি পরিষ্কার: যদি `max_tokens` মান বেশি হয় (প্রায় 16,000-এর উপরে) তাহলে স্ট্রিম ব্যবহার করুন। স্ট্রিমিং সংযোগকে জীবিত রাখে এবং সময়সীমা রোধ করে; আপনি সাথে সাথে অগ্রগতিও দেখতে পাবেন।
- `max_tokens`: সর্বোচ্চ আউটপুট টোকেন মডেল তৈরি করতে পারে; একটি শক্ত সিলিং। যদি একটি বাধা ঘটে, তাহলে stop_reason max_tokens ফেরত দেওয়া হয়।
- প্রসঙ্গ উইন্ডো: যে উইন্ডোতে ইনপুট + আউটপুটের যোগফল অবশ্যই ফিট হবে। max_tokens হল আউটপুটের সিলিং; দুটোকে মেশাবেন না।
সতর্কতা: বড় ম্যাক্স_টোকেন সহ নন-ফ্লো অনুরোধগুলি ছুঁড়ে দেওয়া উত্পাদনে একটি ক্লাসিক ভুল। একটি প্রতিক্রিয়া ছাড়া, সংযোগ ড্রপ, ব্যবহারকারী একটি ত্রুটি দেখেন, এবং টোকেন খরচ নষ্ট হয়. দীর্ঘ আউটপুট = প্রবাহ।
কখন প্রবাহিত হবে এবং কখন নয়?
স্ট্যাটাস
পছন্দ
কেন
লাইভ চ্যাট / সহকারী
প্রবাহ
অনুভূত লেটেন্সি ড্রপ, ব্যবহারকারী অগ্রগতি দেখে
দীর্ঘ প্রতিবেদন / নথি উত্পাদন
প্রবাহ
সময়সীমা রোধ করে, নিরাপদে বড় আউটপুট বহন করে
সংক্ষিপ্ত শ্রেণীবিভাগ (যেমন একক শব্দ ট্যাগ)
কোন প্রবাহ
আউটপুট ইতিমধ্যে ছোট; অতিরিক্ত জটিলতা অপ্রয়োজনীয়
ব্যাচ প্রক্রিয়াকরণ
প্রবাহহীন/ব্যাচ
ফলাফল অবিলম্বে দেখানো হয় না; ইউনিট 7 দেখুন
অটোমেশন ধাপ (পটভূমিতে)
সাধারণত কোন প্রবাহ
আপনি ফলাফলটি পরবর্তী ধাপে পাস করবেন, কোন লাইভ ডিসপ্লে নেই
অনুলিপিযোগ্য প্রম্পট/টেমপ্লেট
স্ট্রীম নিজেই একটি প্রম্পট নয়, তবে প্রম্পটগুলি স্ট্রিম দ্বারা উত্পাদিত আউটপুট পরিচালনার জন্য গুরুত্বপূর্ণ। দীর্ঘ এবং প্রবাহিত প্রযোজনায়, সামনে থেকে কাঠামো আরোপ করা গুণমান এবং ট্রেসেবিলিটি উভয়ই বৃদ্ধি করে।
# দীর্ঘ প্রতিবেদনটিকে ভাগে ভাগ করুন (যাতে প্রবাহে অগ্রগতি দৃশ্যমান হয়) এই সঠিক ক্রমে নিম্নলিখিত শিরোনাম সহ প্রতিবেদনটি লিখুন। প্রতিটি শিরোনাম '##' দিয়ে শুরু করুন:## সারাংশ## ফলাফল## প্রস্তাবনা## পরবর্তী পদক্ষেপ
# দীর্ঘ উৎপাদনে কাটা এড়াতে লক্ষ্য দৈর্ঘ্য দিন। মোট পাঠ্য হবে প্রায় 800 শব্দ। অংশ ভারসাম্য রাখা; শেষে অর্ধেক বাক্য রেখে যাবেন না।
# স্ট্রিমিং সহকারীর জন্য অবিলম্বে প্রথম বাক্যটি দিন। প্রথমে একটি সরাসরি এক-বাক্য উত্তর দিন, তারপর বিস্তারিত যান। তাই ব্যবহারকারী অপেক্ষা করার সময় একটি তাৎক্ষণিক ফলাফল দেখতে পান।
# দীর্ঘ আউটপুট কাঠামোবদ্ধ রাখুন (যাতে এটি পরে পার্স করা যেতে পারে) এই বিভাগে আউটপুট আউটপুট করুন এবং প্রতিটি বিভাগকে একটি পৃথক '###' শিরোনাম দিয়ে চিহ্নিত করুন যাতে আমি এটি প্রোগ্রাম্যাটিকভাবে পার্স করতে পারি: ### ভূমিকা ### BODY ### উত্স
দুর্বল প্রম্পট / শক্তিশালী প্রম্পট (দীর্ঘ উত্পাদন)
# WEAK এই বিষয়ে একটি দীর্ঘ এবং বিস্তারিত প্রতিবেদন লিখুন।
# STRONGএই বিষয়ে প্রায় 900 শব্দের একটি প্রতিবেদন লিখুন। শিরোনাম: ## সারাংশ, ## বিশ্লেষণ, ## ঝুঁকি, ## সুপারিশ। প্রতিটি শিরোনাম সর্বাধিক 3টি অনুচ্ছেদ হওয়া উচিত। শেষে অর্ধেক বাক্য রেখে যাবেন না।
শক্তিশালী সংস্করণ; এটি দৈর্ঘ্য, গঠন এবং ফিনিস গুণমান অগ্রিম নির্ধারণ করে। যেহেতু বিভাগগুলি প্রবাহে আসে, ব্যবহারকারী স্পষ্টভাবে অগ্রগতি দেখেন এবং মডেল বাধার ঝুঁকির বিরুদ্ধে দৈর্ঘ্য নিজেই পরিচালনা করেন।
তিনটি মিনি কেস
কেস 1 - ফাঁকা পর্দার অভিযোগ। একটি পরামর্শকারী দলের ক্লায়েন্ট সহকারী প্রবাহ ছাড়াই সাড়া দিচ্ছিলেন; গড় প্রতিক্রিয়া 7 সেকেন্ড সময় নেয়, ব্যবহারকারীরা জিজ্ঞাসা করেন "এটি কি জমে যায়?" তিনি অভিযোগ করেছেন। একবার আমি প্রবাহে প্রবেশ করলে, প্রথম শব্দটি ~0.6 সেকেন্ডে এসেছিল; মোট সময় একই ছিল, কিন্তু "ধীর" অভিযোগ প্রায় অদৃশ্য হয়ে গেছে।
কেস 2 - পুরানো রিপোর্ট। একটি ফিনান্স টিম একটি 30-পৃষ্ঠার ত্রৈমাসিক প্রতিবেদন তৈরি করছিল; max_tokens: 30000 এর সাথে, নো-ফ্লো অনুরোধটি 60-সেকেন্ডের ক্লায়েন্ট টাইমআউটে আটকে যাবে, অনুরোধটি ব্যর্থ হবে — এবং তৈরি করা টোকেনগুলি চালানে লেখা হবে। তারা স্রোতের সাথে চলে গেল; সংযোগটি লাইভ ছিল, প্রতিবেদনটি সম্পূর্ণরূপে বিতরণ করা হয়েছিল, এবং নষ্ট খরচগুলি বাদ দেওয়া হয়েছিল।
কেস 3 - অপ্রয়োজনীয় প্রবাহ। একটি অপারেশন দল আগত ইমেলগুলিকে "জরুরি/নিয়মিত" হিসাবে লেবেল করছিল; আউটপুট একটি শব্দ ছিল, কিন্তু তারা অভ্যাসগতভাবে প্রবাহ ব্যবহার করে. প্রবাহটি এক-শব্দের প্রতিক্রিয়াতে কোনও সুবিধা দেয়নি, কোডটিকে অপ্রয়োজনীয়ভাবে জটিল করে তোলে। যখন আমি ফ্লোলেস এ স্যুইচ করি, কোডটি সরলীকৃত হয় এবং আচরণ একই থাকে। পাঠ: স্ট্রিমিং দীর্ঘ/লাইভ আউটপুটে মূল্যবান, সর্বত্র নয়।
সাধারণ ভুল
- দীর্ঘ আউটপুটে স্ট্রীম ব্যবহার না করা: টাইমআউট এবং নষ্ট টোকেন খরচ।
- সংক্ষিপ্ত আউটপুটে স্ট্রিমিং ব্যবহার করা: অপ্রয়োজনীয় জটিলতা, শূন্য সুবিধা।
- স্ট্রিমের শেষে `স্টপ_রিজন` চেক করা হচ্ছে না: max_tokens সহ ছেঁটে দেওয়া প্রতিক্রিয়া সম্পূর্ণ বলে বিবেচিত হয়।
- ভুলভাবে ডেল্টা একত্রিত করা: SDK সাহায্যকারীর সাথে ম্যানুয়াল সমষ্টি ক্রম/অনুপস্থিত অংশ ত্রুটি তৈরি করে।
- `ব্যবহার` মধ্য-প্রবাহ পড়ার চেষ্টা করা হচ্ছে: টোকেন সংখ্যা সাধারণত শেষে পরিষ্কার হয়ে যায়; শেষে খরচ ট্র্যাক রাখুন.
- খরচ কমানোর জন্য ভুল স্ট্রিমিং: স্ট্রিমিং অভিজ্ঞতা এবং সহনশীলতা উন্নত করে; এটি টোকেন মূল্য পরিবর্তন করে না।
গভীরতর: প্রবাহ বিরতি এবং স্থিতিস্থাপকতা
স্ট্রিমিং একটি লাইভ সংযোগ; এটি তার শক্তি এবং দুর্বলতা উভয়ই। যদি সংযোগটি মাঝখানে চলে যায় (নেটওয়ার্কের ওঠানামা, ক্লায়েন্ট টাইমআউট), আপনি এখন পর্যন্ত যে পাঠ্য জমা করেছেন তা ধরে রাখবেন, তবে প্রতিক্রিয়াটি অসম্পূর্ণ থাকবে। এটির জন্য একটি উত্পাদন-মানের স্ট্রিমিং ক্লায়েন্ট প্রস্তুত করা উচিত: এটি আংশিক পাঠকে "সম্পূর্ণ প্রতিক্রিয়া" হিসাবে বিবেচনা করা উচিত নয়, বা এটি মেসেজ_স্টপ ইভেন্ট না দেখা পর্যন্ত প্রতিক্রিয়াটিকে সমাপ্ত বলে বিবেচনা করা উচিত নয়।
দ্বিতীয় সূক্ষ্মতা হল যে প্রবাহ খরচ পরিবর্তন করে না। আপনি স্ট্রিমিং সহ বা ছাড়া একটি প্রতিক্রিয়া পান কিনা তা টোকেন মূল্যকে প্রভাবিত করে না; প্রবাহ শুধুমাত্র অভিজ্ঞতা এবং সহনশীলতা উন্নত. তাই "যদি আমরা স্ট্রিমিং করতে যাই, তারা কি সস্তা হবে?" প্রশ্নের উত্তর হল না — খরচের জন্য, ৫ম এবং ৬ষ্ঠ ইউনিট (মডেল নির্বাচন, ক্যাশে) দেখুন।
তৃতীয় পয়েন্টটি হল একটি ব্যবহারিক ভারসাম্য বজায় রাখা: লাইভ সহকারীর সাথে, প্রথম শব্দের দ্রুত আগমন (অনুভূত বিলম্ব) অত্যন্ত মূল্যবান; অতএব, মডেলকে সরাসরি উত্তর লিখতে এবং প্রথমে একটি সংক্ষিপ্ত ফলাফল দিতে বলা (4র্থ ইউনিটে সিস্টেম প্রম্পটের মাধ্যমে) প্রবাহের সুবিধাকে বহুগুণ করে। ব্যবহারকারী যদি প্রথম সেকেন্ডে অর্থপূর্ণ কিছু দেখেন, তাহলে তারা ধৈর্য ধরে পরবর্তী বিবরণের জন্য অপেক্ষা করে। অন্যদিকে, ব্যাকগ্রাউন্ডে চলা কাজের ক্ষেত্রে প্রবাহের কোনো অবদান নেই, যার আউটপুট পরবর্তী অটোমেশন ধাপে যায়; একমাত্র মানদণ্ড হল কাজটি সঠিকভাবে এবং সম্পূর্ণরূপে সম্পন্ন হয়েছে।
সংক্ষেপে
স্ট্রিমিং টুকরো টুকরো প্রতিক্রিয়া পুনরুদ্ধার করে, অনুভূত বিলম্বিতা হ্রাস করে এবং বড় থ্রুপুটগুলিতে টাইমআউট প্রতিরোধ করে। লাইভ সহকারী এবং দীর্ঘ নথি উত্পাদন জন্য প্রায় বাধ্যতামূলক; সংক্ষিপ্ত/ব্যাকগ্রাউন্ড কাজের জন্য এটি অপ্রয়োজনীয়। দীর্ঘ প্রযোজনার ক্ষেত্রে, প্রম্পট সহ সামনে থেকে কাঠামো এবং দৈর্ঘ্য আরোপ করা গুণমান এবং সন্ধানযোগ্যতা উভয়ই বৃদ্ধি করে; প্রবাহ শেষ হলে, stop_reason এবং ব্যবহার নিশ্চিতভাবে চেক করা হয়।
আবেদন টাস্ক
দুটি পরিস্থিতি বেছে নিন: একটি লাইভ/দীর্ঘ (যেমন গ্রাহকের কাছে রিপোর্ট), একটি ছোট/পটভূমি (যেমন ট্যাগিং)। (1) আপনি প্রতিটির জন্য প্রবাহ ব্যবহার করবেন কিনা তা স্থির করুন এবং ন্যায়সঙ্গত করুন। (2) একটি প্রম্পট লিখুন যা দীর্ঘ স্ক্রিপ্টের জন্য কাঠামো আরোপ করে (শিরোনাম + লক্ষ্য দৈর্ঘ্য)। (3) max_tokens মান নির্ধারণ করুন। (4) প্রবাহের শেষে স্টপ_রিজন এবং ব্যবহার সহ আপনি কী পরীক্ষাগুলি সম্পাদন করবেন তা তালিকাভুক্ত করুন।
চেকলিস্ট
- [ ] আমি ব্যাখ্যা করতে পারি স্ট্রিমিং কি এবং কিভাবে এটি অনুভূত বিলম্ব কমায়৷
- [ ] আমি স্ট্রীম এবং ডেল্টা যোগদানের মৌলিক ইভেন্টের ধরন বুঝতে পেরেছি।
- [ ] আমি বড় ম্যাক্স_টোকেন এবং টাইমআউট সম্পর্কের সাথে স্ট্রিম করার প্রয়োজনীয়তা সম্পর্কে জানি।
- কোন কাজের চাপে আমি স্ট্রিমিং ব্যবহার করব এবং কোনটিতে করব না তা আমি সিদ্ধান্ত নিতে পারি।
- [ ] আমি প্রবাহের শেষে stop_reason এবং ব্যবহার পরীক্ষা করতে পারি।