এন্ড-টু-এন্ড প্রোডাকশন: যাচাইকরণ, পর্যবেক্ষণ এবং নীতিশাস্ত্র

লাভ:

• এন্ড-টু-এন্ড আর্কিটেকচার ডিজাইন করতে পারে যা আইডিয়া থেকে প্রোডাকশন পর্যন্ত একটি এলএলএম বৈশিষ্ট্য নেয়
• যাচাইকরণ প্রয়োগ, মানুষের অনুমোদন এবং ট্র্যাকিং (লগিং/মেট্রিক্স) এর স্তরগুলি স্থাপন করে
• সীমানা নৈতিকতা এবং গোপনীয়তার নীতিগুলিকে উত্পাদন সিদ্ধান্তে অনুবাদ করে

আগের দশটি ইউনিটে, আমরা একে একে অংশগুলি শিখেছি: অনুরোধের কাঠামো, টোকেন অর্থনীতি, প্রবাহ, সিস্টেম প্রম্পট, মডেল নির্বাচন, ক্যাশে, ব্যাচ, ত্রুটি ব্যবস্থাপনা, সুরক্ষিত কী এবং অটোমেশন। এই শেষ ইউনিটে, আমরা অংশগুলিকে একত্রিত করি এবং সামগ্রিক স্থাপত্য স্থাপন করি যা ধারণা থেকে উত্পাদন পর্যন্ত একটি LLM বৈশিষ্ট্য বহন করে। উত্পাদন একটি "ওয়ার্কিং ডেমো" থেকে আলাদা: যাচাইকরণ বাধ্যতামূলক, আউটপুট নিরীক্ষণ করা আবশ্যক, সীমানা এবং নৈতিক নীতিগুলি সিদ্ধান্তগুলিতে এমবেড করা আবশ্যক৷ এই ইউনিটটি মডিউলের ক্যারিয়ার কলাম; আগের সবগুলো এখানে একসাথে আসে।

প্রোডাকশন আর্কিটেকচারের স্তর

একটি কঠিন এলএলএম যোগ্যতা প্রায় পাঁচটি স্তর নিয়ে গঠিত:

1. ইনপুট স্তর: ডেটা সংগ্রহ করুন, এটি পরিষ্কার করুন, সংবেদনশীল অঞ্চলগুলিকে মুখোশ করুন, শুধুমাত্র যা প্রয়োজন তা প্রেরণ করুন।
2. মডেল স্তর: সঠিক মডেল নির্বাচন করুন (ইউনিট 5), সিস্টেম প্রম্পট এবং প্যারামিটার সেট করুন (ইউনিট 4), ক্যাশে (ইউনিট 6)।
3. বৈধতা স্তর: প্রয়োজনে স্কিমা/নিয়ম, উত্স, এবং মানুষের অনুমোদনের বিরুদ্ধে আউটপুট পরীক্ষা করুন।
4. অ্যাকশন লেয়ার: বৈধ আউটপুট সহ অ্যাকশন সম্পাদন করুন; উচ্চ প্রভাব কর্ম ক্যাপচার.
5. মনিটরিং স্তর: প্রতিটি কল, খরচ, ত্রুটি এবং গুণমান রেকর্ড করুন এবং পরিমাপ করুন।

এই স্তরগুলি একটি পাইপলাইন; প্রত্যেকে আগেরটির আউটপুট পরীক্ষা করে।

কেন যাচাইকরণ প্রয়োজন?

এলএলএম সাবলীল কিন্তু কখনও কখনও ভুল আউটপুট উত্পাদন করতে পারে। একে হ্যালুসিনেশন বলা হয়: মডেলটি এমন তথ্য তৈরি করতে পারে যা সত্য বলে মনে হয় কিন্তু তা নয়। চ্যাট গেমে এটি সহনীয়; একটি উৎপাদন ব্যবস্থা (চালান, স্বাস্থ্য, আইনি, অর্থ) সহ্য করা যাবে না। তাই দেখা গেল, অন্ধভাবে অবিশ্বস্ত; নিশ্চিত করা হয়।

যাচাইকরণ স্তর (প্রভাব দ্বারা বৃদ্ধি):

• বিন্যাস/স্কিমা বৈধতা: আউটপুট কি প্রত্যাশিত JSON স্কিমার সাথে সামঞ্জস্যপূর্ণ? (গঠিত আউটপুট মূলত এটির নিশ্চয়তা দেয়।)
• নিয়ম/যুক্তি যাচাই: মানগুলি কি যুক্তিসঙ্গত? (পরিমাণটি কি ঋণাত্মক, ভবিষ্যতের তারিখ কি, বিভাগটি কি বৈধ?)
• উৎস যাচাই: দাবী কি প্রদত্ত ডকুমেন্টেশনের উপর ভিত্তি করে? মডেল কি এমন কিছু বলে যা নথিতে নেই?
• মানুষের অনুমোদন: একজন বিশেষজ্ঞ উচ্চ-প্রভাব বা অস্পষ্ট সিদ্ধান্ত পর্যালোচনা করেন।

