জন্য কীভাবে LLM গুলো ব্যবসায়িক নিয়ম ব্যাখ্যা করে, ওয়ার্কফ্লো স্টেট ট্র্যাক করে এবং সিদ্ধান্ত যাচাই করে — প্রম্পট, টুল, টেস্ট, ও মানব পর্যালোচনার মাধ্যমে, কেবল কোড নয়।

যখন মানুষ জিজ্ঞেস করে যে একটি LLM কি “ব্যবসায়িক নিয়ম সম্পর্কে যুক্তি করতে পারে,” তারা সাধারণত কেবল "এটা কি if/else স্টেটমেন্ট লিখতে পারে"—এর চেয়ে বেশি কিছু বোঝায়। ব্যবসায়িক-নিয়ম যুক্তি হলো নীতিমালা ধারাবাহিকভাবে প্রয়োগ করা, সিদ্ধান্তগুলো ব্যাখ্যা করা, ব্যতিক্রমগুলো সামলানো, এবং বর্তমান ওয়ার্কফ্লো স্টেপের সাথে সঙ্গত থাকা—বিশেষত যখন ইনপুট অসম্পূর্ণ, বিশৃঙ্খল বা পরিবর্তনশীল।
কোড জেনারেশন মূলত লক্ষ্য ভাষায় সঠিক সিনট্যাক্স তৈরির ব্যাপার। নিয়মগত যুক্তি হলো উদ্দেশ্য রক্ষা করার ব্যাপার।
একটি মডেল পুরোপুরি বৈধ কোড জেনারেট করলেও ব্যবসায়িক ফলাফল ভুল হতে পারে কারণ:
অন্য কথায়, সঠিকতা হচ্ছে "এটা কম্পাইল করে কি না?" নয়—এটি হচ্ছে "এটি প্রতিবারেই ব্যবসা যা সিদ্ধান্ত নেবে তা কি মেলে, এবং আমরা কি এটি প্রমাণ করতে পারি?"
LLM গুলো নীতিমালাকে কাঠামোবদ্ধ নিয়মে অনুবাদ করতে, সিদ্ধান্ত পথ প্রস্তাব করতে, এবং মানুষের জন্য ব্যাখ্যা খসড়া করতে সাহায্য করতে পারে। কিন্তু তারা স্বয়ংক্রিয়ভাবে জানে না কোন নিয়ম কর্তৃত্বযুক্ত, কোন ডেটা সোর্স বিশ্বাসযোগ্য, বা কেস বর্তমানে কোন ধাপে আছে। সীমাবদ্ধতা না দিলে, তারা সম্ভাব্য উত্তর আত্মবিশ্বাসের সঙ্গে বেছে নিতে পারে পরিবর্তে শাসিত উত্তর।
তাই লক্ষ্য হওয়া উচিত মডেলকে "স্বাধীনভাবে সিদ্ধান্ত নিতে দেয়া" নয়, বরং এটিকে এমন কাঠামো ও চেক দেয়া যাতে এটি নির্ভরযোগ্যভাবে সহায়তা করতে পারে।
একটি ব্যবহারিক পন্থা পাইপলাইনের মতো দেখায়:
এটাই পার্থক্য একটি মেধাবী কোড স্নিপেট এবং এমন একটি সিস্টেমের মধ্যে যা বাস্তব ব্যবসায়িক সিদ্ধান্ত সমর্থন করতে পারে।
"যুক্তি" নিয়ে কথা বলার আগে, দলেরা প্রায়ই মিলিয়ে দেয় এমন দুটি জিনিস আলাদা করা ভাল: ব্যবসায়িক নিয়ম এবং ওয়ার্কফ্লো।
ব্যবসায়িক নিয়ম হলো সেই সিদ্ধান্ত-স্টেটমেন্ট যা আপনার প্রতিষ্ঠান ধারাবাহিকভাবে প্রয়োগ করতে চায়। এগুলো নীতিমালা ও লজিক হিসেবে দেখা যায়, যেমন:
নিয়মগুলো সাধারণত "IF X, THEN Y" হিসেবে ফ্রেম করা হয় (কখনও কখনও ব্যতিক্রম সহ), এবং এগুলো একটি পরিষ্কার ফলাফল দেয়: অনুমোদন/অস্বীকার, মূল্য A/মূল্য B, আরো তথ্য অনুরোধ ইত্যাদি।
ওয়ার্কফ্লো হলো কাজ শুরু থেকে শেষ পর্যন্ত যেটি প্রসেস করে। এটা কি অনুমোদিত তা বলার চেয়ে বেশি কি হবে পরবর্তীতে তা নিয়ে। ওয়ার্কফ্লোতে প্রায়ই থাকে:
কল্পনা করুন একটি রিফান্ড অনুরোধ।
নিয়মের অংশ: “রিফান্ড ক্রয়ের 30 দিনের মধ্যে অনুমোদিত। ব্যতিক্রম: ডিজিটাল ডাউনলোড একবার অ্যাক্সেস করলে অ-রিফান্ডেবল। ব্যতিক্রম: চার্জব্যাক হলে তা এস্ক্যালেট করা উচিত।”
ওয়ার্কফ্লো স্নিপেট:
নিয়মগুলো জটিল হয় যখন তারা বিরোধ করে ("ভিআইপি কাস্টমার সব সময় রিফান্ড পায়" বনাম "ডিজিটাল ডাউনলোড কখনই নয়"), মিসিং কনটেক্সট-এর উপর নির্ভর করে (ডাউনলোড একবার অ্যাক্সেস করা হয়েছে কি না?), বা এজ-কেস লুকায় (বণ্ডেল, আংশিক রিফান্ড, আঞ্চলিক আইন)। ওয়ার্কফ্লো আরেকটি স্তর যোগ করে: সিদ্ধান্তগুলোকে বর্তমান স্টেট, পূর্ববর্তী অ্যাকশন এবং ডেডলাইনগুলোর সাথে সামঞ্জস্য রাখতে হয়।
LLM গুলো মানুষের মতো ব্যবসায়িক নিয়ম "বুঝে" না। তারা বড় টেক্সট ডাটার প্যাটার্ন থেকে পরবর্তী সম্ভাব্য শব্দ জেনারেট করে। তাই একটি LLM বিশ্বাসযোগ্য শোনালেও তা আন্দাজে কাজ করছে—অথবা অনুপস্থিত বিবরণ চুপচাপ পূরণ করছে যা দেয়া হয়নি।
এই সীমাবদ্ধতা ওয়ার্কফ্লো ও সিদ্ধান্ত লজিকের জন্য গুরুত্বপূর্ণ। একটি মডেল এমন নিয়ম প্রয়োগ করতে পারে যা "ঠিক শোনায়" ("কর্মচারীদের সবসময় ম্যানেজারের অনুমোদন দরকার") যদিও বাস্তব নীতিতে ব্যতিক্রম আছে ("শুধু $500 উপরে।" বা "শুধু কনট্রাক্টরদের জন্য")। এটি একটি সাধারণ ব্যর্থতা মোড: আত্মবিশ্বাসী কিন্তু ভুল নিয়ম প্রয়োগ।
সত্যিকারের “বোধ” না থাকা সত্ত্বেও, LLM গুলো সাহায্য করতে পারে যদি আপনি তাদের একটি কাঠামোবদ্ধ সহকারী হিসেবে ব্যবহার করেন:
চাবিকাঠি হলো মডেলকে এমন একটি অবস্থায় রাখা যাতে এটি সহজে অনুপ্রবেশ না করতে পারে।
অস্পষ্টতা কমানোর একটি ব্যবহারিক উপায় হলো সংকুচিত আউটপুট: মডেলকে একটি নির্দিষ্ট স্কিমা বা টেমপলেটে উত্তর দিতে বাধ্য করা (উদাহরণস্বরূপ নির্দিষ্ট ফিল্ড সহ JSON, অথবা নির্ধারিত কলাম সহ একটি টেবিল)। যখন মডেলকে rule_id, conditions, exceptions, এবং decision পূরণ করতে হয়, তখন গ্যাপ স্পট করা ও স্বয়ংক্রিয়ভাবে ভ্যালিডেশন করা সহজ হয়।
সঙ্কুচিত ফরম্যাটগুলো যখন মডেল কোনো তথ্য জানে না তখন সেটাও পরিষ্কার করে তোলে। যদি একটি প্রয়োজনীয় ফিল্ড অনুপস্থিত থাকে, আপনি একটি ফলো-আপ প্রশ্ন জোর করতে পারেন শ্যাষ একটা অনিশ্চিত উত্তর গ্রহণ করার পরিবর্তে।
টেকঅওয়ে: LLM "যুক্তি"কে প্যাটার্ন-ভিত্তিক জেনারেশন হিসেবে দেখুন যাকে কাঠামো দ্বারা পরিচালিত করা হয়েছে—নীতিগুলো সংগঠিত ও ক্রস-চেক করার জন্য কার্যকর, কিন্তু যদি আপনি এটিকে অটল সিদ্ধান্তকারী ধরে নেন তবে ঝুঁকিপূর্ণ।
নীতির ডকুমেন্টগুলো মানুষের জন্য লেখা: তারা লক্ষ্য, ব্যতিক্রম, এবং "সাধারণ যুক্তি" একই অনুচ্ছেদে মিশায়। একটি LLM সেই টেক্সট সংক্ষেপ করতে পারে, কিন্তু এটি আরও নির্ভরযোগ্যভাবে চলবে যখন আপনি নীতিটিকে স্পষ্ট, পরীক্ষাযোগ্য ইনপুটে রূপান্তর করবেন।
ভালো নিয়ম-প্রতিনিধিত্ব দুটো বৈশিষ্ট্য শেয়ার করে: তারা অস্পষ্ট নয় এবং পরীক্ষা করা যায়।
নিয়মগুলো এমনভাবে লিখুন যা আপনি পরীক্ষা করতে পারবেন:
নীতিগুলো মডেলে কয়েকটি ফর্মে প্রদান করা যায়:
বাস্তব নীতিগুলো দ্বন্দ্ব করে। যখন দুটি নিয়ম একে অপরের সাথে বিরোধে থাকে, মডেলটির একটি পরিষ্কার অগ্রাধিকার নীতি প্রয়োজন। প্রচলিত পদ্ধতি:
সংঘাত-নিয়মটি সরাসরি উল্লেখ করুন, বা এটিকে এনকোড করুন (উদাহরণস্বরূপ, priority: 100)। না হলে LLM হয়তো নিয়মগুলোকে "ভাগ করে" মেনে নেবে।
মূল নীতি টেক্সট:
“Refunds are available within 30 days for annual plans. Monthly plans are non-refundable after 7 days. If the account shows fraud or excessive chargebacks, do not issue a refund. Enterprise customers need Finance approval for refunds over $5,000.”
Structured rules (YAML):
rules:
- id: R1
statement: "IF plan_type = annual AND days_since_purchase <= 30 THEN refund MAY be issued"
priority: 10
- id: R2
statement: "IF plan_type = monthly AND days_since_purchase > 7 THEN refund MUST NOT be issued"
priority: 20
- id: R3
statement: "IF fraud_flag = true OR chargeback_rate = excessive THEN refund MUST NOT be issued"
priority: 100
- id: R4
statement: "IF customer_tier = enterprise AND refund_amount > 5000 THEN finance_approval MUST be obtained"
priority: 50
conflict_resolution: "Higher priority wins; MUST NOT overrides MAY"
এখন মডেলটি কি গুরুত্বপূর্ণ তা আন্দাজ করছে না—এটি একটি রুল সেট প্রয়োগ করছে যা আপনি পর্যালোচনা, পরীক্ষা, এবং সংস্করণ করতে পারেন।
একটি ওয়ার্কফ্লো কেবল নিয়মের সেট নয়; এটি ইভেন্টের একটি ক্রম যেখানে পূর্ববর্তী ধাপগুলি পরবর্তী কি হওয়া উচিত তা পরিবর্তন করে। সেই "মেমোরি" হল স্টেট: কেস সম্পর্কে বর্তমান তথ্য (কে কী জমা দিয়েছে, কী ইতিমধ্যে অনুমোদিত, কী অপেক্ষমান, এবং কোন ডেডলাইন প্রযোজ্য)। আপনি যদি স্টেট স্পষ্টভাবে ট্র্যাক না করেন, ওয়ার্কফ্লোটি স্বাভাবিকভাবে ভেঙে পড়ে—ডুপ্লিকেট অনুমোদন, প্রয়োজনীয় চেক বাদ পড়া, সিদ্ধান্ত উল্টে যাওয়া, বা মডেল ভুল নীতি প্রয়োগ করা কারণ এটি আগে যা হয়েছে তা নির্ভরযোগ্যভাবে অনুমান করতে পারে না।
স্টেটকে ওয়ার্কফ্লোয়ের স্কোরবোর্ড হিসেবে ভাবুন। এটি উত্তর দেয়: আমরা এখন কোথায়? কি হয়েছে? পরবর্তী কি অনুমোদিত? একটি LLM-কে পরিষ্কার স্টেট সারাংশ দিলে এটি অতীত ধাপগুলো পুনরায় আলোচনা করা থেকে বিরত থাকবে বা অনুমান করা বন্ধ করবে।
যখন আপনি মডেল কল করেন, ব্যবহারকারীর অনুরোধের সাথে একটি সংক্ষিপ্ত স্টেট পেলোড অন্তর্ভুক্ত করুন। দরকারী ফিল্ডগুলো:
manager_review: approved, finance_review: pending)প্রতিটি ইতিহাস বার্তা ডাম্প করা এড়িয়ে চলুন। পরিবর্তে, বর্তমান স্টেট এবং কী মূল ট্রানজিশন ঘটেছে তার একটি সংক্ষিপ্ত অডিট ট্রেল দিন।
ওয়ার্কফ্লো ইঞ্জিন (ডাটাবেস, টিকিট সিস্টেম, বা অর্কেস্ট্রেটর)-কে single source of truth হিসেবে বিবেচনা করুন। LLM-কে সেই সিস্টেম থেকে স্টেট পড়তে দিন এবং পরবর্তী পদক্ষেপ প্রস্তাব করতে দিন, কিন্তু সিস্টেমটিই সেই ট্রানজিশনগুলো রেকর্ড করবে—এটি "স্টেট ড্রিফট" কমাবে, যেখানে মডেলটির বর্ণনা বাস্তবতা থেকে বিচ্যুত হয়।
{
"request_id": "TRV-10482",
"workflow": "travel_reimbursement_v3",
"current_step": "finance_review",
"step_status": {
"submission": "complete",
"manager_review": "approved",
"finance_review": "pending",
"payment": "not_started"
},
"actors": {
"employee_id": "E-2291",
"manager_id": "M-104",
"finance_queue": "FIN-AP"
},
"amount": 842.15,
"currency": "USD",
"submitted_at": "2025-12-12T14:03:22Z",
"last_state_update": "2025-12-13T09:18:05Z",
"flags": {
"receipt_missing": false,
"policy_exception_requested": true,
"needs_escalation": false
}
}
এমন একটি স্ন্যাপশট থাকলে মডেল সঙ্গত থাকতে পারে: এটি আবার ম্যানেজার অনুমোদন চাইবে না, ফাইন্যান্স চেকগুলোতে ফোকাস করবে, এবং বর্তমান ফ্ল্যাগ ও স্টেপের কারনে সিদ্ধান্ত ব্যাখ্যা করতে পারবে।
ভালো একটি প্রম্পট কেবল উত্তর চাইবে না—এটি সেট করবে মডেল কিভাবে আপনার নিয়ম প্রয়োগ করবে এবং কিভাবে ফলাফল রিপোর্ট করবে। লক্ষ্য হচ্ছে পুনরাবৃত্তিমূলক সিদ্ধান্ত, না উজ্জ্বল প্রাঞ্জল লেখনী।
মডেলটিকে একটি নির্দিষ্ট ভূমিকা দিন যা আপনার প্রসেসের সাথে সংযুক্ত। তিনটি ভূমিকাই ভালভাবে কাজ করে:
আপনি এগুলো ধারাবাহিকভাবে চালাতে পারেন ("analyst → validator → agent") অথবা একই স্ট্রাকচার্ড রেসপন্সে সব তিনটি আউটপুট চাইতে পারেন।
"চেইন-অফ-থট" চাইবার পরিবর্তে দৃশ্যমান ধাপ ও আর্টিফ্যাক্ট নির্দিষ্ট করুন:
এটি মডেলকে সংগঠিত রাখে এবং সরবরাহযোগ্যতায় মনোযোগী করে: কোন নিয়ম ব্যবহৃত হয়েছে এবং ফলাফল কি।
ফ্রি-ফর্ম ব্যাখ্যা ভাসমান হয়ে যায়। একটি সংক্ষিপ্ত যুক্তি দাবি করুন যা সূত্র দেখায়:
এটি পর্যালোচনাকে দ্রুত করে এবং বিরোধের সময় ডিবাগ করতে সাহায্য করে।
প্রতিটি সময় একটি নির্দিষ্ট টেমপ্লেট ব্যবহার করুন:
টেমপ্লেটটি অস্পষ্টতা কমায় এবং মডেলকে অনিশ্চয়তার ক্ষেত্রে দৃঢ়ভাবে গ্যাপ সারফেস করতে প্রণোদিত করে।
একটি LLM মজারভাবে উত্তর লিখতে পারে এমনকি যখন এটি গুরুত্বপূর্ণ বিষয়গুলো অনুপস্থিত। সেটি ড্রাফ্টিংয়ের জন্য ভাল, কিন্তু ব্যবসায়িক-নিয়ম সিদ্ধান্তের জন্য ঝুঁকিপূর্ণ। যদি মডেলকে একটি অ্যাকাউন্টের স্ট্যাটাস, কাস্টমারের টিয়ার, আঞ্চলিক ট্যাক্স রেট, বা সীমা ইতিমধ্যে কি পৌঁছেছে তা অনুমান করতে হয়, আপনি আত্মবিশ্বাসী দেখানো ভুল পাবেন।
টুলগুলো এটি সমাধান করে: “প্রথমে প্রমাণ ফেচ করুন, তারপর সিদ্ধান্ত নিন”—এই দুই-ধাপ প্রক্রিয়ায় রূপান্তর করে যুক্তি।
রুল ও ওয়ার্কফ্লো-ভিত্তিক সিস্টেমে কয়েকটি সাধারণ টুলই বেশিরভাগ কাজ করে:
চাবিকাঠি হলো মডেল অপারেশনাল ফ্যাক্টস "করছে না"—এটি তাদের অনুরোধ করছে।
আপনি সব নীতিগুলো কেন্দ্রীয় স্টোরে রাখলেও, সাধারণত সেগুলো পুরোপুরি প্রম্পটে পেস্ট করতে চান না। রিট্রিভাল সাহায্য করে কেবল বর্তমান কেসের জন্য সর্বাধিক প্রাসঙ্গিক ফ্রাগমেন্ট বাছাই করতে—উদাহরণস্বরূপ:
এটি বিরোধ কমায় এবং মডেলকে আপডেটেড না হওয়া নিয়ম অনুসরণ করার বদলে গুরুত্বপূর্ণ অংশগুলোতে ফোকাস করায়।
একটি নির্ভরযোগ্য প্যাটার্ন হলো টুল ফলাফলকে প্রমাণ হিসেবে ধরার নিয়ম। উদাহরণ:
get_account(account_id) → status="past_due", plan="Business", usage_this_month=12000retrieve_policies(query="overage fee Business plan") → returns rule: “Overage fee applies above 10,000 units at $0.02/unit.”calculate_overage(usage=12000, threshold=10000, rate=0.02) → $40.00এখন সিদ্ধান্ত আর আন্দাজ নয়: এটি নির্দিষ্ট ইনপুটের ওপর ভিত্তি করে উপসংহার ("past_due", "12,000 units", "$0.02/unit")। পরবর্তীতে যদি অডিট করা হয়, আপনি দেখতে পারবেন কোন তথ্য ও কোন রুল সংস্করণ ব্যবহার করা হয়েছিল—এবং যখন কিছু পরিবর্তন করে ঠিক করতে হবে তখন সঠিক অংশ ঠিক করা যাবে।
ফ্রি-ফর্ম টেক্সট নমনীয় কিন্তু এটি ভাঙার সহজ উপায়। একটি মডেল "উচিত মনে হচ্ছে" এমন একটি উত্তর দিতে পারে যা অটোমেট করার অনুপযোগী ("ঠিক মনে হচ্ছে") বা ধাপে অসমঞ্জস ("approve" বনাম "approved")। সংকুচিত আউটপুট প্রতিটি সিদ্ধান্তকে একটি পূর্বানুমিত আকারে বাধ্য করে।
একটি ব্যবহারিক প্যাটার্ন হলো মডেলকে একটি একক JSON অবজেক্টে উত্তর দিতে বাধ্য করা যা আপনার সিস্টেম পার্স করে রুট করতে পারে:
{
"decision": "needs_review",
"reasons": [
"Applicant provided proof of income, but the document is expired"
],
"next_action": "request_updated_document",
"missing_info": [
"Income statement dated within the last 90 days"
],
"assumptions": [
"Applicant name matches across documents"
]
}
এই স্ট্রাকচারটি এমনকি যখন মডেল পুরোপুরি সিদ্ধান্ত নিতে পারে না তখনও কার্যকর। missing_info এবং assumptions অনিশ্চয়তাকে অ্যাকশেনযোগ্য ফলো-আপে পরিণত করে, লুকানো আন্দাজের বদলে।
চলাচলের পরিবর্তন কমাতে, মূল ফিল্ডগুলোর জন্য অনুমোদিত মান (enums) সংজ্ঞায়িত করুন। উদাহরণ:
decision: approved | denied | needs_reviewnext_action: approve_case | deny_case | request_more_info | escalate_to_humanএনামগুলো থাকলে ডাউনস্ট্রীম সিস্টেমকে পরিভাষা, বিরচন, বা টোন ব্যাখ্যা করতে হবে না—তারা সহজে পরিচিত মানের উপর ব্রাঞ্চ করতে পারে।
স্কিমা গার্ডরেইল হিসেবে কাজ করে। তারা:
reasons)।decision ও next_action থেকে ট্রিগার করা যায়।ফলাফল হলো কম অস্পষ্টতা, কম এজ-কেস ব্যর্থতা, এবং ধারাবাহিকভাবে ওয়ার্কফ্লোতে চলাচল করে এমন সিদ্ধান্ত।
একটি ভাল প্রম্পট থাকা সত্ত্বেও মডেল "ঠিক শোনায়" এমনকি যখন এটি নীতিভঙ্গ করছে, প্রয়োজনীয় ধাপ ছাড়ছে, বা একটি মান উদ্ভাবিত করছে। ভ্যালিডেশন হলো সেই সেফটি নেট যা একটি সম্ভাব্য উত্তরকে নির্ভরযোগ্য সিদ্ধান্তে পরিণত করে।
শুরুতে যাচাই করুন যে নিয়ম প্রয়োগের জন্য ন্যূনতম তথ্য আছে কি না। প্রি-চেকগুলো মডেল সিদ্ধান্ত নেওয়ার আগে চালান।
সাধারণ প্রি-চেকের মধ্যে রয়েছে প্রয়োজনীয় ফিল্ড (উদাহরণ: কাস্টমার টাইপ, অর্ডার টোটাল, অঞ্চল), মৌলিক ফরম্যাট (তারিখ, আইডি, মুদ্রা), এবং অনুমোদিত রেঞ্জ (নেগেটিভ নয়, শতাংশ 100% কাপে)। যদি কিছু ব্যর্থ করে, একটি স্পষ্ট, অ্যাকশেনযোগ্য ত্রুটি ফেরত দিন ("Missing 'region'; cannot choose tax rule set") মডেলকে আন্দাজ করতে দিয়ে না।
মডেল আউটপুট করার পরে যাচাই করুন যে সেটি আপনার রুল সেটের সাথে সঙ্গত।
ফোকাস করুন:
প্রথম উত্তরের পরে একটি "সেকেন্ড পাস" যোগ করুন যা প্রথম উত্তরটি আবার মূল্যায়ন করে। এটি অন্য একটি মডেল কল হতে পারে বা একই মডেলকে একটি ভ্যালিডেটর-স্টাইল প্রম্পট দিয়ে চালানো হতে পারে যা কেবল কমপ্লায়েন্স চেক করে, সৃষ্টিশীলতা নয়।
সহজ একটি প্যাটার্ন: প্রথম পাস সিদ্ধান্ত + যুক্তি উৎপন্ন করে; সেকেন্ড পাস valid অথবা ব্যর্থতাগুলোর একটি স্ট্রাকচার্ড তালিকা দেয় (মিসিং ফিল্ড, লঙ্ঘিত বাধ্যবাধকতা, অস্পষ্ট নিয়ম ব্যাখ্যা)।
প্রতিটি সিদ্ধান্তের জন্য ব্যবহৃত ইনপুট, রুল/পলিসি সংস্করণ, এবং ভ্যালিডেশন ফলাফল লগ করুন (সেকেন্ড-পাস ফলসহ)। যখন কিছু ভুল হয়, এটি আপনাকে ঠিক একই শর্ত পুনরায় তৈরি করতে দেয়, রুল ম্যাপিং ঠিক করতে সাহায্য করে, এবং সংশোধন নিশ্চিত করে—মডেল "কী বোঝাতে চেয়েছিল" অনুমান না করেই।
রুল- এবং ওয়ার্কফ্লো-চালিত LLM ফিচারের টেস্টিং হলো "কী জেনারেট করল?" চেক করা নয়, বরং "এক সুচিন্তিত মানুষ ঠিক একই সিদ্ধান্ত নিত কি, সঠিক কারণ দেখিয়ে, প্রতিবার?" ভালো খবর: আপনি এটি ঐ একই শৃঙ্খলায় পরীক্ষা করতে পারেন যেভাবে প্রচলিত সিদ্ধান্ত লজিককে টেস্ট করেন।
প্রতিটি নিয়মকে একটি ফাংশনের মতো বিবেচনা করুন: ইনপুট দিলে একটি আউটকাম ফেরত দেয় যা আপনি assert করতে পারেন।
উদাহরণস্বরূপ, যদি আপনার একটি রিফান্ড নিয়ম থাকে "খোলা না থাকা আইটেমের জন্য 30 দিনের মধ্যে রিফান্ড অনুমোদিত", লক্ষ্যভিত্তিক কেস লিখুন:
এই ইউনিট টেস্টগুলো অফ-বাই-ওয়ান সংখ্যা, মিসিং ফিল্ড, এবং "সহায়ক" মডেল আচরণ যা অজানা ভরাট করে তা ধরবে।
ওয়ার্কফ্লো তখনই ব্যর্থ হয় যখন স্টেট ধাপে ধাপে অসঙ্গত থাকে। সিনারিও টেস্টগুলো বাস্তব ভ্রমণ সিমুলেট করে:
লক্ষ্য হলো যাচাই করা যে মডেল বর্তমান স্টেটকে সম্মান করে এবং কেবল অনুমোদিত ট্রানজিশনগুলোই নেয়।
কিছু বাস্তব, অ্যানোনিমাইজড উদাহরণ সংগ্রহ করুন যেগুলোর সম্মত ফলাফল আছে (সংক্ষিপ্ত যুক্তিসহ)। এটি ভার্শন করা রাখুন এবং নীতি পরিবর্তন হলে রিভিউ করুন। একটি ছোট গোল্ড সেট (এমনকি 100–500 কেস) শক্তিশালী কারণ এটি অনিয়মিত বাস্তবতা—মিসিং ডেটা, অদ্ভুত ভাষা, বর্ডারলাইন সিদ্ধান্ত—প্রতিফলিত করে।
সময়ভিত্তিক সিদ্ধান্ত বিতরণ ও মান সংকেত ট্র্যাক করুন:
মনিটরিংকে সেফ রোলব্যাকে জোড়া দিন: পূর্ববর্তী প্রম্পট/রুল প্যাক রাখুন, নতুন ভার্সন ফিচার ফ্ল্যাগ করুন, এবং মেট্রিক ক্ষুণ্ণ হলে দ্রুত রিভার্টের জন্য প্রস্তুত থাকুন। অপারেশনাল প্লেবুক ও রিলিজ গেটিং-এর জন্য দেখুন /blog/validation-strategies।
আপনি উপরোক্ত প্যাটার্নগুলো বাস্তবায়ন করলে সাধারণত মডেলের চারপাশে একটি ছোট সিস্টেম বানাতে হয়: স্টেট স্টোরেজ, টুল কল, রিট্রিভাল, স্কিমা ভ্যালিডেশন, এবং একটি ওয়ার্কফ্লো অর্কেস্ট্রেটর। Koder.ai এমন ধরনের ওয়ার্কফ্লো-ব্যাকড অ্যাসিস্ট্যান্ট দ্রুত প্রোটোটাইপ ও ডিপ্লয় করার একটি ব্যবহারিক উপায়: আপনি চ্যাটে ওয়ার্কফ্লো বর্ণনা করে একটি কাজ করা ওয়েব অ্যাপ (React) প্লাস ব্যাকএন্ড সার্ভিসেস (Go with PostgreSQL) জেনারেট করতে পারেন, এবং স্ন্যাপশট ও রোলব্যাক ব্যবহার করে নিরাপদে ইটারেট করতে পারেন।
এটি ব্যবসায়িক-নিয়ম যুক্তির জন্য গুরুত্বপূর্ণ কারণ "গার্ডরেইল" প্রায়শই অ্যাপ্লিকেশনে থাকে, প্রম্পটে নয়:
LLM গুলো দৈনন্দিন নীতিগুলো প্রয়োগে বিস্ময়কর হতে পারে, কিন্তু তারা নির্ধারিত রুল ইঞ্জিন নয়। তাদেরকে সিদ্ধান্ত-সহকারী হিসেবে দেখুন যা গার্ডরেইল চায়—না যে তারা চূড়ান্ত কর্তৃপক্ষ।
তিনটি ব্যর্থতা মোড নিয়মভিত্তিক ওয়ার্কফ্লোতে বারবার দেখা যায়:
মানব পর্যালোচনা যোগ করুন যখন:
মডেলকে "কিছু বানাতে দেয়ার" পরিবর্তে পরিষ্কার পরবর্তী ধাপ নির্ধারণ করুন:
নিম্নলিখিতগুলোর বেশিরভাগের উত্তর যদি "হ্যাঁ" হয় তবেই LLM-কে রুল-ভিত্তিক ওয়ার্কফ্লোতে ব্যবহার করুন:
যদি না হয়, LLM-কে খসড়া/সহকারী ভূমিকায় রাখুন যতক্ষণ না সেই নিয়ন্ত্রণগুলি বিদ্যমান হয়।