মূল লেখায় যান
পার্ট ১৩ ৩ মিনিট পড়া

AI অ্যাপ্লিকেশনের আর্কিটেকচার

মডেলকে ঘিরে অ্যাপ কীভাবে বানাবেন: ব্যবহারকারীকে উত্তর স্ট্রিম করা, লম্বা কাজ ব্যাকগ্রাউন্ডে চালানো, নিরাপদে রিট্রাই করা, অনেক কাস্টমারের জন্য কী আর প্রম্পট সামলানো, এক প্রোভাইডার ব্যর্থ হলে আরেকটায় যাওয়া, আর AI ফিচারের জন্য API ডিজাইন।

কুইজে যান
এই পাতায়

AI অ্যাপ্লিকেশনের আর্কিটেকচার

একটা LLM কল আসলে শুধু একটা HTTP রিকোয়েস্ট। এর চারপাশে একটা প্রোডাক্ট বানাতে আধুনিক যেকোনো অ্যাপের মতো একই কাঠামো লাগে, সঙ্গে কয়েকটা নতুন জিনিস: স্ট্রিমিং, রিজিউমেবিলিটি, মাল্টি-টেন্যান্সি, ফলব্যাক, ফিচার ফ্ল্যাগ, আর পার্শিয়াল রেজাল্টের জন্য বানানো API।

অনুশীলন · ৪টি টাস্ক

যেকোনো ফ্রি AI চ্যাট খুলুন: ChatGPT · Claude · Gemini

অনুশীলন কীভাবে করবেন
  • নতুন চ্যাট মানে একদম নতুন কথোপকথন, আগের কোনো হিস্ট্রি নেই। ChatGPT, Claude বা Gemini-তে New chat-এ ক্লিক করুন। সাধারণত এটা উপরে বাঁ দিকে থাকে।
  • একই চ্যাট মানে: যে চ্যাট খোলা আছে, সেখানেই লিখতে থাকুন। আগে যা পাঠিয়েছেন, AI তা মনে রাখে।
  • প্রম্পট ব্যবহার করতে: কপি-তে ক্লিক করুন, চ্যাটের মেসেজ বক্সে ক্লিক করুন, পেস্ট করুন (Ctrl+V, বা ফোনে চেপে ধরে রাখুন), তারপর Enter চাপুন।
  • AI-এর উত্তর প্রতিবার একটু আলাদা হয়। আপনার উত্তর উদাহরণের সাথে হুবহু মিলতে হবে না। একই ধারণা আছে কি না, সেটা দেখুন।
  • শুধু বানানো ডেটা ব্যবহার করুন। নিজের বা অন্যের ব্যক্তিগত তথ্য চ্যাটে পেস্ট করবেন না।

টাস্ক ১

স্ট্রিম হওয়া উত্তরের প্রথম শব্দের সময় মাপুন

এটা কেন দরকার