সতর্কতা: "মডেলটি খুব ভাল, আর কোন যাচাইয়ের প্রয়োজন নেই" হল সবচেয়ে বিপজ্জনক উত্পাদনের ভুল। মডেল যতই ভালো হোক না কেন, যাচাইকরণ স্তরটি উচ্চ-প্রভাবিত সিদ্ধান্তে একটি নিরাপত্তা জাল। এমনকি একটি ভুল স্বয়ংক্রিয় সিদ্ধান্ত সব সময় বাঁচিয়ে নিতে পারে।

হিউম্যান-ইন-দ্য-লুপ

প্রতিটি সিদ্ধান্ত সম্পূর্ণ স্বয়ংক্রিয় হতে হবে না। হিউম্যান-ইন-দ্য-লুপ পদ্ধতিতে, মডেলটি কাজের গতি বাড়ায় এবং মানুষ এটিকে অনুমোদন করে। সঠিক ভারসাম্য নির্ভর করে সিদ্ধান্তের প্রভাব এবং সেই কাজের উপর মডেলের নির্ভরযোগ্যতার উপর।

সিদ্ধান্তের প্রভাব

এপ্রোচ

কম (লেবেল পরামর্শ, খসড়া)

সম্পূর্ণ অটোমেশন; ত্রুটি সস্তা এবং বিপরীত হয়

মাঝারি (রাউটিং, অগ্রাধিকার)

অটোমেশন + নমুনা নিয়ন্ত্রণ

উচ্চ (অর্থ, চুক্তি, স্বাস্থ্য, মুছে ফেলা)

মানুষের সম্মতি বাধ্যতামূলক; মডেল শুধুমাত্র প্রস্তাব

পর্যবেক্ষণ: আপনি যা দেখতে পাচ্ছেন না তা পরিচালনা করতে পারবেন না

উৎপাদনে, আপনাকে অবশ্যই প্রতিটি কল নিরীক্ষণ করতে হবে। মনিটরিং ব্যতীত, আপনি খরচ, গুণমান উন্নত করতে পারবেন না বা তাড়াতাড়ি সমস্যা ধরতে পারবেন না। রেকর্ড করার জন্য মূল মেট্রিক্স:

• ব্যবহার/খরচ: প্রতি অনুরোধ এবং মোট টোকেন, মডেল বিতরণ, দৈনিক খরচ।
• লেটেন্সি: গড় এবং সবচেয়ে খারাপ ক্ষেত্রে প্রতিক্রিয়া সময়।
• ত্রুটির হার: 429/500 হার, পুনরায় চেষ্টা, পরিত্যাগ।
• গুণমান: যাচাইকরণ স্তরে প্রত্যাখ্যাত আউটপুট হার, মানুষের অনুমোদনে সংশোধন হার, ব্যবহারকারীর প্রতিক্রিয়া।

টিপ: নিরীক্ষণ লগগুলিতে সংবেদনশীল ডেটা (ব্যক্তিগত তথ্য, কী) লিখবেন না। গোপনীয়তার সুযোগের মধ্যে লগগুলি বিবেচনা করুন; প্রয়োজনে মাস্ক করে রেকর্ড করুন (ইউনিট 9)।

নৈতিকতা এবং সীমানা

প্রযুক্তিগত নির্ভুলতার মতো নৈতিক দায়িত্ব উত্পাদন সিদ্ধান্তের একটি অংশ:

• স্বচ্ছতা: ব্যবহারকারীর জানা উচিত যে তারা কৃত্রিম বুদ্ধিমত্তা বা মানুষের সাথে কথা বলছে কিনা।
• ন্যায্যতা এবং পক্ষপাতিত্ব: মডেলটি যে ডেটাতে প্রশিক্ষিত তা থেকে পক্ষপাত বহন করতে পারে; উচ্চ-প্রভাবিত সিদ্ধান্তগুলিতে বৈষম্যমূলক পরিণতিগুলি পর্যবেক্ষণ করুন (নিয়োগ, ক্রেডিট)।
• দায়: একটি স্বয়ংক্রিয় সিদ্ধান্ত ক্ষতির কারণ হলে, আপনি দায়ী; "মডেল তাই বলেছে" একটি প্রতিরক্ষা নয়.
• সীমার স্বীকৃতি: মডেল কিছু কাজ নির্ভরযোগ্যভাবে সম্পাদন করতে পারে না; তাদের স্বয়ংক্রিয় না করাও একটি ডিজাইনের সিদ্ধান্ত।

অনুলিপিযোগ্য টেমপ্লেট

# বৈধকরণ চেকলিস্ট (আউটপুট জেনারেশনের পরে) 1) স্কিমা কি বৈধ? (গঠিত আউটপুট বৈধতা) 2) মানগুলি কি অর্থপূর্ণ? (নিয়ম চেক: পরিসীমা, তারিখ, enum)3) দাবি কি উৎসের উপর ভিত্তি করে? (নথিতে না থাকলে প্রত্যাখ্যান করুন)4) প্রভাব কি বেশি? → মানুষের অনুমোদনের জন্য পাঠান5) সব পাস হলে → অ্যাকশনের অনুমতি দিন, সংরক্ষণ করুন

