লাভ:
- একটি LLM API অনুরোধের মৌলিক কাঠামো বর্ণনা করতে পারে (এন্ডপয়েন্ট, মডেল, বার্তা, max_tokens)
- সিস্টেম, ব্যবহারকারী এবং সহকারী ভূমিকা এবং রাষ্ট্রহীন কথোপকথনের ইতিহাসের মধ্যে পার্থক্য বোঝে
- ফিরে আসা প্রতিক্রিয়ার ক্ষেত্রগুলি (কন্টেন্ট ব্লক, স্টপ_রিজন, ব্যবহার) পড়তে এবং ব্যাখ্যা করতে পারে
পূর্ববর্তী মডিউলগুলিতে, আমরা একটি চ্যাট উইন্ডো থেকে কৃত্রিম বুদ্ধিমত্তা ব্যবহার করেছি। কিন্তু আপনি যদি আপনার নিজস্ব পণ্য, অটোমেশন বা ওয়ার্কফ্লোতে AI এম্বেড করতে চান তবে একটি চ্যাট ইন্টারফেস এটিকে কাটবে না; আপনাকে প্রোগ্রামগতভাবে মডেলের সাথে সংযোগ করতে হবে, অর্থাৎ কোড বা একটি অটোমেশন টুল দিয়ে। এই সেতুর নাম API (অ্যাপ্লিকেশন প্রোগ্রামিং ইন্টারফেস, চুক্তি যা দুটি সফ্টওয়্যারকে নির্দিষ্ট নিয়মের সাথে কথা বলার অনুমতি দেয়)। আপনি যখন এই ইউনিটটি শেষ করবেন, তখন আপনি জানতে পারবেন একটি LLM (বড় ভাষা মডেল) API অনুরোধ কী গঠন করে, বার্তার ভূমিকা কী এবং কীভাবে প্রতিক্রিয়া পড়তে হয়। এটি সেই ভিত্তি যার উপর বাকি মডিউলটি নির্মিত হবে।
API কিভাবে কাজ করে?
API-এর মৌলিক প্রবাহ হল: আপনি একটি নির্দিষ্ট বিন্যাসে একটি অনুরোধ পাঠান; সার্ভার একটি নির্দিষ্ট বিন্যাসে একটি প্রতিক্রিয়া প্রদান করে। LLM-এ, এটি সাধারণত একটি HTTP কল (HTTP: ওয়েবে অনুরোধ-প্রতিক্রিয়া বহনের জন্য স্ট্যান্ডার্ড প্রোটোকল) একটি একক ঠিকানায় (শেষ পয়েন্ট, সার্ভারে নির্দিষ্ট ঠিকানা যা আপনার অনুরোধ পরিচালনা করে)। উদাহরণস্বরূপ, একটি মেসেজিং এপিআই-এ, সমস্ত অনুরোধগুলি একটি একক ঠিকানায় যায় এবং JSON (জাভাস্ক্রিপ্ট অবজেক্ট নোটেশন - একটি পাঠ্য বিন্যাস যা কী/মান জোড়া রয়েছে যা মানুষ এবং মেশিন উভয়ই পড়তে পারে) হিসাবে বয়ে নিয়ে যায়।
একটি অনুরোধে, আপনি অন্তত এই তিনটি জিনিস নির্দিষ্ট করুন:
- মডেল: আপনি কোন মডেল ব্যবহার করবেন (যেমন একটি দ্রুত এবং সস্তা মডেল বা একটি শক্তিশালী মডেল)।
- max_tokens: মডেলটি তৈরি করতে পারে এমন সর্বাধিক সংখ্যক টোকেন (যে ক্ষুদ্রতম ইউনিটে পাঠ্যটি প্রক্রিয়া করা হয়, যা পরবর্তী ইউনিটে বিস্তারিতভাবে প্রক্রিয়া করা হবে); যেমন আউটপুট সীমা।
- বার্তা: কথোপকথন তৈরি করে এমন বার্তাগুলির তালিকা।
ধাপে ধাপে: কীভাবে একটি অনুরোধ সেট আপ করবেন
- শেষ পয়েন্ট এবং শংসাপত্র প্রস্তুত করুন। আপনি শিরোনামের অনুরোধে আপনার API কী (গোপন স্ট্রিং যা আপনার পরিচয় প্রমাণ করে) যোগ করুন। আপনি কখনই কোডে কী এমবেড করবেন না; আমরা ইউনিট 9 এ নিরাপদ স্টোরেজ কভার করব।
- মডেল এবং আউটপুট সীমা নির্বাচন করুন। একটি সাধারণ কাজের জন্য লাইটওয়েট মডেল + ছোট ম্যাক্স_টোকেন; শক্তিশালী মডেল + একটি জটিল কাজের জন্য বৃহত্তর সীমা।
- বার্তা তালিকা সেট আপ করুন. List the system instruction, user message, and past rounds (if any).
- অনুরোধ পাঠান এবং প্রতিক্রিয়া পার্স. ফিরে আসা JSON থেকে পাঠ্য বিষয়বস্তু পড়ুন, কারণ বন্ধ করুন এবং টোকেন ব্যবহার করুন।
বার্তার ভূমিকা: সিস্টেম, ব্যবহারকারী, সহকারী
একটি কথোপকথন একটি ক্রমানুসারে সাজানো বার্তাগুলি নিয়ে গঠিত এবং প্রতিটি বার্তার একটি ভূমিকা রয়েছে৷ ভূমিকাটি নির্ধারণ করে যে মডেলটি সেই পাঠ্যটিকে কীভাবে আচরণ করে।
ভূমিকা
কে লেখে
উদ্দেশ্য
সিস্টেম
বিকাশকারী/অপারেটর
স্থায়ী নির্দেশাবলী, ব্যক্তিত্ব এবং নিয়ম যা পুরো কথোপকথন জুড়ে প্রযোজ্য
ব্যবহারকারী
শেষ ব্যবহারকারী
ব্যবহারকারীর বর্তমান প্রশ্ন বা ইনপুট
সহকারী
মডেল
মডেল দ্বারা উত্পাদিত প্রতিক্রিয়া (এবং পূর্ববর্তী প্রতিক্রিয়া)
সিস্টেমের ভূমিকা বেশিরভাগ প্রদানকারীর অনুরোধের অংশে একটি পৃথক সিস্টেম ক্ষেত্র হিসাবে উপলব্ধ; ব্যবহারকারী এবং সহকারীকে বার্তা তালিকায় ক্রমানুসারে তালিকাভুক্ত করা হয়েছে। Critical point: the system instruction is the high-level instruction, the user message is the request to be answered at that moment.
{ "model": "claude-opus-4-8", "max_tokens": 1024, "system": "আপনি একজন কর্পোরেট সহায়তা সহকারী। একটি সংক্ষিপ্ত, আনুষ্ঠানিক এবং যাচাইকৃত প্রতিক্রিয়া দিন। আপনি যে তথ্য সম্পর্কে নিশ্চিত নন তা তৈরি করবেন না।", "messages": [ { "role": "user", "আমি প্রত্যাবর্তনের প্রক্রিয়া শুরু করব?" } ]}
বক্তৃতা রাষ্ট্রহীন
এখানে সবচেয়ে সাধারণ ভুল ধারণা রয়েছে: LLM API কলগুলি স্টেটলেস - সার্ভার দুটি অনুরোধের মধ্যে কোনও মেমরি ধরে রাখে না। মডেল আপনার আগের অনুরোধ মনে নেই. আপনি যদি একটি মাল্টি-রাউন্ড চ্যাট সেট আপ করেন তবে আপনাকে প্রতিটি নতুন অনুরোধের সাথে অতীতের রাউন্ডগুলি পুনরায় পাঠাতে হবে। মডেলের "মেমরি" আপনার পাঠানো বার্তাগুলির একটি তালিকা নিয়ে গঠিত৷
{ "মডেল": "claude-opus-4-8", "max_tokens": 512, "messages": [ { "role": "user", "content": "হ্যালো, আমার নাম ডেনিজ।" }, { "role": "assistant", "content": "Hello Deniz, আমি কিভাবে আপনাকে সাহায্য করতে পারি?" }, { "role": "user", "content": "আমি শুধু আমার নাম বলেছি, মনে আছে?" } ]}
তৃতীয় বার্তার সঠিক উত্তর দেওয়া আপনার আগের দুটি বার্তা পাঠানোর উপর নির্ভর করে। আপনি যদি এটি না পাঠান, তাহলে মডেলটি "সমুদ্র" জানতে পারবে না এবং ভুল উত্তর দেবে৷ এটি সরাসরি খরচকেও প্রভাবিত করে: কথোপকথন যত দীর্ঘ হবে, তালিকা তত বড় হবে, প্রতিটি অনুরোধ আরও টোকেন গ্রহণ করবে।
টিপ: দীর্ঘ কথোপকথনে, পুরো ইতিহাস পাঠানোর পরিবর্তে পুরানো রাউন্ডগুলি (সারাংশ + শেষ কয়েকটি রাউন্ড) সংক্ষিপ্ত করা এবং সরানো খরচ হ্রাস করে এবং প্রসঙ্গ উইন্ডোটি সংরক্ষণ করে। আমরা এটিকে 6 এবং 11 ইউনিটে গভীর করব।
উত্তর পড়ুন
যখন মডেল একটি প্রতিক্রিয়া প্রদান করে, আপনি একটি কাঠামোগত বস্তু পাবেন, সাধারণ পাঠ্য নয়। সাধারণ এলাকা:
{ "id": "msg_01ABC...", "model": "claude-opus-4-8", "role": "Assistant", "content": [ { "type": "text", "text": "রিটার্ন শুরু করতে, আপনার অ্যাকাউন্টে 'আমার অর্ডার' পৃষ্ঠাতে যান..." } ], "stop_reason:" "stop_reason:" "input_tokens": 47, "output_tokens": 88 }}
- বিষয়বস্তু: প্রতিক্রিয়া নিজেই; এটি বিষয়বস্তু ব্লকের একটি তালিকা। পাঠ্য ব্লকের পাঠ্য ক্ষেত্রটি প্রকৃত উত্তর।
- stop_reason: কেন মডেল থামল। end_turn = প্রাকৃতিক শেষ; max_tokens = আউটপুট সীমাতে আটকে আছে (প্রতিক্রিয়া অসম্পূর্ণ হতে পারে); অস্বীকার = নিরাপত্তার কারণে প্রত্যাখ্যান করা হয়েছে। আপনার কোড সর্বদা প্রথমে stop_reason দেখতে হবে।
- ব্যবহার: ইনপুট এবং আউটপুট টোকেন নম্বর। এটি ব্যয় এবং সীমা ট্র্যাকিংয়ের ভিত্তি।
মনোযোগ: যদি stop_reason max_tokens হয়, প্রতিক্রিয়া সম্পূর্ণ হয় না। এটিকে "সফল প্রতিক্রিয়া" হিসাবে বিবেচনা করা এবং ব্যবহারকারীকে অর্ধেক পাঠ্য দেখানো উৎপাদনের সবচেয়ে সাধারণ ভুলগুলির মধ্যে একটি। হয় max_tokens বাড়ান অথবা স্ট্রিমিং ব্যবহার করুন।
দুর্বল প্রম্পট / শক্তিশালী প্রম্পট
দুটি ভিন্ন সিস্টেম প্রম্পট সহ একই কাজ:
# দুর্বল তুমি একজন সহকারী। প্রশ্নগুলোর উত্তর দাও।
# স্ট্রং আপনি একজন কর্পোরেট সহায়তা সহকারী। নিয়ম:- শুধুমাত্র প্রদত্ত পলিসি নথিতে তথ্যের উপর নির্ভর করুন; যদি এটি নথিতে না থাকে তবে বলুন "আমার কাছে এই তথ্য নেই, আমি এটি প্রাসঙ্গিক ইউনিটে নির্দেশ করছি।" - উত্তরগুলি 3টি বাক্যের বেশি হওয়া উচিত নয়, আনুষ্ঠানিক এবং পরিষ্কার হওয়া উচিত। - ব্যক্তিগত ডেটা (টিসি আইডি নম্বর, কার্ড নম্বর) জিজ্ঞাসা করবেন না এবং পুনরাবৃত্তি করবেন না। - আপনি যখন নিশ্চিত না হন তখন অনুমান করবেন না।
শক্তিশালী সংস্করণ; এটি সুযোগ, ফর্ম, নিরাপত্তা মার্জিন, এবং অনিশ্চয়তার মধ্যে আচরণ সংজ্ঞায়িত করে। মডেল আউটপুট এর ধারাবাহিকতা এই স্পষ্টতা থেকে সরাসরি আসে।
তিনটি মিনি কেস
কেস 1 — সমর্থন বট (রাষ্ট্রহীনতার ফাঁদ)। একটি ই-কমার্স দল বটটি লাইভ নিয়েছিল; যখন ব্যবহারকারী বলেন "আগের অর্ডার বাতিল করুন", বট অর্ডার নম্বর "ভুলে গেছে"। কারণ: তারা শুধুমাত্র শেষ বার্তা দিয়ে প্রতিটি অনুরোধ পাঠাচ্ছিল। সমাধান: তারা বার্তা তালিকায় শেষ 6 রাউন্ড যোগ করেছে। ফলাফল: প্রসঙ্গ সংরক্ষিত, কিন্তু অনুরোধ প্রতি ইনপুট 40 টোকেন থেকে ~600 টোকেনে বেড়েছে — আমরা ইউনিট 2-এ খরচ পাঠ কভার করব।
কেস 2 - অসম্পূর্ণ চুক্তির সারাংশ। একটি আইনি দল 10-পৃষ্ঠার চুক্তির রূপরেখা ছিল; max_tokens: 300 কম রয়ে গেছে, সারাংশ মধ্য-বাক্যটি কেটে দিচ্ছে। stop_reason প্রতিবার max_tokens ছিল কিন্তু কেউ তাকাচ্ছে না। max_tokens বাড়িয়ে 1500 করা হয়েছে এবং stop_reason চেক যোগ করা হয়েছে; ছেঁটে যাওয়া সারাংশের হার 18% থেকে 0% এ কমেছে।
কেস 3 - মিশ্রিত ভূমিকা। একটি বিপণন দল ব্যবহারকারীর বার্তায় সমস্ত নির্দেশাবলী লিখছিল, সিস্টেমটি ফাঁকা রেখেছিল। যখন ব্যবহারকারীর ইনপুট নির্দেশের সাথে মিশ্রিত হয়, তখন মডেলটি কখনও কখনও ব্যবহারকারীর "আগের নিয়মগুলি ভুলে যাওয়ার" নির্দেশ মেনে চলে। তারা সিস্টেমে স্থায়ী নিয়ম সরানো; নির্দেশনা থেকে ব্যবহারকারীর ইনপুট আলাদা করে, নিয়ম লঙ্ঘন উল্লেখযোগ্যভাবে কমে গেছে।
সাধারণ ভুল
- অতীত পাঠাতে ভুলে যাওয়া: মডেলটিকে "মনে নেই" বলে মনে করা হয়; যদিও এটা রাষ্ট্রহীন। আপনি প্রসঙ্গ বহন.
- `স্টপ_রিজন` এর দিকে না তাকিয়ে: max_tokens-এর সাথে বন্ধ হওয়া প্রতিক্রিয়া সম্পূর্ণ বলে বিবেচিত হয়।
- 'ব্যবহারকারী'-তে নির্দেশনা এম্বেড করা: সিস্টেমে স্থায়ী নিয়ম; তাত্ক্ষণিক ইনপুট ব্যবহারকারীর কাছে যায়। মিশ্রণ নিরাপত্তা দুর্বলতা তৈরি করে।
- একটি প্লেইন স্ট্রিং এর জন্য 'সামগ্রী' ভুল করা: উত্তর হল ব্লকের একটি তালিকা; প্রথম টেক্সট ব্লকের টেক্সট ফিল্ড পড়ুন, ব্লাইন্ড ইনডেক্স দিয়ে কন্টেন্ট[0] পাওয়ার আগে এর ধরন যাচাই করুন।
- কোডে কী এম্বেড করা: একটি পরিবেশ পরিবর্তনশীল (ইউনিট 9) ব্যবহার করুন।
গভীরতর: বিষয়বস্তু ব্লক এবং বহু-অংশের উত্তর
প্রতিক্রিয়ার বিষয়বস্তু ক্ষেত্রটি কেন একটি তালিকা তা বোঝার জন্য আপনি পরবর্তীতে যে উন্নত বৈশিষ্ট্যগুলির মুখোমুখি হবেন তার জন্য মৌলিক। কখনও কখনও মডেলটি পাঠ্যের একটি ব্লক নয়, তবে বেশ কয়েকটি ব্লক ফেরত দেয়: চিন্তার একটি ব্লক, পাঠ্যের একটি ব্লক অনুসরণ করে; বা টেক্সট একটি ব্লক একটি টুল ব্যবহার ব্লক দ্বারা অনুসরণ করা. এই কারণেই অন্ধভাবে বিষয়বস্তু[0]কে "উত্তর" হিসেবে গণনা করা ভঙ্গুর। সঠিক পদ্ধতি হল তালিকার মধ্য দিয়ে যাওয়া এবং টাইপ অনুসারে বাছাই করা: আপনি ব্লকের টেক্সট বিষয়বস্তু সংগ্রহ করেন যার টাইপ ফিল্ড টেক্সট, এবং অন্য ধরনের (চিন্তা, টুল) আলাদাভাবে ব্যবহার করুন।
এই পার্থক্যটি অনুশীলনে যা করে তা হল আপনি ব্যবহারকারীর কাছে প্রকাশ না করেই মডেলের যুক্তি (যদি থাকে) লগ করতে পারেন, টুল কলগুলিকে পৃথক যুক্তিতে পুনঃনির্দেশ করতে পারেন এবং শুধুমাত্র আসল উত্তরটি স্ক্রিনে প্রিন্ট করতে পারেন। মডিউলটি অগ্রসর হওয়ার সাথে সাথে (বিশেষ করে ইউনিট 4 এবং 11-এ) আপনি দেখতে পাবেন যে এই ব্লক কাঠামোটি আউটপুট যাচাইকরণ এবং নির্দেশিত করার জন্য কতটা কার্যকর।
আরেকটি ব্যবহারিক পয়েন্ট: আপনি বিভিন্ন প্রদানকারী প্ল্যাটফর্ম থেকে একই মডেল অ্যাক্সেস করতে পারেন (সরাসরি API, একটি ক্লাউড প্রদানকারীর মাধ্যমে)। যদিও শেষবিন্দু ঠিকানা এবং প্রমাণীকরণ বিন্যাস পরিবর্তিত হতে পারে, মৌলিক ধারণা যেমন বার্তার ভূমিকা, রাষ্ট্রহীনতা এবং প্রতিক্রিয়া কাঠামো একই থাকে। সুতরাং আপনি যে প্ল্যাটফর্ম ব্যবহার করেন না কেন এই ইউনিটের মৌলিক বিষয়গুলি প্রযোজ্য।
সংক্ষেপে
একটি LLM API অনুরোধে মডেল, আউটপুট সীমা এবং বার্তা তালিকা থাকে; ভূমিকা (সিস্টেম, ব্যবহারকারী, সহকারী) মডেলের আচরণ নির্ধারণ করে। কলগুলি রাষ্ট্রহীন: আপনি প্রতিটি অনুরোধের সাথে প্রসঙ্গ বহন করেন। প্রতিক্রিয়া একটি কাঠামোগত বস্তু; বিষয়বস্তু, স্টপ_রিজন এবং ব্যবহারের ক্ষেত্রগুলি পড়া এবং ব্যাখ্যা করা উত্পাদনের স্থায়িত্বের ভিত্তি।
আবেদন টাস্ক
আপনার নিজের পেশা থেকে একটি কাজ চয়ন করুন (যেমন ইনকামিং ই-মেইল বাছাই করা, সংক্ষিপ্ত সারাংশ তৈরি করা)। কাগজের টুকরোতে: (1) 4-5 নিয়ম সহ সিস্টেম প্রম্পট লিখুন, (2) একটি নমুনা ব্যবহারকারী বার্তা এবং একটি 2-রাউন্ড ইতিহাস যদি থাকে তবে সেট আপ করুন, (3) max_tokens-এর জন্য একটি যুক্তিসঙ্গত মান নির্ধারণ করুন এবং ন্যায্যতা লিখুন, (4) প্রত্যাবর্তিত প্রতিক্রিয়াতে আপনি কোন stop_reason মানগুলি পরিচালনা করবেন এবং কীভাবে করবেন তা তালিকা।
চেকলিস্ট
- [ ] আমি একটি অনুরোধের তিনটি বাধ্যতামূলক অংশ গণনা করতে পারি (মডেল, সর্বোচ্চ_টোকেন, বার্তা)।
- [ ] আমি সিস্টেম, ব্যবহারকারী এবং সহকারী ভূমিকার মধ্যে পার্থক্য ব্যাখ্যা করতে পারি।
- [ ] আমি জানি যে কলগুলি রাষ্ট্রহীন এবং আমাকে অতীতকে বহন করতে হবে৷
- আমি [ ] বিষয়বস্তু, স্টপ_রিজন এবং ব্যবহার ক্ষেত্র পড়তে এবং মন্তব্য করতে পারি।
- [ ] max_tokens এর সাহায্যে আমি ছাঁটা প্রতিক্রিয়া লক্ষ্য করতে এবং পরিচালনা করতে পারি।