LLMOps আর অবজারভেবিলিটি

এখানে একটা 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-এ শুরু হয়েছে, বলো।

Request-টা status 200 ফেরত দিয়েছে। পুরনো ধরনের DevOps dashboard এটার জন্য সবুজ দেখায়। ৩টা ছোট বাক্যে বলো, শুধু 200 দেখলে এই run-এর কোন জিনিসটা ধরা পড়ে না। তারপর trace-এ কোন ৪টা field রাখা উচিত তার list দাও, যাতে পরে এই failure খুঁজে পাওয়া যায়।

এখানে 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-এ কত লোকসান, বলো।

এবার ধরো আমরা report_writer-কে small model-এ নিয়ে যাচ্ছি। 4, 5 আর 6 নম্বর request-এ একই token সংখ্যা ধরো। প্রতি request-এর নতুন গড় cost কত? Production-এ এই বদল করার আগে আমাদের কী মেপে দেখতে হবে? 100 শব্দের কম লিখে উত্তর দাও।

আমরা 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 বেছে নেওয়া উচিত ছিল?
ছোট আর সরাসরি উত্তর দাও।

আমরা user_id-র hash দিয়ে traffic ভাগ করি (একটা স্থির নিয়ম, যা প্রতিটা user-কে সবসময় একই version-এ পাঠায়)। আমরা এটা করি কেন, প্রতিটা message-এ random বাছি না কেন? আর প্রতিটা trace-এ support-v8-এর মতো prompt version ID রাখা উচিত কেন? ৪টা ছোট বাক্যে উত্তর দাও।

আমাদের 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 দেওয়া উচিত, বলো।

একজন 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-এর চেয়ে বেশি কাজের কেন।