# সিস্টেম প্রম্পট যা উৎসের উপর নির্ভর করতে বাধ্য করে শুধুমাত্র প্রদত্ত নথিতে তথ্যের উপর নির্ভর করে। নথিতে নেই এমন কিছু যোগ করবেন না। কোনো তথ্য নথিতে না থাকলে লিখুন "নথিতে পাওয়া যায়নি"। কখনও অনুমান বা জিনিস আপ.

# মানব অনুমোদন থ্রেশহোল্ড (সিদ্ধান্তের নিয়ম) যদি [অর্থ, চুক্তি, মুছে ফেলুন, স্বাস্থ্য] সিদ্ধান্ত_টাইপ করুন → মানব অনুমোদন বাধ্যতামূলকআইএফ মডেল_ট্রাস্ট < থ্রেশহোল্ড বা বৈধতা "অনিশ্চিত" → মানব অনুমোদনে জমা দিনOTHER → স্বয়ংক্রিয় প্রয়োগ + নমুনা নিয়ন্ত্রণ

# ট্রেস লগ টেমপ্লেট (সংবেদনশীল ডেটা লেখা) { "সময়":"...", "মডেল":"...", "ইনপুট_টোকেন":..., "আউটপুট_টোকেন":..., "বিলম্ব_এমএস":..., "স্টপ_রিজন":"...", "প্রমাণিকরণ":"পাসিত| প্রত্যাখ্যান| মানুষ" // NE_কাহিনী লিখিত হয়, "ব্যক্তিগত ডেটা" এবং NE_}...

দুর্বল প্রম্পট / শক্তিশালী প্রম্পট (উৎপাদন নির্ভরযোগ্যতা)

# দুর্বল (কোনও যাচাইকরণ নেই, কোনও উত্স নেই, স্বয়ংক্রিয়ভাবে প্রযোজ্য) এই অনুরোধটি মূল্যায়ন করুন, একটি ফেরতের সিদ্ধান্ত নিন এবং আবেদন করুন৷

# স্ট্রং (উৎস-ভিত্তিক, সুপারিশ তৈরি করে, মানুষের অনুমোদনের জন্য ছেড়ে দেয়) শুধুমাত্র ফেরত নীতি নথির উপর ভিত্তি করে এই ফেরত অনুরোধের মূল্যায়ন করুন। যৌক্তিকতার সাথে সিদ্ধান্তের সুপারিশ করুন কিন্তু বাস্তবায়ন করবেন না: {"recommendation":"approve|reject","reason":"...","policy_clause":"..."}।পলিসি ডকুমেন্টে কোনো স্পষ্ট ভিত্তি না থাকলে, "অস্পষ্ট" দিন। একজন প্রতিনিধি চূড়ান্ত সিদ্ধান্ত অনুমোদন করবেন।

শক্তিশালী সংস্করণ; এটি সিদ্ধান্তটিকে উত্সের জন্য দায়ী করে, মডেলটিকে "করানোর" পরিবর্তে "পরামর্শদাতা" হিসাবে অবস্থান করে এবং মানুষের অনুমোদনের পিছনে উচ্চ-প্রভাবিত পদক্ষেপ রাখে। এটি উত্পাদন নির্ভরযোগ্যতার সারাংশ।

তিনটি মিনি কেস

কেস 1 — যেদিন যাচাইকরণ স্তরটি সংরক্ষণ করা হয়েছিল। একটি ফিনটেক মডেল ক্লাসিফাই লেনদেনের বিবরণ এবং স্বয়ংক্রিয় অ্যাকাউন্টিং রেকর্ড তৈরি করত। তারা নিয়মের বৈধতা যোগ করেছে: একবার মডেলটি ভুলভাবে পরিমাণ আউটপুট করে (নথিতে 1,250 এর পরিবর্তে 12,500), "পরিমাণ নথির সাথে মেলে না" নিয়মটি আউটপুট প্রত্যাখ্যান করে এবং রেকর্ডটি মানুষের কাছে পড়ে। যদি কোন যাচাই না হয়, তাহলে ভুল রেকর্ডটি নীরবে সিস্টেমে প্রবেশ করবে।

কেস 2 — পলাতক নজরদারি দ্বারা ধরা. একটি SaaS দল একটি মনিটরিং প্যানেল স্থাপন করেছিল; একদিন সকালে দৈনিক খরচ তিনগুণ বেড়ে গেল। এটি লগ থেকে দেখা গেছে যে একজন ক্লায়েন্ট একটি লুপে প্রবেশ করেছে এবং একই অনুরোধ হাজার হাজার বার পাঠিয়েছে। তারা কোটা এবং অনুলিপি যোগ করেছে; কয়েক ঘণ্টার মধ্যেই সমস্যার সমাধান হয়ে যায়। ট্র্যাকিং ছাড়া, মাসের শেষে বিল একটি চমক হবে.

