Part ০৮
LLMOps আর Observability
Langfuse / LangSmith / Helicone / Arize Phoenix / Braintrust দিয়ে tracing; প্রতিটা request-এর token, খরচ আর latency মাপা; prompt আর agent-এর versioning; A/B testing; replay করে debug করা; model upgrade-এ চুপচাপ আচরণ বদলে গেলে সেই drift ধরা; আর feedback loop, যা আপনার eval dataset বড় করে। প্রতিটি section দুই ভাবে লেখা: engineer-এর জন্য technical version (code আর diagram সহ), আর সাধারণ পাঠকের জন্য সহজ ভাষায় ব্যাখ্যা (উপমা সহ)। প্রতিটি topic-এর শেষে বাংলা ব্যাখ্যাও আছে।
১টি section · ৩০টি source · তিনভাবে ব্যাখ্যা
01
LLMOps আর observability
পুরোনো DevOps জিজ্ঞেস করে, "request কি 200 ফেরত দিয়েছে?" LLM app-এ আরও গভীর প্রশ্ন লাগে: model কি সঠিক উত্তর দিয়েছে, ঠিক খরচে, ঠিক সুরে, কোনো তথ্য ফাঁস না করে? এই প্রশ্নগুলোর উত্তর খোঁজার কাজকে বলে LLMOps, আর এর নিজস্ব toolchain আছে।
অনুশীলন · ৪টি 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 ১
Flat log থেকে trace বানাও
এটা কেন দরকার
কোনো user যখন বলে "তোমার chatbot খারাপ উত্তর দিয়েছে", তখন একসারি flat log পড়া কঠিন। Trace প্রতিটা ধাপ আর তার সময় দেখায়, তাই ভাঙা ধাপটা তাড়াতাড়ি খুঁজে পাওয়া যায়।
ধাপ ১
নতুন chatএই prompt-এর log দেখো। আন্দাজ করো কোন ধাপে সবচেয়ে বেশি সময় লেগেছে। তারপর prompt টা copy করো, paste করে Enter চাপো।
Prompt এখানে একটা agent run-এর flat log আছে (বানানো data)। Span হলো run-এর একটা ধাপ, যার একটা শুরু আর একটা শেষ আছে। 10:02:11.000 REQUEST_START POST /chat user=u_204 prompt_id=support-v7 10:02:11.020 SPAN_START build_system_prompt 10:02:11.040 SPAN_END build_system_prompt 10:02:11.040 SPAN_START llm_call_1 model=model-x 10:02:12.440 SPAN_END llm_call_1 in_tokens=1200 out_tokens=60 decision="call tool search_orders" 10:02:12.440 SPAN_START tool_search_orders args={"customer":"u_204"} 10:02:16.940 SPAN_END tool_search_orders status=timeout 10:02:16.940 SPAN_START llm_call_2 model=model-x 10:02:18.140 SPAN_END llm_call_2 in_tokens=1350 out_tokens=80 10:02:18.150 REQUEST_END status=200 answer="Sorry, I could not check your order right now." কাজ: 1. এই run-টাকে trace হিসেবে আঁকো: span-এর একটা tree, indentation দিয়ে। প্রতিটা span-এর সময় সেকেন্ডে দেখাও। 2. সবচেয়ে ধীর span-এর নাম বলো, আর মোট সময়ের কত ভাগ সেটা নিয়েছে বলো। 3. আসল সমস্যা কোন span-এ শুরু হয়েছে, বলো।তুমি দেখবে: একটা tree, উপরে request আর নিচে চারটা ধাপ। সবচেয়ে ধীর span হলো
tool_search_orders, প্রায় 4.5 s, যা মোট 7.15 s-এর প্রায় 63%। সমস্যা ওখানেই শুরু (timeout)।Example উত্তর
REQUEST POST /chat (7.15 s) build_system_prompt (0.02 s) llm_call_1 (1.4 s) tool_search_orders (4.5 s) status=timeout llm_call_2 (1.2 s) সবচেয়ে ধীর span: tool_search_orders, 4.5 s, 7.15 s-এর প্রায় 63%। আসল সমস্যা শুরু হয়েছে tool_search_orders-এ, যেটা timeout হয়েছে।
তোমার উত্তরের ভাষা একটু আলাদা হবে।
ধাপ ২
একই chatএকটা সময় নিজে হাতে মিলিয়ে দেখো: tool span-এর শেষের সময় (16.940) থেকে শুরুর সময় (12.440) বিয়োগ করো।
তুমি দেখবে: 4.5 সেকেন্ড। এটা model-এর tree-র সাথে মেলে।
ধাপ ৩
একই chatএই prompt টা copy করো, একই chat-এ paste করে Enter চাপো। 200 status নিয়ে model কী বলে, পড়ো।
Prompt Request-টা status 200 ফেরত দিয়েছে। পুরনো ধরনের DevOps dashboard এটার জন্য সবুজ দেখায়। ৩টা ছোট বাক্যে বলো, শুধু 200 দেখলে এই run-এর কোন জিনিসটা ধরা পড়ে না। তারপর trace-এ কোন ৪টা field রাখা উচিত তার list দাও, যাতে পরে এই failure খুঁজে পাওয়া যায়।
তুমি দেখবে: Model বলবে 200 শুধু বোঝায় server সাড়া দিয়েছে। উত্তরটা তবুও user-এর কোনো কাজে লাগেনি। সে prompt version, model, token সংখ্যা, cost, latency আর tool status-এর মতো field-এর list দেবে।
Example উত্তর
200 শুধু বলে server সাড়া দিয়েছে। উত্তর ভালো ছিল কি না, সেটা বলে না। এখানে tool timeout হয়েছে, তাই user পেয়েছে "Sorry, I could not check your order"। Dashboard সবুজই থাকে, অথচ user ব্যর্থ হয়। Field: prompt_id, model-এর নাম, token সংখ্যা ও cost, tool status ও latency।
তোমার উত্তরের ভাষা একটু আলাদা হবে।
এইমাত্র কী হলো
Trace হলো span-এর একটা tree। Span হলো একটা ধাপ, যেমন LLM call বা tool call, তার সময়সহ। Tree দেখাচ্ছে tool call মোট সময়ের 63% নিয়েছে আর fail করেছে। Server তবুও 200 ফেরত দিয়েছে, তাই শুধু status দেখলে কিছু ধরা পড়ত না। LLM app-এ উত্তর কোথায় ভেঙেছে দেখতে trace লাগে।
কাজ শেষ, যখন তোমার কাছে ৪ ধাপের একটা span tree আছে, তুমি সবচেয়ে ধীর ধাপটা (4.5 s) জানো, আর log-এ রাখার ৪টা field-এর list আছে।
নিজেকে যাচাই করোStatus 200 দেখেই এই request-কে সুস্থ বলা যায় না কেন?উত্তর দেখো
Server সাড়া দিয়েছে, কিন্তু tool timeout হওয়ায় user-এর জন্য উত্তরটা ভুল ছিল। LLMOps জানতে চায় উত্তরটা ঠিক ছিল কি না। Span-এর trace দেখায় কোথায় ভেঙেছে।
Task ২
কোন feature লোকসানে চলছে, খুঁজে বের করো
এটা কেন দরকার
তোমার app-এ কয়েকটা AI feature থাকলে মাসের bill একটাই বড় সংখ্যা। কোন feature আয়ের চেয়ে বেশি খরচ করছে, সেটা না জানলে তুমি তা ঠিক করতে পারবে না।
ধাপ ১
নতুন chatএই prompt-এর ৬টা log সারি দেখো। আন্দাজ করো কোন feature লোকসানে। তারপর prompt টা copy করো, paste করে Enter চাপো।
Prompt এখানে log করা কয়েকটা LLM request আছে (বানানো data)। প্রতি 1 million token-এর দাম: small model = input 0.20 USD আর output 0.80 USD। Large model = input 3.00 USD আর output 15.00 USD। id | feature | user | model | in_tokens | out_tokens | latency_s 1 | autocomplete | u1 | small | 300 | 20 | 0.4 2 | autocomplete | u2 | small | 280 | 25 | 0.5 3 | autocomplete | u1 | small | 310 | 18 | 0.4 4 | report_writer | u3 | large | 12000 | 1500 | 14.2 5 | report_writer | u4 | large | 9000 | 1200 | 11.8 6 | report_writer | u3 | large | 15000 | 2000 | 18.5 আয়: প্রতিটা autocomplete request 0.001 USD আয় করে। প্রতিটা report_writer request 0.04 USD আয় করে। কাজ: 1. প্রতিটা request-এর cost USD-তে বের করো। Formula একবার দেখাও, তারপর একটা table দাও। 2. প্রতিটা feature-এর cost আর আয় যোগ করো। 3. কোন feature লোকসানে আছে আর গড়ে প্রতি request-এ কত লোকসান, বলো।
তুমি দেখবে: Autocomplete-এর খরচ এক পয়সার ভগ্নাংশ, আর সেটা লাভে। report_writer লোকসানে: তার গড় cost প্রতি request-এ প্রায় 0.0595 USD, কিন্তু আয় 0.04 USD। গড় লোকসান প্রায় 0.0195 USD।
Example উত্তর
Cost = in_tokens × in_price ÷ 1,000,000 + out_tokens × out_price ÷ 1,000,000 1: 0.000076 2: 0.000076 3: 0.0000764 4: 0.0585 5: 0.045 6: 0.075 autocomplete: cost প্রায় 0.00023 USD, আয় 0.003 USD। লাভ। report_writer: cost 0.1785 USD, আয় 0.12 USD। লোকসান 0.0585 USD, প্রতি request-এ প্রায় 0.0195 USD। report_writer লোকসানে চলছে।
তোমার উত্তরের ভাষা একটু আলাদা হবে।
ধাপ ২
একই chatCalculator দিয়ে 4 নম্বর request নিজে হাতে মিলাও: 12,000 × 3 ÷ 1,000,000, সাথে 1,500 × 15 ÷ 1,000,000।
তুমি দেখবে: 0.036 + 0.0225 = 0.0585 USD। এটা table-এর সাথে মেলে, আর এই request-এর আয় 0.04 USD-এর চেয়ে বেশি।
ধাপ ৩
একই chatএই prompt টা copy করো, একই chat-এ paste করে Enter চাপো। নতুন cost আর সতর্কবার্তাটা পড়ো।
Prompt এবার ধরো আমরা report_writer-কে small model-এ নিয়ে যাচ্ছি। 4, 5 আর 6 নম্বর request-এ একই token সংখ্যা ধরো। প্রতি request-এর নতুন গড় cost কত? Production-এ এই বদল করার আগে আমাদের কী মেপে দেখতে হবে? 100 শব্দের কম লিখে উত্তর দাও।
তুমি দেখবে: প্রতি request-এ নতুন গড় cost প্রায় 0.0037 USD। ভালো উত্তরে এটাও থাকবে যে আগে উত্তরের মান যাচাই করতে হবে, যেমন eval দিয়ে (যে test উত্তরের নম্বর দেয়)।
Example উত্তর
Small model-এ গড় cost প্রতি request-এ প্রায় 0.0037 USD (4, 5, 6 নম্বর request-এ 0.0036, 0.0028 আর 0.0046)। এটা 0.04 USD আয়ের অনেক নিচে। বদলের আগে আসল report request-এ eval দিয়ে উত্তরের মান মাপো। সস্তা model খারাপ report লিখতে পারে, তাই user feedback আর latency-ও দেখো।
তোমার উত্তরের ভাষা একটু আলাদা হবে।
এইমাত্র কী হলো
প্রতিটা request-এ input token আর output token থাকে। Model-এর দাম দিয়ে গুণ করলে সেই request-এর cost পাওয়া যায়। Log-এ tag (লেবেল) থাকলে, যেমন feature আর model, তুমি feature ধরে cost ভাগ করতে পারো। Feature tag না থাকলে "কোন feature লোকসানে?" প্রশ্নের উত্তর দেওয়া যেত না। সস্তা model cost কমায়, কিন্তু মানও যাচাই করতে হয়।
কাজ শেষ, যখন তোমার কাছে ৬টা request-এর প্রত্যেকটার cost আছে, কোন feature লোকসানে তুমি জানো, আর 4 নম্বর request তুমি হাতে মিলিয়েছ।
নিজেকে যাচাই করো"এই feature কি লোকসানে?" প্রশ্নের উত্তর দিতে log-এর কোন field লাগে?উত্তর দেখো
Input token, output token আর model থেকে vendor-এর দাম দিয়ে cost পাওয়া যায়। Feature tag request-গুলোকে ভাগ করে। এই field না থাকলে data দিয়ে প্রশ্নটার উত্তর দেওয়া যায় না।
Task ৩
A/B test কখন থামাবে, ঠিক করো
এটা কেন দরকার
তুমি যখন production-এ নতুন prompt test করবে, শুরুর একটা ভালো result লোভ দেখায়। খুব তাড়াতাড়ি ship করলে তুমি এমন prompt-এর জন্য বেশি টাকা দিতে পারো, যা আসলে ভালো না।
ধাপ ১
নতুন chatএই prompt-এর সংখ্যাগুলো পড়ো। ঠিক করো: ১ম দিনের পরই v8 ship করবে, না ৭ম দিন পর্যন্ত অপেক্ষা করবে? কারণ লিখে রাখো। তারপর prompt টা copy করো, paste করে Enter চাপো।
Prompt আমরা production-এ আমাদের support-bot-এর prompt-এর দুটো version test করছি (বানানো data)। Traffic ভাগ করা হয়েছে user_id-র hash দিয়ে। Version support-v7 হলো এখনকার prompt। Version support-v8 একটা নতুন, লম্বা prompt। ১ম দিনের বিকেল পর: - v7: 60টা rate করা উত্তরের মধ্যে 40টা thumbs-up - v8: 60টা rate করা উত্তরের মধ্যে 45টা thumbs-up ৭ম দিন পর: - v7: 420টা rate করা উত্তরের মধ্যে 290টা thumbs-up, প্রতি উত্তরে গড় cost 0.8 cent, গড় latency 2.1 s - v8: 420টা rate করা উত্তরের মধ্যে 292টা thumbs-up, প্রতি উত্তরে গড় cost 1.1 cent, গড় latency 3.3 s কাজ: 1. ১ম দিনে আর ৭ম দিনে প্রতিটা version-এর thumbs-up হার বের করো। 2. ১ম দিনের পর কি আমাদের থেমে v8 ship করা উচিত? কেন বা কেন নয়? 3. ৭ম দিনে আমাদের কী করা উচিত? 4. Test শুরুর আগে আমাদের কোন metric বেছে নেওয়া উচিত ছিল? ছোট আর সরাসরি উত্তর দাও।
তুমি দেখবে: ১ম দিন: v7 66.7%, v8 75.0%। ৭ম দিন: v7 69.0%, v8 69.5%। শুরুর ব্যবধান প্রায় মিলিয়ে গেছে। ৭ম দিনে v8-এর মান প্রায় সমান, কিন্তু cost বেশি আর ধীর। বেশিরভাগ model বলবে v7 রাখো।
Example উত্তর
1. ১ম দিন: v7 40/60 = 66.7%, v8 45/60 = 75.0%। ৭ম দিন: v7 290/420 = 69.0%, v8 292/420 = 69.5%। 2. না। প্রতি version-এ মাত্র 60টা rating নিয়ে একটা বিকেল অনেক কম data। Chance-এর কারণে v8 ভালো দেখাতে পারে। 3. v7 রাখো। v8-এর মান প্রায় একই, কিন্তু তার cost 0.8 cent-এর বদলে 1.1 cent আর সে ধীর (2.1 s-এর বদলে 3.3 s)। 4. Test শুরুর আগেই মূল metric, cost-এর সীমা, latency-র সীমা আর test কত দিন চলবে, ঠিক করা উচিত ছিল।
তোমার উত্তরের ভাষা একটু আলাদা হবে।
ধাপ ২
একই chatএই prompt টা copy করো, একই chat-এ paste করে Enter চাপো। পড়ো, ভাগ করতে user_id-র hash কেন ব্যবহার করা হয়।
Prompt আমরা user_id-র hash দিয়ে traffic ভাগ করি (একটা স্থির নিয়ম, যা প্রতিটা user-কে সবসময় একই version-এ পাঠায়)। আমরা এটা করি কেন, প্রতিটা message-এ random বাছি না কেন? আর প্রতিটা trace-এ support-v8-এর মতো prompt version ID রাখা উচিত কেন? ৪টা ছোট বাক্যে উত্তর দাও।
তুমি দেখবে: চারটা ছোট বাক্য। Hash প্রতিটা user-কে একটা version-এই রাখে, তাই user দুটো আলাদা bot দেখে না। প্রতিটা trace-এ version ID থাকলে বোঝা যায় কোন prompt কোন উত্তর বানিয়েছে।
Example উত্তর
Hash প্রতিটা user-কে সবসময় একই version-এ পাঠায়। প্রতি message-এ random বাছলে এক user একই chat-এ দুটো আলাদা bot দেখতে পারে। প্রতিটা trace-এ version ID থাকলে বোঝা যায় কোন prompt কোন উত্তর বানিয়েছে। তখন তুমি বলতে পারো "support-v8-এর user-রা বেশি timeout পেয়েছে" আর খারাপ version তাড়াতাড়ি খুঁজে পাও।
তোমার উত্তরের ভাষা একটু আলাদা হবে।
এইমাত্র কী হলো
Rating কম হলে chance-এর কারণে একটা version ভালো দেখাতে পারে। 60টা rating-এ v8 এগিয়ে ছিল 8 পয়েন্ট। 420টা rating-এ এগিয়ে থাকা নেমে এল 0.5 পয়েন্টে। Metric (আর cost ও latency-র সীমা) তুমি test-এর আগে ঠিক করো, আর থামো শুধু তখন, যখন একটা version সেই metric-এ পরিষ্কারভাবে জেতে। কোনো prompt feedback-এ জিতেও খারাপ লেনদেন হতে পারে, যদি সে ধীর হয় আর বেশি cost করে।
কাজ শেষ, যখন তোমার কাছে ১ম দিনের (66.7% আর 75.0%) আর ৭ম দিনের (69.0% আর 69.5%) thumbs-up হার আছে, আর প্রতিটা দিনের জন্য একটা সিদ্ধান্ত আছে।
নিজেকে যাচাই করোএকটা ভালো বিকেল দেখেই test থামিয়ে দেওয়া ভুল কেন?উত্তর দেখো
Rating কম হলে chance-এর কারণে একটা version ভালো দেখাতে পারে। আগে metric ঠিক করো, আর থামো শুধু যখন একটা version সেই metric-এ পরিষ্কারভাবে জেতে। Cost আর latency-ও গোনায় ধরতে হয়।
Task ৪
নীরবে model বদলে যাওয়া ধরো
এটা কেন দরকার
Vendor নাম না বদলেই একটা model আপডেট করতে পারে। তোমার code একই থাকে, কিন্তু তোমার JSON ভেঙে যেতে পারে। User ধরার আগে তুমি যেন এটা ধরতে পারো, তার একটা উপায় দরকার।
ধাপ ১
নতুন chatএই prompt-এর ৫টা case পড়ো। কোনগুলো বদলেছে, দাগ দাও। তারপর prompt টা copy করো, paste করে Enter চাপো। Model-এর list-এর সাথে নিজেরটা মেলাও।
Prompt আমাদের app একটা model-কে দিয়ে message থেকে {"name": ..., "amount_bdt": ...}-এর মতো JSON বের করায়। Vendor একই model নামের পেছনের model আপডেট করেছে। আমরা 5টা production input পুরনো আর নতুন version দিয়ে চালিয়েছি (বানানো data)। 1. Input: "Rahim paid 1,200 taka" OLD: {"name":"Rahim","amount_bdt":1200} NEW: {"name":"Rahim","amount_bdt":1200} 2. Input: "Sumi sent 5k BDT" OLD: {"name":"Sumi","amount_bdt":5000} NEW: {"name":"Sumi","amount_bdt":"5k"} 3. Input: "Tanvir paid 300 taka and Mina paid 450 taka" OLD: [{"name":"Tanvir","amount_bdt":300},{"name":"Mina","amount_bdt":450}] NEW: {"name":"Tanvir","amount_bdt":300} 4. Input: "Lina paid 75 taka" OLD: {"name":"Lina","amount_bdt":75} NEW: Sure! Here is the JSON: {"name":"Lina","amount_bdt":75} 5. Input: "Arif paid 2,000 taka" OLD: {"name":"Arif","amount_bdt":2000} NEW: {"name":"Arif","amount_bdt":2000} কাজ: 1. প্রতিটা case-এর জন্য বলো SAME না CHANGED, আর বদলের ধরন কী। 2. প্রতিটা বদলের জন্য একটা automatic check লেখো (এমন নিয়ম যা একটা program পরীক্ষা করতে পারে)। 3. Live traffic-এর কত অংশ দুই model দিয়েই চালানো উচিত, আর কিসের উপর alert দেওয়া উচিত, বলো।তুমি দেখবে: ১ আর ৫ নম্বর case SAME। ২, ৩ আর ৪ নম্বর CHANGED: ভুল type (সংখ্যার বদলে লেখা), দ্বিতীয় মানুষটা হারিয়ে যাওয়া, আর JSON-এর চারপাশে বাড়তি লেখা।
Example উত্তর
1 SAME 2 CHANGED: amount_bdt এখন "5k" নামের লেখা, সংখ্যা নয়। Check: amount_bdt অবশ্যই সংখ্যা হতে হবে। 3 CHANGED: list একটা object হয়ে গেছে, Mina হারিয়ে গেছে। Check: output-এ মানুষের সংখ্যা input-এর সংখ্যার সমান হতে হবে। 4 CHANGED: JSON-এর চারপাশে বাড়তি লেখা। Check: পুরো উত্তরটা JSON হিসেবে parse হতে হবে। 5 SAME Live traffic-এর 1-5% দুই model দিয়েই চালাও। Check-এর pass rate আলাদা হলে alert দাও।
তোমার উত্তরের ভাষা একটু আলাদা হবে।
ধাপ ২
একই chatএই prompt টা copy করো, একই chat-এ paste করে Enter চাপো। দেখো, expected output টা ঠিক মনে হচ্ছে কি না।
Prompt একজন user এই উত্তরে thumbs-down দিয়েছে। Input: "Karim paid 1.5 lakh taka" (1 lakh = 100,000) Output: {"name":"Karim","amount_bdt":1.5} এই failure-টাকে আমাদের eval dataset-এর জন্য একটা test case বানাও। Input, expected output আর যে নিয়ম দিয়ে এটা পরীক্ষা হবে, তা দাও। তারপর ২ বাক্যে বলো, এই রকম হাজারটা আসল failure বানানো test-এর চেয়ে বেশি কাজের কেন।তুমি দেখবে: একটা test case। Input হলো Karim-এর বাক্য, expected output-এ
"amount_bdt": 150000আছে, আর নিয়ম বলে amount অবশ্যই 150000 হতে হবে। তারপর আসল failure নিয়ে ২টা বাক্য।Example উত্তর
Input: "Karim paid 1.5 lakh taka" Expected output: {"name":"Karim","amount_bdt":150000} নিয়ম: JSON parse হয়, আর amount_bdt একটা সংখ্যা এবং সেটা 150000। আসল failure আসে আসল user-দের কাছ থেকে, তাই সেগুলো দেখায় কোন case তোমার app ভাঙে। বানানো test শুধু সেটাই ধরে, যা তুমি আগে ভেবেছ।তোমার উত্তরের ভাষা একটু আলাদা হবে।
এইমাত্র কী হলো
Drift মানে model-এর নাম একই থেকে যায়, কিন্তু তার আচরণ বদলে যায়। ১ আর ৫ নম্বর case ঠিক দেখাচ্ছে, তাই শুধু সহজ input-এর test কিছুই ধরত না। কঠিন case-গুলো ভেঙেছে। Drift ধরতে live traffic-এর অল্প অংশ (1-5%) পুরনো আর নতুন model দিয়ে চালাও, check-এর result মেলাও, আর পার্থক্যে alert দাও। User-দের আসল failure নতুন test case হয়ে যায়।
কাজ শেষ, যখন তোমার কাছে ৩টা বদলে যাওয়া case-এর list আছে, প্রতিটার একটা করে check সহ, আর Karim-এর জন্য একটা নতুন test case আছে।
নিজেকে যাচাই করোOffline eval এই ধরনের বদল মিস করতে পারে কেন?উত্তর দেখো
Model-এর নাম একই ছিল, তাই তোমার code-এ কিছু বদলায়নি। একটা স্থির test set-এ হয়তো ভেঙে যাওয়া case-গুলোই নেই। আসল traffic-এর একটা ছোট অংশ দুই model দিয়েই চালালে পার্থক্য ধরা পড়ে।
ভিডিও দেখো · ৭টি
Langfuse Intro - Observability & Tracing Deep Dive Langfuse
LLM Observability: Dashboards, Alerts & SLOs That Work | Module 4.2 KryptoMindz Technologies
How to Version Prompts Without Breaking Production - Latitude Latitude
Improving LLM systems with A/B testing Flow AI
LLM Observability with Langfuse: Debugging a Broken RAG Agent Langfuse
Tracking Drift to Monitor LLM Performance Fiddler AI
Build a Prompt Learning Loop - SallyAnn DeLucia & Fuad Ali, Arize AI Engineer
তথ্যসূত্র
Sources
সব citation মূল paper (arXiv), vendor-এর docs (OpenAI, Anthropic, Google) বা official team blog-এ যায়। প্রতিটি পাতা খুলে citation-এর তথ্য যাচাই করা হয়েছে।
- [1]Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models" (ICLR 2023)
- [2]Wei et al., "Plan-and-Execute Agents" / "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" — NeurIPS 2022
- [3]Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning" — NeurIPS 2023
- [4]Xu et al., "ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models"
- [5]Anthropic Engineering blog — "How we built our multi-agent research system" (2025)
- [6]LangGraph — official documentation (LangChain)
- [7]Temporal — "Durable Execution for LLM Agents"
- [8]Park et al., "Generative Agents: Interactive Simulacra of Human Behavior" — 2023
- [9]Anthropic — "Introducing computer use, a new Claude 3.5 Sonnet capability" (Oct 2024)
- [10]Anthropic — Tool use / function calling documentation
- [11]OpenAI — Function calling guide
- [12]Anthropic — Model Context Protocol (MCP) specification
- [13]Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention" — vLLM paper, SOSP 2023
- [14]Zheng et al., "SGLang: Efficient Execution of Structured Language Model Programs" — 2023
- [15]llama.cpp — open-source GGUF-native inference (ggerganov)
- [16]Lin et al., "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration" — MLSys 2024
- [17]Anthropic — Prompt caching documentation
- [18]Zheng et al., "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" — NeurIPS 2023
- [19]Es et al., "Ragas: Automated Evaluation of Information Retrieval Augmented Language Models" — 2023
- [20]Yue et al., "Large Language Model Cascades with Mixture of Thought Representations" — 2024
- [21]GPTCache — open-source semantic cache
- [22]Guo et al., "DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via RL" — 2025
- [23]Jiang et al., "LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models" — EMNLP 2023
- [24]LiteLLM — unified interface for 100+ LLMs
- [25]OWASP — "Top 10 for LLM Applications" (LLM01 Prompt Injection, 2025)
- [26]Bai et al., "Constitutional AI: Harmlessness from AI Feedback" — Anthropic, 2022
- [27]NVIDIA NeMo Guardrails — open-source toolkit
- [28]Qwen2-VL Team, "Qwen2-VL: Enhancing Vision-Language Model's Perception of the World at Any Resolution" — 2024
- [29]OpenAI — Realtime API documentation
- [30]OpenAI — Production best practices guide