আপনি যখন চ্যাট ফিচার বানাবেন, স্ক্রিন অনেক সেকেন্ড খালি থাকলে ইউজার চলে যায়। স্ট্রিমিং মডেল যেমন যেমন লেখে, তেমন তেমন শব্দ দেখায়, তাই অ্যাপ দ্রুত মনে হয়।

  1. ধাপ ১
    নতুন চ্যাট

    এই প্রম্পটটা কপি করুন। Enter চাপার সঙ্গে সঙ্গে স্টপওয়াচ চালু করুন। প্রথম শব্দ আর শেষ শব্দ আসার সময় লিখে রাখুন।

    প্রম্পট
    প্রায় ৪০০ শব্দের একটা গল্প লেখো। চট্টগ্রামের একজন বাস ড্রাইভার রাতের শেষ ট্রিপে একটা হারানো ব্যাগ খুঁজে পায়। কোনো ভূমিকা ছাড়া সঙ্গে সঙ্গে গল্প শুরু করো।

    আপনি দেখবেন: প্রথম শব্দ তাড়াতাড়ি আসে, যেমন ১ বা ২ সেকেন্ড পরে। শেষ শব্দ আসে অনেক পরে, যেমন ১৫ থেকে ৩০ সেকেন্ড পরে।

    উদাহরণ উত্তর
    রাতের শেষ বাসটা রাত ১১টা ৪০-এ চট্টগ্রামের ডিপোতে ঢুকল। রফিক ইঞ্জিন বন্ধ করে, রোজকার মতো, সিটগুলো দেখতে করিডর ধরে হাঁটল। পেছনের সারির নিচে সে একটা ছোট কালো ব্যাগ দেখতে পেল...

    আপনার উত্তরের ভাষা একটু আলাদা হবে।

  2. ধাপ ২
    একই চ্যাট

    ধরুন চ্যাট শেষ শব্দ পর্যন্ত কিছুই দেখায়নি। ইউজার কত সময় অপেক্ষা করত আর তার কেমন লাগত, লিখে রাখুন।

    আপনি দেখবেন: আপনার লেখা পুরো সময়টা, যেমন ২০ সেকেন্ড, ইউজার একটা খালি স্ক্রিন দেখত। বেশিরভাগ মানুষ ভাবত অ্যাপ নষ্ট।

  3. ধাপ ৩
    নতুন চ্যাট

    প্রম্পট পাঠানোর আগে তিনটা ফিচার পড়ুন। তারপর পেস্ট করে Enter চাপুন।

    প্রম্পট
    এই তিনটার প্রতিটা এক সহজ বাক্যে বুঝিয়ে বলো: SSE (Server-Sent Events), WebSockets, আর HTTP chunked transfer।
    তারপর প্রতিটা feature-এর জন্য একটা বেছে নাও আর একটা কারণ দাও।
    Feature ১: একটা AI chat-এর উত্তর শব্দ শব্দ করে আসে। data শুধু server থেকে browser-এ যায়। পথটা একটা সাধারণ HTTP proxy।
    Feature ২: একটা voice call, যেখানে user আর AI একসঙ্গে কথা বলতে পারে।
    Feature ৩: একটা পুরনো company proxy-র জন্য fallback, যে proxy SSE header মুছে ফেলে।
    শেষে SSE-র তুলনায় WebSockets-এর একটা খরচ বা অসুবিধা বলো।

    আপনি দেখবেন: ফিচার ১-এর জন্য SSE, ফিচার ২-এর জন্য ওয়েবসকেট, আর ফিচার ৩-এর জন্য HTTP চাঙ্কড। ওয়েবসকেটের খরচ হলো ভারী সেটআপ।

    উদাহরণ উত্তর
    SSE: server একটা সাধারণ HTTP connection দিয়ে browser-এ text ঠেলে দেয়। এটা একমুখী।
    WebSockets: একটা খোলা connection, যেখানে দুই পক্ষই যেকোনো সময় পাঠাতে পারে।
    HTTP chunked: server একটা response অনেক ছোট টুকরোয় পাঠায়।
    Feature ১: SSE। data শুধু এক দিকে যায়, আর সাধারণ proxy দিয়েও চলে।
    Feature ২: WebSockets। দুই পক্ষকেই একসঙ্গে audio পাঠাতে হয়।
    Feature ৩: HTTP chunked। proxy SSE header মুছে ফেললেও এটা চলে।
    WebSockets-এর খরচ: ভারী handshake (শুরুর setup) আর চালাতে বেশি কাজ।

    আপনার উত্তরের ভাষা একটু আলাদা হবে।

এইমাত্র কী হলো

মডেল টোকেন (শব্দের ছোট অংশ) একটা একটা করে লেখে। স্ট্রিমিং থাকলে অ্যাপ প্রতিটা টোকেন সঙ্গে সঙ্গে দেখায়। মোট সময় বদলায় না, কিন্তু ইউজার প্রায় এক সেকেন্ড পরে প্রথম শব্দ দেখে আর পড়া শুরু করে। SSE স্ট্রিম করার সবচেয়ে সহজ উপায়, কারণ ডেটা শুধু এক দিকে যায়, সার্ভার থেকে ব্রাউজারে।

কাজ শেষ, যখন আপনার কাছে গল্পের দুটো সময় (প্রথম শব্দ আর শেষ শব্দ) আছে, আর ৩টা ফিচারের প্রতিটার জন্য একটা ট্রান্সপোর্ট আছে।

নিজেকে যাচাই করুনস্ট্রিমিংয়ে উত্তর লেখার মোট সময় বদলায় না। তবুও অ্যাপ কেন বেশি দ্রুত মনে হয়?উত্তর দেখুন