কেস 3 - সীমা গ্রহণ করা। একটি স্বাস্থ্যসেবা স্টার্টআপ সম্পূর্ণরূপে স্বয়ংক্রিয়ভাবে একটি রোগ নির্ণয়ের সুপারিশ করতে এবং রোগীকে দেখানোর পরিকল্পনা করছিল। একটি নীতিশাস্ত্র এবং দায়বদ্ধতা পর্যালোচনায়, তারা সিদ্ধান্ত নিয়েছে যে এটি অফ-সীমা ছিল: মডেলটি শুধুমাত্র একজন চিকিত্সককে একটি সারাংশ এবং সম্ভাব্য পয়েন্ট প্রদান করে, চিকিত্সক রোগ নির্ণয় করেন। একটি কাজ স্বয়ংক্রিয় না করাও একটি পরিপক্ক ডিজাইনের সিদ্ধান্ত।

সাধারণ ভুল

• বৈধতা এড়িয়ে যাওয়া: অন্ধভাবে আউটপুট প্রয়োগ করা, "মডেলটি ভাল" বলে।
• স্বয়ংক্রিয়ভাবে উচ্চ-প্রভাবিত সিদ্ধান্ত: অর্থ/স্বাস্থ্য/আইনে মানুষের অনুমোদন অপরিহার্য।
• মনিটরিং নয়: খরচ এবং মানের সমস্যা দেরিতে আবিষ্কৃত হয়।
• লগগুলিতে সংবেদনশীল ডেটা লেখা: গোপনীয়তা লঙ্ঘন; এটি মাস্ক করে সংরক্ষণ করুন.
• উত্সের উপর নির্ভর করার চেষ্টা না করা: নথিতে যা নেই তা মডেলটি তৈরি করতে পারে।
• সীমা উপেক্ষা করা: কিছু কাজ স্বয়ংক্রিয় না করা সঠিক সিদ্ধান্ত; স্বচ্ছতা এবং দায়িত্ব আপনার।

গভীরতর: রিলিজ ম্যানেজমেন্ট, রোলব্যাক এবং ইনক্রিমেন্টাল ডিপ্লয়মেন্ট

একটি এলএলএম বৈশিষ্ট্যকে উৎপাদনে নিয়ে যাওয়া মানে এটি সেট আপ করা এবং ভুলে যাওয়া নয়; নিরাপদে সময়ের সাথে একটি লাইভ সিস্টেম পরিবর্তন করা হয়। এর তিনটি স্তম্ভ রয়েছে।

সংস্করণ করা। আপনার সিস্টেম প্রম্পট, মডেল নির্বাচন, এবং যাচাইকরণ নিয়ম সময়ের সাথে পরিবর্তিত হয়। সংস্করণ প্রতিটি উল্লেখযোগ্য পরিবর্তন এবং কোন সংস্করণ লাইভ রেকর্ড. যদি একদিন মান কমে যায়, "আমরা কি পরিবর্তন করেছি?" আপনি কয়েক মিনিটের মধ্যে প্রশ্নের উত্তর দিতে সক্ষম হবেন। একটি সংস্করণহীন সিস্টেমে, রিগ্রেশনের মূল কারণ খুঁজে পেতে দিন লাগে।

রোলব্যাক যদি একটি নতুন প্রম্পট বা মডেল লাইভে প্রত্যাশার চেয়ে খারাপ আচরণ করে, আপনি দ্রুত পূর্ববর্তী, সুপরিচিত সংস্করণে ফিরে যেতে সক্ষম হবেন। রোলব্যাক প্ল্যান ছাড়া একটি পরিবর্তন অন্ধভাবে একটি লাইভ ঝুঁকি গ্রহণ করছে। "আমি কিছু পরিবর্তন করেছি, এটি খারাপ হয়ে গেছে, আমি ফিরে যেতে পারি না" সবচেয়ে ব্যয়বহুল প্রযোজনা দৃশ্য।

ধীরে ধীরে রোলআউট। একবারে সমস্ত ট্র্যাফিকের পরিবর্তন প্রয়োগ করার পরিবর্তে, আপনি প্রথমে এটিকে একটি ছোট শতাংশে (যেমন 5%) রোল আউট করুন এবং মেট্রিক্স (গুণমান, খরচ, ত্রুটি) নিরীক্ষণ করুন। এটা ভাল হলে, আপনি শতাংশ বৃদ্ধি; যদি এটি খারাপ হয়, আপনি শুধুমাত্র একটি ছোট অংশ প্রভাবিত করে এটি ফিরে পাবেন। এটি ঝুঁকিকে সীমাবদ্ধ করে।

এই তিনটি অনুশীলন পূর্ববর্তী সমস্ত ইউনিটের কৌশলগুলিকে একত্রিত করে: ইভাল (ইউনিট 5) অগ্রিম পরিবর্তনের ব্যবস্থা করে, পর্যবেক্ষণ (এই ইউনিট) প্রচারের সময় প্রাথমিক সতর্কতা দেয়, যাচাইকরণ স্তরটি কার্যকর হওয়ার আগে ভুল আউটপুটগুলিকে ধরে। উৎপাদন একটি একক সঠিক সেটআপ নয়; এটি একটি অবিচ্ছিন্ন শৃঙ্খলা যা পরিমাপ করে, নিরীক্ষণ করে এবং আত্মবিশ্বাসের সাথে পরিবর্তন করতে পারে। এই শৃঙ্খলা প্রতিষ্ঠা করার জন্য সম্পূর্ণ মডিউলটি আপনার জন্য।

