মূল লেখায় যাও
AI Engineering
English

Part ১৩

AI Application-এর Architecture

SSE / WebSocket / chunked HTTP-তে streaming, লম্বা agent run-এর জন্য background job আর queue, idempotency আর resumability, multi-tenant prompt আর key management, বিভিন্ন provider জুড়ে fallback chain, prompt আর model-এর জন্য feature flag, আর AI feature-এর API design pattern (cancel, retry, partial result)। প্রতিটি section দুই ভাবে লেখা: engineer-এর জন্য technical version (code আর diagram সহ), আর সাধারণ পাঠকের জন্য সহজ ভাষায় ব্যাখ্যা (উপমা সহ)। প্রতিটি topic-এর শেষে বাংলা ব্যাখ্যাও আছে।

১টি section · ৩০টি source · তিনভাবে ব্যাখ্যা

01

AI application-এর architecture

একটা LLM call আসলে শুধু একটা HTTP request। এর চারপাশে একটা product বানাতে আধুনিক যেকোনো app-এর মতো একই কাঠামো লাগে, সঙ্গে কয়েকটা নতুন জিনিস: streaming, resumability, multi-tenancy, fallback, feature flag, আর partial result-এর জন্য বানানো API।

অনুশীলন · ৪টি task

যেকোনো free AI chat খোলো: ChatGPT · Claude · Gemini

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

Task ১

stream হওয়া উত্তরের প্রথম শব্দের সময় মাপো

এটা কেন দরকার

তুমি যখন chat feature বানাবে, স্ক্রিন অনেক সেকেন্ড খালি থাকলে user চলে যায়। streaming model যেমন যেমন লেখে, তেমন তেমন শব্দ দেখায়, তাই app দ্রুত মনে হয়।

  1. ধাপ ১
    নতুন chat

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

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

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

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

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

  2. ধাপ ২
    একই chat

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

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

  3. ধাপ ৩
    নতুন chat

    prompt পাঠানোর আগে তিনটা feature পড়ো। তারপর paste করে Enter চাপো।

    Prompt
    এই তিনটার প্রতিটা এক সহজ বাক্যে বুঝিয়ে বলো: 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-এর একটা খরচ বা অসুবিধা বলো।

    তুমি দেখবে: Feature ১-এর জন্য SSE, Feature ২-এর জন্য WebSockets, আর Feature ৩-এর জন্য HTTP chunked। WebSockets-এর খরচ হলো ভারী setup।

    Example উত্তর
    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) আর চালাতে বেশি কাজ।

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

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

model token (শব্দের ছোট টুকরো) একটা একটা করে লেখে। streaming থাকলে app প্রতিটা token সঙ্গে সঙ্গে দেখায়। মোট সময় বদলায় না, কিন্তু user প্রায় এক সেকেন্ড পরে প্রথম শব্দ দেখে আর পড়া শুরু করে। SSE stream করার সবচেয়ে সহজ উপায়, কারণ data শুধু এক দিকে যায়, server থেকে browser-এ।

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

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

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

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

Task ২

লম্বা job চালানো একটা server সাজো

এটা কেন দরকার