ইউজার অল্প সময় পরেই প্রথম শব্দ দেখে আর পড়া শুরু করতে পারে। স্ট্রিমিং না থাকলে সে খালি স্ক্রিন নিয়ে পুরো উত্তরের জন্য অপেক্ষা করত।

আরেকটু কঠিন করে দেখুন

১,০০০ শব্দের গল্প চান আর আবার মাপুন। প্রথম শব্দের সময় কি বেশি বদলায়? এটা থেকে কী বোঝা যায়?

টাস্ক ২

লম্বা জব চালানো একটা সার্ভার সাজান

এটা কেন দরকার

আপনি যখন ৪ মিনিট ধরে কাজ করা একটা AI এজেন্ট বানাবেন, তখন ওয়েব রিকোয়েস্ট খুলে রাখা যাবে না। অনেক সার্ভার এত লম্বা অপেক্ষার রিকোয়েস্ট কেটে দেয়, আর ইউজার কিছুই দেখে না।

  1. ধাপ ১
    নতুন চ্যাট

    এই প্রম্পটটা কপি করে পেস্ট করুন, Enter চাপুন। AI এখন একটা API সার্ভার সাজবে। এই প্রম্পটে HTTP আর JSON-এর অংশ ইংরেজিতে রাখা হয়েছে।

    প্রম্পট
    তুমি একটা research agent-এর API server হিসেবে কাজ করো। শুধু একটা HTTP status line আর একটা JSON body দিয়ে উত্তর দেবে। আর কোনো লেখা নয়।
    নিয়ম:
    - POST /jobs একটা job শুরু করে। সঙ্গে সঙ্গে 202 আর একটা JSON body দিয়ে উত্তর দাও, যাতে job_id আর status "queued" থাকবে। প্রথম job_id হলো job_001। job টা শেষ হতে 245 সেকেন্ড লাগে।
    - GET /jobs/{job_id} status দেয়। status হতে পারে queued, running, done আর failed।
    - আমি প্রতিটা GET request-এ কত সেকেন্ড পার হয়েছে (elapsed) বলব। এই table ব্যবহার করো:
      0 থেকে 59 সেকেন্ড: running, step "1 search sources"
      60 থেকে 179 সেকেন্ড: running, step "2 read 12 sources"
      180 থেকে 244 সেকেন্ড: running, step "3 write the report"
      245 সেকেন্ড বা বেশি: done, আর একটা result field, যাতে একটা ছোট বানানো report title থাকবে
    - running হলে progress-ও percent-এ দেখাও: elapsed ভাগ 245, কাছের পূর্ণ সংখ্যায় গোল করে।
    বুঝলে READY বলো।

    আপনি দেখবেন: AI READY বলে উত্তর দেয়।

  2. ধাপ ২
    একই চ্যাট

    এই রিকোয়েস্টটা কপি করে পেস্ট করুন, Enter চাপুন। এটা জব শুরু করে। রিকোয়েস্টটা ইংরেজিতে থাকবে, কারণ এটা HTTP আর JSON।

    প্রম্পট
    POST /jobs
    {"topic": "Mobile payment use in rural Bangladesh"}

    আপনি দেখবেন: স্ট্যাটাস ২০২ আর একটা job_id দিয়ে তাড়াতাড়ি উত্তর, যেমন job_001। এখনো কোনো রেজাল্ট নেই।

    উদাহরণ উত্তর
    HTTP/1.1 202 Accepted
    {"job_id": "job_001", "status": "queued"}

    আপনার উত্তরের ভাষা একটু আলাদা হবে।

  3. ধাপ ৩
    একই চ্যাট

    এই রিকোয়েস্টটা কপি করে পেস্ট করুন, Enter চাপুন। এটা ৪০ সেকেন্ড পরের স্ট্যাটাস চায়।

    প্রম্পট
    GET /jobs/job_001
    elapsed: 40 seconds

    আপনি দেখবেন: স্ট্যাটাস running, ধাপ ১, আর প্রায় ১৬% প্রোগ্রেস।

    উদাহরণ উত্তর
    HTTP/1.1 200 OK
    {"job_id": "job_001", "status": "running", "step": "1 search sources", "progress": "16%"}

    আপনার উত্তরের ভাষা একটু আলাদা হবে।

  4. ধাপ ৪
    একই চ্যাট

    এই রিকোয়েস্টটা কপি করে পেস্ট করুন, Enter চাপুন। এটা ১২০ সেকেন্ড পরের স্ট্যাটাস চায়।

    প্রম্পট
    GET /jobs/job_001
    elapsed: 120 seconds

    আপনি দেখবেন: স্ট্যাটাস running, ধাপ ২, আর প্রায় ৪৯% প্রোগ্রেস।

    উদাহরণ উত্তর
    HTTP/1.1 200 OK
    {"job_id": "job_001", "status": "running", "step": "2 read 12 sources", "progress": "49%"}

    আপনার উত্তরের ভাষা একটু আলাদা হবে।

  5. ধাপ ৫
    একই চ্যাট

    এই রিকোয়েস্টটা কপি করে পেস্ট করুন, Enter চাপুন। এটা ২৪৫ সেকেন্ড পরের স্ট্যাটাস চায়।

    প্রম্পট
    GET /jobs/job_001
    elapsed: 245 seconds

    আপনি দেখবেন: স্ট্যাটাস done, আর একটা ছোট রিপোর্ট টাইটেল সহ রেজাল্ট।

    উদাহরণ উত্তর
    HTTP/1.1 200 OK
    {"job_id": "job_001", "status": "done", "result": "Mobile Payments in Rural Bangladesh: A Short Report"}

    আপনার উত্তরের ভাষা একটু আলাদা হবে।