সংক্ষেপে

উত্পাদন একটি কাজের ডেমোর চেয়ে বেশি: এটি ইনপুট, মডেল, যাচাইকরণ, অ্যাকশন এবং পর্যবেক্ষণ স্তরগুলির একটি পাইপলাইন। আউটপুট যাচাই ছাড়া অবিশ্বস্ত হয়; উচ্চ-প্রভাবিত সিদ্ধান্তগুলি মানুষের অনুমোদনের সাথে জড়িত; প্রতিটি কল খরচ, ত্রুটি এবং মানের জন্য নিরীক্ষণ করা হয়. নৈতিকতা, স্বচ্ছতা, পক্ষপাতিত্ব নিয়ন্ত্রণ, জবাবদিহিতা এবং সীমা গ্রহণ প্রযুক্তিগত সিদ্ধান্তের অবিচ্ছেদ্য অংশ। এই মডিউলে শেখা প্রতিটি অংশ এই সামগ্রিক নকশায় একত্রিত হয়।

আবেদন টাস্ক

এন্ড-টু-এন্ড একটি LLM বৈশিষ্ট্য ডিজাইন করুন। (1) আপনার নির্দিষ্ট কাজের জন্য পাঁচটি স্তর (ইনপুট, মডেল, যাচাইকরণ, অ্যাকশন, পর্যবেক্ষণ) পূরণ করুন। (2) প্রভাব দ্বারা চিহ্নিত করুন কোন সিদ্ধান্তের জন্য মানুষের অনুমোদনের প্রয়োজন হবে। (3) কমপক্ষে তিনটি যাচাইকরণ চেক লিখুন (স্কিমা, নিয়ম, উত্স)। (4) আপনি কী ট্র্যাক করবেন এবং আপনি কী লগ করবেন না তা নির্ধারণ করুন৷ (5) একটি সীমা এবং একটি নৈতিক নীতি লিখুন যা আপনি এই বৈশিষ্ট্যটিতে গ্রহণ করেন৷

চেকলিস্ট

• আমি উৎপাদন পাইপলাইনের পাঁচটি স্তর ডিজাইন করতে পারি।
• [] আমি স্কিমা, নিয়ম এবং উত্সের বিরুদ্ধে আউটপুট যাচাই করতে পারি।
• সিদ্ধান্তের প্রভাবের উপর ভিত্তি করে আমি একটি মানবিক অনুমোদনের সীমা নির্ধারণ করতে পারি।
• [ ] আমি খরচ, ত্রুটি এবং গুণমান নিরীক্ষণ করি এবং লগগুলিতে সংবেদনশীল ডেটা না লেখার অনুশীলন করি৷
• আমি নীতি, দায়িত্ব এবং সীমানাকে উৎপাদন সিদ্ধান্তে রূপান্তর করতে পারি।

মডিউল পরীক্ষা

1. একটি LLM চ্যাট API-এ 'সিস্টেম' ভূমিকা কী করে?

• ক) মডেলটিকে স্থায়ী নির্দেশাবলী এবং আচরণের নিয়ম দেয় যা পুরো কথোপকথন জুড়ে প্রযোজ্য হয় ✔
• খ) ব্যবহারকারীর লেখা শেষ প্রশ্ন রাখে
• গ) মডেল দ্বারা উত্পাদিত প্রতিক্রিয়া সংরক্ষণ করে
• D) API কী এনক্রিপ্ট করে

বর্ণনা: সিস্টেমের ভূমিকা মডেলকে অবিরাম নির্দেশনা, ব্যক্তিত্ব এবং নিয়ম দেয় যা পুরো কথোপকথন জুড়ে প্রযোজ্য হয়; এটি একটি উচ্চ-স্তরের পুনঃনির্দেশ, ব্যবহারকারীর বার্তাগুলি থেকে আলাদা৷

2. কেন প্রতিবার API অনুরোধে কথোপকথনের ইতিহাস (আগের বার্তা) আবার পাঠানো হয়?

• ক) সার্ভার ইতিহাস মুছে ফেলায় ব্যাকআপ করা প্রয়োজন
• খ) API কলগুলি রাষ্ট্রহীন; ✔ প্রতিটি অনুরোধে প্রসঙ্গ পাঠানো হয় কারণ মডেলটি ইতিহাস মনে রাখে না
• গ) শুধুমাত্র চালানের জন্য প্রয়োজনীয়, মডেলের উপর কোন প্রভাব নেই
• ঘ) প্রতিক্রিয়া মন্থর এড়াতে ইতিহাস পাঠানো বাধ্যতামূলক

ব্যাখ্যা: LLM API কলগুলি রাষ্ট্রহীন; মডেলটি পূর্ববর্তী রাউন্ডগুলি মনে রাখে না, তাই প্রসঙ্গ সংরক্ষণের জন্য প্রতিটি অনুরোধে সমস্ত প্রাসঙ্গিক ইতিহাস পাঠানো হয়৷

3. এলএলএম মূল্যে 'টোকেন' কী?