তুমি যখন ৪ মিনিট ধরে কাজ করা একটা AI agent বানাবে, তখন web request খুলে রাখা যাবে না। অনেক server এত লম্বা অপেক্ষার request কেটে দেয়, আর user কিছুই দেখে না।

  1. ধাপ ১
    নতুন chat

    এই prompt টা copy করে paste করো, Enter চাপো। AI এখন একটা API server সাজবে। এই prompt-এ HTTP আর JSON-এর অংশ English-এ রাখা হয়েছে।

    Prompt
    তুমি একটা 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. ধাপ ২
    একই chat

    এই request টা copy করে paste করো, Enter চাপো। এটা job শুরু করে। request টা English-এ থাকবে, কারণ এটা HTTP আর JSON।

    Prompt
    POST /jobs
    {"topic": "Mobile payment use in rural Bangladesh"}

    তুমি দেখবে: status 202 আর একটা job_id দিয়ে তাড়াতাড়ি উত্তর, যেমন job_001। এখনো কোনো result নেই।

    Example উত্তর
    HTTP/1.1 202 Accepted
    {"job_id": "job_001", "status": "queued"}

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

  3. ধাপ ৩
    একই chat

    এই request টা copy করে paste করো, Enter চাপো। এটা ৪০ সেকেন্ড পরের status চায়।

    Prompt
    GET /jobs/job_001
    elapsed: 40 seconds

    তুমি দেখবে: status running, step 1, আর প্রায় 16% progress।

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

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

  4. ধাপ ৪
    একই chat

    এই request টা copy করে paste করো, Enter চাপো। এটা ১২০ সেকেন্ড পরের status চায়।

    Prompt
    GET /jobs/job_001
    elapsed: 120 seconds

    তুমি দেখবে: status running, step 2, আর প্রায় 49% progress।

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

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

  5. ধাপ ৫
    একই chat

    এই request টা copy করে paste করো, Enter চাপো। এটা ২৪৫ সেকেন্ড পরের status চায়।

    Prompt
    GET /jobs/job_001
    elapsed: 245 seconds

    তুমি দেখবে: status done, আর একটা ছোট report title সহ result।

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

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

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

লম্বা কাজ web request খুলে রাখবে না। server সঙ্গে সঙ্গে একটা job_id দিয়ে উত্তর দেয়, যেটা অনেকটা টিকিট নম্বরের মতো, আর কাজটা background-এ করে। client তখন job_id দিয়ে বারবার জিজ্ঞেস করে। একে বলে polling। এখানে প্রথম উত্তর সঙ্গে সঙ্গে এসেছে, কিন্তু job টা শেষ হতে ২৪৫ সেকেন্ড লাগে, মানে প্রায় ৪ মিনিট।

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

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

লম্বা কাজে connection time out হতে পারে, আর user কিছুই দেখে না। job_id থাকলে কাজ background-এ চলে, আর client progress দেখতে পারে বা পরে ফিরে আসতে পারে।

আরেকটু কঠিন করে দেখোএকটা নিয়ম যোগ করো: ১৫০ সেকেন্ড পরে step 2 fail করে। ১৬০ সেকেন্ডে poll করো। server কী status আর message দেবে, আর client কি আবার চেষ্টা করবে?

Task ৩

retry-র পর দুইবার charge বন্ধ করো

এটা কেন দরকার