এইমাত্র কী হলো

লম্বা কাজ ওয়েব রিকোয়েস্ট খুলে রাখবে না। সার্ভার সঙ্গে সঙ্গে একটা job_id দিয়ে উত্তর দেয়, যেটা অনেকটা টিকেট নম্বরের মতো, আর কাজটা ব্যাকগ্রাউন্ডে করে। ক্লায়েন্ট তখন job_id দিয়ে বারবার জিজ্ঞেস করে। একে বলে পোলিং। এখানে প্রথম উত্তর সঙ্গে সঙ্গে এসেছে, কিন্তু জবটা শেষ হতে ২৪৫ সেকেন্ড লাগে, মানে প্রায় ৪ মিনিট।

কাজ শেষ, যখন আপনার কাছে job_id সহ একটা দ্রুত উত্তর আছে, আর ৩টা পোল, যেগুলোতে running, running আর done দেখা গেছে।

নিজেকে যাচাই করুনপ্রায় ১০ সেকেন্ডের বেশি লাগা কাজে রেজাল্টের বদলে job_id ফেরত দেওয়া উচিত কেন?উত্তর দেখুন

লম্বা কাজে কানেকশন টাইম আউট হতে পারে, আর ইউজার কিছুই দেখে না। job_id থাকলে কাজ ব্যাকগ্রাউন্ডে চলে, আর ক্লায়েন্ট প্রোগ্রেস দেখতে পারে বা পরে ফিরে আসতে পারে।

আরেকটু কঠিন করে দেখুন

একটা নিয়ম যোগ করুন: ১৫০ সেকেন্ড পরে ধাপ ২ ফেইল করে। ১৬০ সেকেন্ডে পোল করুন। সার্ভার কী স্ট্যাটাস আর মেসেজ দেবে, আর ক্লায়েন্ট কি আবার চেষ্টা করবে?

টাস্ক ৩

রিট্রাইয়ের পর দুইবার চার্জ বন্ধ করুন

এটা কেন দরকার