• ক) API এ লগ ইন করতে ব্যবহৃত ওয়ান-টাইম পাসওয়ার্ড
• খ) প্রতিটি অনুরোধে একটি নির্দিষ্ট ফি প্রদান করা হয়
• গ) ক্ষুদ্রতম একক যেখানে মডেল পাঠ্য প্রক্রিয়া করে; সাধারণত শব্দ অংশের সাথে মিলে যায় ✔
• D) একটি ইউনিট যা শুধুমাত্র আউটপুটের দৈর্ঘ্য পরিমাপ করে

বর্ণনা: টোকেন হল ক্ষুদ্রতম একক যেখানে মডেল পাঠ্য প্রক্রিয়া করে; এটি সাধারণত একটি শব্দের একটি অংশের সাথে মিলে যায় এবং ইনপুট এবং আউটপুট উভয়ই টোকেনের সংখ্যার উপর ভিত্তি করে চার্জ করা হয়।

4. কেন আউটপুট টোকেনগুলি বেশিরভাগ এলএলএম প্রদানকারীর ইনপুট টোকেনের চেয়ে বেশি ব্যয়বহুল?

• ক) আউটপুট টোকেন সবসময় ইনপুটের চেয়ে দীর্ঘ হয়
• খ) ইনপুট টোকেন বিনামূল্যে
• গ) আউটপুট টোকেন ইন্টারনেটের মাধ্যমে দুইবার পাঠানো হয়
• D) ইউনিট খরচ বেশি কারণ আউটপুট জেনারেশনের জন্য প্রতিটি টোকেনের জন্য অতিরিক্ত গণনার প্রয়োজন ✔

বর্ণনা: প্রতিটি আউটপুট টোকেনের জন্য মডেলকে ধাপে ধাপে জেনারেশন (গণনা) করতে হবে; এই উৎপাদন খরচ একবারে ইনপুট প্রক্রিয়াকরণের চেয়ে বেশি, তাই আউটপুট ইউনিটের দাম সাধারণত বেশি হয়।

5. কোন পরিস্থিতিতে স্ট্রিমিং ব্যবহার করা সবচেয়ে উপকারী?

• ক) দীর্ঘ উত্তরে; অনুভূত বিলম্ব হ্রাস করে এবং সময়সীমা রোধ করে ✔
• খ) শুধুমাত্র খুব সংক্ষিপ্ত, এক শব্দের উত্তর
• গ) খরচ শূন্যে নামিয়ে আনা
• ঘ) API কী লুকানোর জন্য

বর্ণনা: দীর্ঘ প্রতিক্রিয়াগুলিতে, প্রথম শব্দগুলি অবিলম্বে প্রদর্শিত করে স্ট্রিমিং অনুভূত বিলম্বিতা হ্রাস করে এবং বড় max_tokens মানগুলিতে HTTP টাইমআউট প্রতিরোধ করে।

6. আধুনিক মডেলগুলিতে 'প্রচেষ্টা' প্যারামিটার বৃদ্ধি সাধারণত কী প্রভাবিত করে?

• ক) সর্বদা উত্তর ছোট করুন
• খ) স্বয়ংক্রিয়ভাবে API কী ঘোরে
• গ) এটি শুধুমাত্র ইনপুট টোকেন মূল্য হ্রাস করে
• ঘ) চিন্তার গভীরতা এবং টোকেন ব্যয় বৃদ্ধি করে; এটি গুণমান উন্নত করতে পারে, তবে এটি লেটেন্সি এবং খরচও বাড়ায় ✔

বর্ণনা: প্রচেষ্টার প্যারামিটারটি সামঞ্জস্য করে যে মডেলটি একটি কাজ সম্পর্কে কতটা গভীরভাবে চিন্তা করবে এবং কত টোকেন খরচ করবে; আপগ্রেড করা মান উন্নত করতে পারে, কিন্তু এটি বিলম্ব এবং খরচও বাড়ায়। সাধারণ কাজের জন্য, কম পরিশ্রমই যথেষ্ট।

7. একটি সাধারণ, উচ্চ-ভলিউম শ্রেণীবিভাগের টাস্কের জন্য সাধারণত সবচেয়ে ব্যয়-কার্যকর পদ্ধতি কী?

• ক) সর্বদা সবচেয়ে ব্যয়বহুল এবং সবচেয়ে শক্তিশালী মডেল ব্যবহার করুন
• খ) প্রতিটি অনুরোধের জন্য একই সময়ে সমস্ত মডেলকে কল করা
• গ) সবচেয়ে হালকা/সস্তা মডেলটি নির্বাচন করা যা সামান্য ইভাল দিয়ে যাচাই করে কাজটি সম্পন্ন করে ✔
• ঘ) max_tokens মান অপ্রয়োজনীয়ভাবে খুব বেশি রাখা

ব্যাখ্যা: যদি কাজটি জটিল না হয়, তবে সবচেয়ে ব্যয়বহুল এবং শক্তিশালী মডেল ব্যবহার করার পরিবর্তে একটি দ্রুত এবং সস্তা মডেল বেছে নেওয়া যা সহজেই কাজটি সম্পন্ন করে (যেমন হাইকু ক্লাস) খরচ উল্লেখযোগ্যভাবে হ্রাস করবে।