তোমার app যখন প্রতিটা AI run-এর জন্য টাকা নেবে, তখন যে user দুইবার Pay চাপে বা পেজ refresh করে, তাকে দুইবার টাকা দিতে হবে না। একটা লম্বা run fail করলেও আবার শূন্য থেকে শুরু হবে না।

  1. ধাপ ১
    নতুন chat

    এই prompt টা copy করে paste করো, Enter চাপো। AI এখন একটা billing API সাজবে।

    Prompt
    তুমি 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. ধাপ ২
    একই chat

    এই prompt টা copy করে paste করো, Enter চাপো। তিনটা request-এর পর মোট কত টাকা charge হলো, লিখে রাখো।

    Prompt
    এই তিনটা 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 উত্তর। request 1-এ charge 0.40। request 2 একটা replay, charge 0। request 3 একটা error 422। মোট 0.40 USD।

    Example উত্তর
    {"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. ধাপ ৩
    একই chat

    এই prompt টা copy করে paste করো, Enter চাপো। checkpoint থাকলে খরচ কত, আর না থাকলে কত, লিখে রাখো।

    Prompt
    এখন একটা লম্বা 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-এ অন্তত কী থাকতে হবে, একটা জিনিসের নাম বলো।

    তুমি দেখবে: checkpoint থাকলে শুধু step 4 আর 5 চলে: 0.20 USD। checkpoint না থাকলে ৫টা step-ই চলে: 0.50 USD।

    Example উত্তর
    ১. শুধু 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 শেষ হয়েছে তার নম্বর।

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

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

idempotency key হলো একটা অনন্য label, যেটা client একটা request-এ লাগায়। একই request আবার এলে server সংরক্ষিত উত্তরটাই ফেরত দেয়, আর আবার charge করে না। checkpoint হলো এ পর্যন্ত করা কাজের একটা সংরক্ষিত copy। fail করার পর server শুধু বাকি step গুলো চালায়: ৫টার বদলে ২টা step (0.20 USD, 0.50 USD-এর বদলে)।

কাজ শেষ, যখন তিনটা request-এর মোট 0.40 USD তোমার কাছে আছে, আর retry-র দুটো খরচ আছে: 0.20 USD আর 0.50 USD।

নিজেকে যাচাই করোএকজন user পেজ refresh করল, আর client একই request আবার পাঠাল। idempotency key কীভাবে user-কে বাঁচায়?উত্তর দেখো

server key-র নামে response সংরক্ষণ করে রাখে। একই key দিয়ে দ্বিতীয় request এলে একই response যায়, নতুন run হয় না, আর নতুন charge হয় না।

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

Task ৪

backup provider চেষ্টা করা একটা gateway সাজো

এটা কেন দরকার

তুমি যখন কোনো AI provider-এর ওপর product বানাবে, সেই provider মাঝে মাঝে fail করবে। gateway তখন request টা backup provider-এ পাঠায়, তাই তোমার user তবুও উত্তর পায়।

  1. ধাপ ১
    নতুন chat

    এই prompt টা copy করে paste করো, Enter চাপো। এটা normal prompt, যে provider-এর tool আছে তার জন্য।

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

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

    Example উত্তর
    {"tool": "get_weather", "arguments": {"city": "Sylhet"}}

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

  2. ধাপ ২
    নতুন chat

    এই prompt টা copy করে paste করো, Enter চাপো। এটা degraded prompt, যে provider-এর কোনো tool নেই তার জন্য।

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

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

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

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

  3. ধাপ ৩
    নতুন chat

    এই prompt টা copy করে paste করো, Enter চাপো। AI এখন একটা gateway সাজবে। table-এর প্রতিটা row নিয়মের সঙ্গে মিলিয়ে দেখো।

    Prompt
    তুমি একটা 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), খরচ। তারপর মোট খরচ যোগ করো।

    তুমি দেখবে: একটা table, যেখানে X Provider 1 ব্যবহার করে, Y Provider 2, আর Z degraded prompt সহ Provider 3। মোট খরচ 0.018 USD।

    Example উত্তর
    | 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

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

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

একটা provider নানা error দিয়ে fail করতে পারে, যেমন 503 (server তৈরি নেই) বা 429 (অনেক বেশি request)। আবার কোনো provider-এ একটা feature নাও থাকতে পারে, যেমন tool। gateway ঠিক করা ক্রমে পরের provider চেষ্টা করে। tool নেই এমন provider-এর জন্য সে একটা degraded prompt ব্যবহার করে, যেটা সহজ, কিন্তু তবুও কাজের। এখানে fail হওয়া call-এর খরচ নেই, তাই প্রতিটা request শুধু যে provider উত্তর দিয়েছে তার খরচ দেয়।

কাজ শেষ, যখন তোমার কাছে একটা tool call, tool ছাড়া একটা সৎ উত্তর, আর মোট 0.018 USD সহ একটা gateway table আছে।

নিজেকে যাচাই করোযে provider-এ tool use নেই, fallback chain তার জন্য আলাদা prompt ব্যবহার করে কেন?উত্তর দেখো

tool ব্যবহার করতে না পারা provider normal prompt-এ fail করত। তোমার tool নেই, তবুও উত্তর দাও ধরনের degraded prompt উত্তরটাকে কাজের রাখে।

আরেকটু কঠিন করে দেখোএকটা নিয়ম যোগ করো: user free plan-এ থাকলে Provider 1 বাদ দাও। তারপর জিজ্ঞেস করো, একটা feature flag দিয়ে কীভাবে প্রথমে ১০ শতাংশ user-এর জন্য এই নিয়ম চালু করা যায়।

ভিডিও দেখো · ৬টি

তথ্যসূত্র

Sources

সব citation মূল paper (arXiv), vendor-এর docs (OpenAI, Anthropic, Google) বা official team blog-এ যায়। প্রতিটি পাতা খুলে citation-এর তথ্য যাচাই করা হয়েছে।

  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