আপনার অ্যাপ যখন প্রতিটা AI রানের জন্য টাকা নেবে, তখন যে ইউজার দুইবার পে বাটন চাপে বা পাতা রিফ্রেশ করে, তাকে দুইবার টাকা দিতে হবে না। একটা লম্বা রান ফেইল করলেও আবার শূন্য থেকে শুরু হবে না।

  1. ধাপ ১
    নতুন চ্যাট

    এই প্রম্পটটা কপি করে পেস্ট করুন, Enter চাপুন। AI এখন একটা বিলিং API সাজবে।

    প্রম্পট
    তুমি report তৈরির একটা API server হিসেবে কাজ করো। প্রতিটা নতুন run-এর খরচ 0.40 USD। আমি যে request পাঠাব, প্রতিটার জন্য শুধু JSON দিয়ে উত্তর দেবে।
    নিয়ম:
    - প্রতিটা request-এ একটা idempotency_key আর একটা body থাকে।
    - নতুন key হলে নতুন run_id সহ নতুন run হয় (run_1, run_2, ...)। charged: 0.40 আর replayed: false দিয়ে উত্তর দাও।
    - একই key আর একই body হলে আগের সংরক্ষিত response আবার দাও, replayed: true আর charged: 0 সহ। নতুন run নয়।
    - একই key কিন্তু আলাদা body হলে error code 422 আর একটা ছোট message দাও।
    বুঝলে READY বলো।

    আপনি দেখবেন: AI READY বলে উত্তর দেয়।

  2. ধাপ ২
    একই চ্যাট

    এই প্রম্পটটা কপি করে পেস্ট করুন, Enter চাপুন। তিনটা রিকোয়েস্টের পর মোট কত টাকা চার্জ হলো, লিখে রাখুন।

    প্রম্পট
    এই তিনটা request ক্রমানুসারে সামলাও। তৃতীয়টার পরে মোট কত USD charge হলো, তার একটা লাইন যোগ করো।
    1. idempotency_key: k-1001, body: {"report": "monthly sales"}
    2. idempotency_key: k-1001, body: {"report": "monthly sales"} (user পেজ refresh করেছে)
    3. idempotency_key: k-1001, body: {"report": "yearly sales"}

    আপনি দেখবেন: তিনটা JSON উত্তর। রিকোয়েস্ট 1-এ চার্জ ০.৪০। রিকোয়েস্ট ২ একটা রিপ্লে, চার্জ ০। রিকোয়েস্ট ৩ একটা এরর ৪২২। মোট ০.৪০ USD।

    উদাহরণ উত্তর
    {"run_id": "run_1", "charged": 0.40, "replayed": false}
    {"run_id": "run_1", "charged": 0, "replayed": true}
    {"error": 422, "message": "Key k-1001 আগেই আলাদা body দিয়ে ব্যবহার হয়েছে।"}
    মোট charge: 0.40 USD

    আপনার উত্তরের ভাষা একটু আলাদা হবে।

  3. ধাপ ৩
    একই চ্যাট

    এই প্রম্পটটা কপি করে পেস্ট করুন, Enter চাপুন। চেকপয়েন্ট থাকলে খরচ কত, আর না থাকলে কত, লিখে রাখুন।

    প্রম্পট
    এখন একটা লম্বা run। run_77-এ ৫টা step আছে। প্রতিটা step-এর খরচ 0.10 USD, আর যে step fail করে তার খরচ নেই। step 1, 2 আর 3 শেষ হয়েছে এবং আগেই charge হয়েছে। server প্রতিটার পর একটা checkpoint সংরক্ষণ করেছে। step 4 একটা network error-এ fail করেছে। client একই idempotency_key দিয়ে আবার চেষ্টা করছে।
    ১. এখন তুমি কোন কোন step চালাবে, আর কত charge করবে?
    ২. checkpoint না থাকলে retry-র খরচ কত হতো?
    ৩. checkpoint-এ অন্তত কী থাকতে হবে, একটা জিনিসের নাম বলো।

    আপনি দেখবেন: চেকপয়েন্ট থাকলে শুধু ধাপ ৪ আর ৫ চলে: ০.২০ USD। চেকপয়েন্ট না থাকলে ৫টা ধাপই চলে: ০.৫০ USD।

    উদাহরণ উত্তর
    ১. শুধু step 4 আর 5 চালাব। step 1 থেকে 3 checkpoint-এ আছে। charge: 2 × 0.10 = 0.20 USD।
    ২. checkpoint না থাকলে ৫টা step-ই আবার চলত: 5 × 0.10 = 0.50 USD।
    ৩. checkpoint-এ থাকতে হবে step 1 থেকে 3-এর সংরক্ষিত result, আর শেষ যে step শেষ হয়েছে তার নম্বর।

    আপনার উত্তরের ভাষা একটু আলাদা হবে।

এইমাত্র কী হলো