8. কোন পরিস্থিতিতে প্রম্পট ক্যাশিং খরচ কমিয়ে দেয়?

• ক) যখন অনেক অনুরোধে একটি বড় এবং স্থির প্রসঙ্গ বারবার ব্যবহার করা হয় ✔
• খ) যখন প্রতিটি অনুরোধের সাথে একটি সম্পূর্ণ ভিন্ন পাঠ্য পাঠানো হয়
• গ) যখন শুধুমাত্র একটি অনুরোধ করা হয়
• ঘ) আউটপুট টোকেন কমাতে

বর্ণনা: ক্যাশিং একটি উপসর্গ মিল; এমন ক্ষেত্রে যেখানে একটি বড়, অপরিবর্তনীয় প্রসঙ্গ (সিস্টেম প্রম্পট, নথি) অনেক অনুরোধে পুনরায় ব্যবহার করা হয়, ক্যাশে থেকে পড়া সম্পূর্ণ মূল্যের একটি ছোট ভগ্নাংশ (~0.1x)।

9. আমি কিভাবে প্রম্পট সম্পাদনা করব যাতে প্রম্পট ক্যাশে হিট হয়?

• ক) শুরুতে পরিবর্তনশীল বিষয়বস্তু এবং শেষে স্থির বিষয়বস্তু রাখা
• খ) প্রতিটি অনুরোধের জন্য সিস্টেম প্রম্পটে বর্তমান তারিখ এবং সময় এম্বেড করুন
• গ) শুরুতে নির্দিষ্ট বিষয়বস্তু (সিস্টেম প্রম্পট, নথি) এবং শেষে পরিবর্তনশীল বিষয়বস্তু রাখা ✔
• ঘ) প্রতিটি অনুরোধের সাথে টুল তালিকার ক্রম পরিবর্তন করা

ব্যাখ্যা: যেহেতু ক্যাশে একটি প্রিফিক্স ম্যাচ, স্থির/অপরিবর্তিত বিষয়বস্তু (সিস্টেম প্রম্পট, নথি) শুরু করা হয়; পরিবর্তনশীল বিষয়বস্তু (তারিখ, ব্যবহারকারীর প্রশ্ন, অনুরোধ আইডি) শেষে রাখা হয়। এমনকি শুরুতে পরিবর্তিত একটি একক বাইট ক্যাশে অকার্যকর করবে।

10. কোন ধরনের কাজের চাপের জন্য ব্যাচ প্রক্রিয়াকরণ সবচেয়ে উপযুক্ত?

• ক) লাইভ চ্যাট যেখানে ব্যবহারকারী স্ক্রিনে তাত্ক্ষণিক প্রতিক্রিয়া আশা করে৷
• খ) মাত্র একটি সংক্ষিপ্ত প্রশ্ন
• গ) API কী তৈরি করা
• ঘ) যে কাজগুলি বিলম্ব সহনশীল, বড় আয়তনের এবং অবিলম্বে ফলাফলের প্রয়োজন হয় না ✔

বর্ণনা: ব্যাচ প্রসেসিং বৃহৎ পরিমান কাজের জন্য উপযুক্ত যেগুলির জন্য তাৎক্ষণিক প্রতিক্রিয়ার প্রয়োজন হয় না এবং বিলম্ব সহনশীল; ফলাফল কিছু সময় পরে বিতরণ করা হয়, কিন্তু ইউনিট খরচ সাধারণত কম হয়.

11. একটি ব্যাচের ফলাফল কোন অনুরোধের সাথে আত্মবিশ্বাসের সাথে মেলাতে ব্যবহৃত হয়?

• ক) অনুরোধ পাঠানোর আদেশ (অবস্থান)
• খ) উত্তরের দৈর্ঘ্য
• গ) API কী-এর শেষ 4টি সংখ্যা
• ঘ) প্রতিটি অনুরোধে একটি অনন্য কাস্টম_আইডি দেওয়া হয় ✔

মন্তব্য: বাল্ক ফলাফল জমা দেওয়ার আদেশের চেয়ে ভিন্ন ক্রমে ফেরত দেওয়া হতে পারে; তাই প্রতিটি অনুরোধে একটি অনন্য কাস্টম_আইডি দিয়ে আইডি দিয়ে ফলাফল মেলে, অবস্থান নয়।

12. যখন আপনি API থেকে একটি 429 (রেট লিমিট) ত্রুটি পান তখন প্রস্তাবিত আচরণ কী?

• ক) একই সময়ে আরও অনেক অনুরোধ পাঠানোর মাধ্যমে জোর করা
• খ) সূচকীয় ব্যাকঅফের সাথে আবার চেষ্টা করা, পুনরায় চেষ্টা-পরবর্তী শিরোনাম অনুসরণ করে ✔
• গ) অনুরোধটি সম্পূর্ণ বাতিল করুন এবং ব্যবহারকারীর কাছে ক্র্যাশ হিসাবে ত্রুটিটি দেখান
• ঘ) API কী পরিবর্তন করা

ব্যাখ্যা: 429 একটি পুনরায় চেষ্টাযোগ্য ত্রুটি; সঠিক পদ্ধতি হল সূচকীয় ব্যাকঅফ দিয়ে আবার চেষ্টা করা, পুনরায় চেষ্টা-পরবর্তী শিরোনামকে সম্মান করে। বেশিরভাগ অফিসিয়াল SDK স্বয়ংক্রিয়ভাবে এটি করে।

13. নিম্নলিখিত HTTP ত্রুটি কোডগুলির মধ্যে কোনটি সাধারণত পুনঃপ্রচেষ্টাযোগ্য বলে বিবেচিত হয়?

• ক) 400 (অবৈধ অনুরোধ)
• খ) 401 (প্রমাণিকরণ ত্রুটি)
• গ) 529 (সার্ভার ওভারলোড) ✔
• D) 404 (পাওয়া যায়নি)

ব্যাখ্যা: 429 (গতি সীমা), 500 (সার্ভার ত্রুটি) এবং 529 (ওভারলোড) অস্থায়ী ত্রুটি এবং ব্যাক অফ করে পুনরায় চেষ্টা করা যেতে পারে। 400 এবং 401 এর মত ত্রুটি হল অনুরোধ/পরিচয় সংক্রান্ত সমস্যা; আবার চেষ্টা করলে সমাধান হবে না।

14. API কীগুলি পরিচালনা করার নিরাপদ উপায় নিচের কোনটি?

• ক) এনভায়রনমেন্ট ভেরিয়েবল/হিডেন ম্যানেজারে স্টোর করা, কোডে এম্বেড না করা এবং নিয়মিত ঘোরানো ✔
• খ) কীটি সরাসরি সোর্স কোডে লিখুন এবং সংগ্রহস্থলে পাঠান
• গ) ক্লায়েন্ট সাইডে (ব্রাউজার) জাভাস্ক্রিপ্টে কী রাখা
• ঘ) ইমেলের মাধ্যমে পুরো দলের সাথে একটি একক কী শেয়ার করা

বর্ণনা: কীগুলি কখনই সোর্স কোড বা সংগ্রহস্থলে লেখা হয় না; এটি একটি এনভায়রনমেন্ট ভেরিয়েবল বা লুকানো ম্যানেজমেন্ট টুলে সংরক্ষণ করা হয়, যা ন্যূনতম সুযোগ-সুবিধা দিয়ে দেওয়া হয় এবং নিয়মিত ঘোরানো হয়।

15. গোপনীয়তার পরিপ্রেক্ষিতে একটি অটোমেশন টুল (n8n, Zapier, Make) এর সাথে LLM ইন্টিগ্রেশনের সর্বোত্তম পন্থা কী?

• ক) মডেলে সমস্ত কাঁচা ডেটা পাঠানো, এমনকি যদি এটি প্রয়োজনীয় না হয়
• খ) ফ্লো স্টেপের ভিতরে প্লেইন টেক্সটে API কী লেখা
• গ) সংবেদনশীল ডেটা মিনিমাইজ করা এবং মাস্ক করা এবং গোপন শংসাপত্র হিসাবে কী সংরক্ষণ করা ✔
• ঘ) প্রবাহ ইতিহাসে স্থায়ীভাবে ব্যক্তিগত তথ্য রাখা

বর্ণনা: যেহেতু অটোমেশনে প্রবেশ করা ডেটা তৃতীয় পক্ষের সিস্টেম এবং মডেলের মধ্য দিয়ে যায়, সেহেতু সংবেদনশীল/ব্যক্তিগত ডেটা মিনিমাইজ করা, মাস্ক করা এবং শুধুমাত্র প্রয়োজনীয় ক্ষেত্র পাঠানো প্রয়োজন; API কী টুলের মধ্যে গোপন শংসাপত্র হিসাবেও সংরক্ষণ করা হয়।

16. কেন একটি এলএলএম ভিত্তিক উৎপাদন বৈশিষ্ট্যে আউটপুট বৈধকরণ বাধ্যতামূলক?

• ক) শুধুমাত্র ফরম্যাটিং প্রয়োজন কারণ মডেল কখনো ভুল করে না
• খ) কারণ মডেলটি তরলভাবে উত্পাদন করতে পারে তবে কখনও কখনও ভুলভাবে; স্কিমা/নিয়ম অবশ্যই সম্পদ এবং মানুষের অনুমোদনের সাথে নিরীক্ষা করা উচিত ✔
• গ) বৈধকরণ এড়ানো উচিত কারণ এটি শুধুমাত্র খরচ বাড়ায়
• ঘ) যাচাইকরণ শুধুমাত্র টোকেনের সংখ্যা কমানোর জন্য

বর্ণনা: এলএলএম সাবলীল কিন্তু কখনও কখনও ভুল (হ্যালুসিনেটরি) আউটপুট তৈরি করতে পারে; তাই এটি উচ্চ প্রভাবের সিদ্ধান্তে বেরিয়ে এসেছে; এটি স্কিমা/নিয়ম চেকিং, সোর্স ভ্যালিডেশন এবং প্রয়োজনে মানুষের অনুমোদন দ্বারা নিরীক্ষা করা উচিত।