আইডেমপোটেন্সি কী হলো একটা অনন্য লেবেল, যেটা ক্লায়েন্ট একটা রিকোয়েস্টে লাগায়। একই রিকোয়েস্ট আবার এলে সার্ভার সংরক্ষিত উত্তরটাই ফেরত দেয়, আর আবার চার্জ করে না। চেকপয়েন্ট হলো এ পর্যন্ত করা কাজের একটা সংরক্ষিত কপি। ফেইল করার পর সার্ভার শুধু বাকি ধাপগুলো চালায়: ৫টার বদলে ২টা ধাপ (০.২০ USD, ০.৫০ USD-এর বদলে)।

কাজ শেষ, যখন তিনটা রিকোয়েস্টের মোট ০.৪০ USD আপনার কাছে আছে, আর রিট্রাইয়ের দুটো খরচ আছে: ০.২০ USD আর ০.৫০ USD।

নিজেকে যাচাই করুনএকজন ইউজার পাতা রিফ্রেশ করল, আর ক্লায়েন্ট একই রিকোয়েস্ট আবার পাঠাল। আইডেমপোটেন্সি কী কীভাবে ইউজারকে বাঁচায়?উত্তর দেখুন

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

আরেকটু কঠিন করে দেখুন

AI-কে জিজ্ঞেস করুন, একই কী দিয়ে দুটো রিকোয়েস্ট যদি ঠিক একই সময়ে আসে, প্রথমটা শেষ হওয়ার আগেই, তাহলে কী হওয়া উচিত।

টাস্ক ৪

ব্যাকআপ প্রোভাইডার চেষ্টা করা একটা গেটওয়ে সাজান

এটা কেন দরকার

আপনি যখন কোনো AI প্রোভাইডারের ওপর প্রোডাক্ট বানাবেন, সেই প্রোভাইডার মাঝে মাঝে ফেইল করবে। গেটওয়ে তখন রিকোয়েস্টটা ব্যাকআপ প্রোভাইডারে পাঠায়, তাই আপনার ইউজার তবুও উত্তর পায়।

  1. ধাপ ১
    নতুন চ্যাট

    এই প্রম্পটটা কপি করে পেস্ট করুন, Enter চাপুন। এটা নরমাল প্রম্পট, যে প্রোভাইডারের টুল আছে তার জন্য।

    প্রম্পট
    তুমি একটা tool ব্যবহার করতে পারো: get_weather(city: string), যেটা live আবহাওয়া দেয়।
    User-এর প্রশ্ন: আজ সিলেটে কি ছাতা লাগবে?
    শুধু JSON আকারে tool call দিয়ে উত্তর দাও, এই form-এ: {"tool": ..., "arguments": {...}}। এখনই প্রশ্নের উত্তর দিয়ো না।

    আপনি দেখবেন: শুধু JSON আকারে একটা টুল কল, কোনো চূড়ান্ত উত্তর নেই। যেমন শহর Sylhet দিয়ে get_weather।

    উদাহরণ উত্তর
    {"tool": "get_weather", "arguments": {"city": "Sylhet"}}

    আপনার উত্তরের ভাষা একটু আলাদা হবে।

  2. ধাপ ২
    নতুন চ্যাট

    এই প্রম্পটটা কপি করে পেস্ট করুন, Enter চাপুন। এটা ডিগ্রেডেড প্রম্পট, যে প্রোভাইডারের কোনো টুল নেই তার জন্য।

    প্রম্পট
    তোমার কোনো tool নেই, আর কোনো live data নেই। শুধু সাধারণ জ্ঞান থেকে উত্তর দাও। পরিষ্কার বলো যে তুমি আজকের আবহাওয়া দেখতে পারছ না, আর যতটা কাজের পরামর্শ দেওয়া যায় দাও।
    User-এর প্রশ্ন: আজ সিলেটে কি ছাতা লাগবে?

    আপনি দেখবেন: একটা সাধারণ উত্তর, যেখানে AI বলে যে সে আজকের আবহাওয়া দেখতে পারছে না, আর একটা কাজের পরামর্শ দেয়।

    উদাহরণ উত্তর
    আমি আজকের আবহাওয়া দেখতে পারছি না, তাই নিশ্চিত করে বলতে পারব না। সিলেট বাংলাদেশের সবচেয়ে বেশি বৃষ্টির জায়গাগুলোর একটা, বিশেষ করে বর্ষায়, তাই একটা ছোট ছাতা সঙ্গে রাখা নিরাপদ। বের হওয়ার আগে একটা আবহাওয়ার app দেখে নিয়ো।

    আপনার উত্তরের ভাষা একটু আলাদা হবে।

  3. ধাপ ৩
    নতুন চ্যাট

    এই প্রম্পটটা কপি করে পেস্ট করুন, Enter চাপুন। AI এখন একটা গেটওয়ে সাজবে। টেবিলের প্রতিটা রো নিয়মের সঙ্গে মিলিয়ে দেখুন।

    প্রম্পট
    তুমি একটা LLM gateway হিসেবে কাজ করো। fallback chain হলো: Provider 1 (tool আছে), তারপর Provider 2 (tool আছে), তারপর Provider 3 (tool নেই, তাই একটা degraded prompt ব্যবহার করো, যেটা বলে: তোমার কোনো tool নেই, সাধারণ জ্ঞান থেকে উত্তর দাও)।
    নিয়ম: 503 বা 429 error এলে পরের provider-এ যাও। সফল হলে থামো। কোন provider উত্তর দিল, কতবার চেষ্টা হলো, আর খরচ কত, লিখে রাখো।
    প্রতি call-এর খরচ: Provider 1 0.010 USD, Provider 2 0.006 USD, Provider 3 0.002 USD। fail হওয়া call-এর খরচ 0।
    তিনটা request এসেছে:
    Request X: Provider 1 দেয় 200।
    Request Y: Provider 1 দেয় 503, Provider 2 দেয় 200।
    Request Z: Provider 1 দেয় 503, Provider 2 দেয় 429, Provider 3 দেয় 200।
    একটা table দাও, যাতে থাকবে: request, ব্যবহার হওয়া provider, attempts, ব্যবহার হওয়া prompt (normal বা degraded), খরচ। তারপর মোট খরচ যোগ করো।

    আপনি দেখবেন: একটা টেবিল, যেখানে X প্রোভাইডার ১ ব্যবহার করে, Y প্রোভাইডার ২, আর Z ডিগ্রেডেড প্রম্পট সহ প্রোভাইডার ৩। মোট খরচ ০.০১৮ USD।

    উদাহরণ উত্তর
    | Request | Provider | Attempts | Prompt | খরচ (USD) |
    | X | Provider 1 | 1 | normal | 0.010 |
    | Y | Provider 2 | 2 | normal | 0.006 |
    | Z | Provider 3 | 3 | degraded | 0.002 |
    মোট খরচ: 0.010 + 0.006 + 0.002 = 0.018 USD

    আপনার উত্তরের ভাষা একটু আলাদা হবে।

এইমাত্র কী হলো

একটা প্রোভাইডার নানা এরর দিয়ে ফেইল করতে পারে, যেমন ৫০৩ (সার্ভার তৈরি নেই) বা ৪২৯ (অনেক বেশি রিকোয়েস্ট)। আবার কোনো প্রোভাইডারে একটা ফিচার হয়তো থাকে না, যেমন টুল। গেটওয়ে ঠিক করা ক্রমে পরের প্রোভাইডার চেষ্টা করে। টুল নেই এমন প্রোভাইডারের জন্য সে একটা ডিগ্রেডেড প্রম্পট ব্যবহার করে, যেটা সহজ, কিন্তু তবুও কাজের। এখানে ফেইল হওয়া কলের খরচ নেই, তাই প্রতিটা রিকোয়েস্ট শুধু যে প্রোভাইডার উত্তর দিয়েছে তার খরচ দেয়।

কাজ শেষ, যখন আপনার কাছে একটা টুল কল, টুল ছাড়া একটা সৎ উত্তর, আর মোট ০.০১৮ USD সহ একটা গেটওয়ে টেবিল আছে।

নিজেকে যাচাই করুনযে প্রোভাইডারে টুল ইউজ নেই, ফলব্যাক চেইন তার জন্য আলাদা প্রম্পট ব্যবহার করে কেন?উত্তর দেখুন

টুল ব্যবহার করতে না পারা প্রোভাইডার নরমাল প্রম্পটে ফেইল করত। আপনার tool নেই, তবুও উত্তর দিন ধরনের ডিগ্রেডেড প্রম্পট উত্তরটাকে কাজের রাখে।

আরেকটু কঠিন করে দেখুন

একটা নিয়ম যোগ করুন: ইউজার ফ্রি প্ল্যানে থাকলে প্রোভাইডার ১ বাদ দিন। তারপর জিজ্ঞেস করুন, একটা ফিচার ফ্ল্যাগ দিয়ে কীভাবে প্রথমে ১০ শতাংশ ইউজারের জন্য এই নিয়ম চালু করা যায়।

ভিডিও দেখুন · ৬টি

কুইজ

কী শিখলেন যাচাই করুন। ৫টি প্রশ্ন।

১. একটা টাস্ক প্রায় ১০ সেকেন্ডের বেশি সময় নেয়। এই পার্ট অনুযায়ী কী করা উচিত?

২. কোন স্ট্রিমিং ট্রান্সপোর্ট সবচেয়ে সহজ, একমুখী (সার্ভার থেকে ক্লায়েন্ট) আর যেকোনো HTTP প্রক্সির মধ্য দিয়ে কাজ করে?

৩. মাল্টি-টেন্যান্ট অ্যাপের ক্ষেত্রে টপিক বলে, প্রতিটি টেন্যান্টের প্রম্পট তার নিজের কোডবেসে হার্ড-কোড করতে হবে।

৪. এই পার্ট অনুযায়ী মডেল গেটওয়ে মূলত কী?

৫. একটা AI API-তে ক্লায়েন্ট যেন রিকোয়েস্টের মধ্যেই খরচ আর ল্যাটেন্সি বাজেট দিতে পারে, যেমন $০.০৫ আর ৮s।

মেলাতে সব প্রশ্নের উত্তর দিন।

তথ্যসূত্র

সোর্স

সব সাইটেশন মূল পেপার (arXiv), ভেন্ডরের ডক্স (OpenAI, Anthropic, Google) বা অফিশিয়াল টিম ব্লগে যায়। প্রতিটি পাতা খুলে সাইটেশনের তথ্য যাচাই করা হয়েছে।

  1. [1]Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models" (ICLR 2023)
  2. [2]Wei et al., "Plan-and-Execute Agents" / "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" — NeurIPS 2022
  3. [3]Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning" — NeurIPS 2023
  4. [4]Xu et al., "ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models"
  5. [5]Anthropic Engineering blog — "How we built our multi-agent research system" (2025)
  6. [6]LangGraph — official documentation (LangChain)
  7. [7]Temporal — "Durable Execution for LLM Agents"
  8. [8]Park et al., "Generative Agents: Interactive Simulacra of Human Behavior" — 2023
  9. [9]Anthropic — "Introducing computer use, a new Claude 3.5 Sonnet capability" (Oct 2024)
  10. [10]Anthropic — Tool use / function calling documentation
  11. [11]OpenAI — Function calling guide
  12. [12]Anthropic — Model Context Protocol (MCP) specification
  13. [13]Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention" — vLLM paper, SOSP 2023
  14. [14]Zheng et al., "SGLang: Efficient Execution of Structured Language Model Programs" — 2023
  15. [15]llama.cpp — open-source GGUF-native inference (ggerganov)
  16. [16]Lin et al., "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration" — MLSys 2024
  17. [17]Anthropic — Prompt caching documentation
  18. [18]Zheng et al., "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" — NeurIPS 2023
  19. [19]Es et al., "Ragas: Automated Evaluation of Information Retrieval Augmented Language Models" — 2023
  20. [20]Yue et al., "Large Language Model Cascades with Mixture of Thought Representations" — 2024
  21. [21]GPTCache — open-source semantic cache
  22. [22]Guo et al., "DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via RL" — 2025
  23. [23]Jiang et al., "LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models" — EMNLP 2023
  24. [24]LiteLLM — unified interface for 100+ LLMs
  25. [25]OWASP — "Top 10 for LLM Applications" (LLM01 Prompt Injection, 2025)
  26. [26]Bai et al., "Constitutional AI: Harmlessness from AI Feedback" — Anthropic, 2022
  27. [27]NVIDIA NeMo Guardrails — open-source toolkit
  28. [28]Qwen2-VL Team, "Qwen2-VL: Enhancing Vision-Language Model's Perception of the World at Any Resolution" — 2024
  29. [29]OpenAI — Realtime API documentation
  30. [30]OpenAI — Production best practices guide