কিভাবে LLM গুলো ব্যবসায়িক নিয়ম ও ওয়ার্কফ্লো যুক্তি পরিচালনা করে

কেন ব্যবসায়িক নিয়মের যুক্তিবিবেচনা কেবল কোড জেনারেশন নয়

যখন মানুষ জিজ্ঞেস করে যে একটি LLM কি “ব্যবসায়িক নিয়ম সম্পর্কে যুক্তি করতে পারে,” তারা সাধারণত কেবল "এটা কি if/else স্টেটমেন্ট লিখতে পারে"—এর চেয়ে বেশি কিছু বোঝায়। ব্যবসায়িক-নিয়ম যুক্তি হলো নীতিমালা ধারাবাহিকভাবে প্রয়োগ করা, সিদ্ধান্তগুলো ব্যাখ্যা করা, ব্যতিক্রমগুলো সামলানো, এবং বর্তমান ওয়ার্কফ্লো স্টেপের সাথে সঙ্গত থাকা—বিশেষত যখন ইনপুট অসম্পূর্ণ, বিশৃঙ্খল বা পরিবর্তনশীল।

যুক্তি বনাম কোড উত্তোলন

কোড জেনারেশন মূলত লক্ষ্য ভাষায় সঠিক সিনট্যাক্স তৈরির ব্যাপার। নিয়মগত যুক্তি হলো উদ্দেশ্য রক্ষা করার ব্যাপার।

একটি মডেল পুরোপুরি বৈধ কোড জেনারেট করলেও ব্যবসায়িক ফলাফল ভুল হতে পারে কারণ:

• নীতির লেখা অস্পষ্ট ("recent customer", "high risk", "approved documentation").
• নিয়মগুলো সংঘাত করে এবং অগ্রাধিকার অস্পষ্ট।
• এজ-কেসগুলো বলা নেই (আংশিক রিফান্ড, ডুপ্লিকেট, সপ্তাহান্ত/ছুটির দিন)।
• ওয়ার্কফ্লো স্টেট পরবর্তী কি হওয়া উচিত তা বদলে দেয় (ইনটেক বনাম রিভিউ বনাম চূড়ান্ত অনুমোদন)।

অন্য কথায়, সঠিকতা হচ্ছে "এটা কম্পাইল করে কি না?" নয়—এটি হচ্ছে "এটি প্রতিবারেই ব্যবসা যা সিদ্ধান্ত নেবে তা কি মেলে, এবং আমরা কি এটি প্রমাণ করতে পারি?"

LLM থেকে কী আশা করা উচিত

LLM গুলো নীতিমালাকে কাঠামোবদ্ধ নিয়মে অনুবাদ করতে, সিদ্ধান্ত পথ প্রস্তাব করতে, এবং মানুষের জন্য ব্যাখ্যা খসড়া করতে সাহায্য করতে পারে। কিন্তু তারা স্বয়ংক্রিয়ভাবে জানে না কোন নিয়ম কর্তৃত্বযুক্ত, কোন ডেটা সোর্স বিশ্বাসযোগ্য, বা কেস বর্তমানে কোন ধাপে আছে। সীমাবদ্ধতা না দিলে, তারা সম্ভাব্য উত্তর আত্মবিশ্বাসের সঙ্গে বেছে নিতে পারে পরিবর্তে শাসিত উত্তর।

তাই লক্ষ্য হওয়া উচিত মডেলকে "স্বাধীনভাবে সিদ্ধান্ত নিতে দেয়া" নয়, বরং এটিকে এমন কাঠামো ও চেক দেয়া যাতে এটি নির্ভরযোগ্যভাবে সহায়তা করতে পারে।

এই পোস্টের বাকি অংশ কী করবে

একটি ব্যবহারিক পন্থা পাইপলাইনের মতো দেখায়:

1. নীতিগুলোর লেখা usable rule representations-এ রূপান্তর করা।
2. ওয়ার্কফ্লো স্টেট ট্র্যাক করা যাতে সিদ্ধান্তগুলো ধাপে ধাপে সঙ্গত থাকে।
3. অগ্রাধিকার, ব্যতিক্রম, এবং ব্যাখ্যা জোরদার করার জন্য প্রম্পট প্যাটার্ন ব্যবহার করা।
4. অনুমোদিত ডেটা ব্যবহারের মাধ্যমে টুল ও রিট্রিভাল দিয়ে সিদ্ধান্তগুলো গ্রাউন্ড করা।
5. অস্পষ্টতা কমাতে আউটপুটকে স্কিমা দিয়ে বাধ্য করা।
6. ভ্যালিডেট, টেস্ট, ও মনিটর করা যাতে ভুলগুলি রিলিজের আগে ধরা পড়ে।

এটাই পার্থক্য একটি মেধাবী কোড স্নিপেট এবং এমন একটি সিস্টেমের মধ্যে যা বাস্তব ব্যবসায়িক সিদ্ধান্ত সমর্থন করতে পারে।

ব্যবসায়িক নিয়ম ও ওয়ার্কফ্লো: সংক্ষিপ্ত, সাধারণ ভাষার রিফ্রেশার

"যুক্তি" নিয়ে কথা বলার আগে, দলেরা প্রায়ই মিলিয়ে দেয় এমন দুটি জিনিস আলাদা করা ভাল: ব্যবসায়িক নিয়ম এবং ওয়ার্কফ্লো।

ব্যবসায়িক নিয়ম কী?

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

• যোগ্যতা: কে কোন সুবিধা, প্ল্যান বা ফিচারের যোগ্য?
• মূল্য নির্ধারণ: কখন কী ছাড় প্রযোজ্য?
• অনুমোদন: কখন ম্যানেজার রিভিউ প্রয়োজন?
• অনেরুগমন (কমপ্লায়েন্স): কি লগ করা, redact করা বা ব্লক করা উচিত?

নিয়মগুলো সাধারণত "IF X, THEN Y" হিসেবে ফ্রেম করা হয় (কখনও কখনও ব্যতিক্রম সহ), এবং এগুলো একটি পরিষ্কার ফলাফল দেয়: অনুমোদন/অস্বীকার, মূল্য A/মূল্য B, আরো তথ্য অনুরোধ ইত্যাদি।

ওয়ার্কফ্লো কী?

ওয়ার্কফ্লো হলো কাজ শুরু থেকে শেষ পর্যন্ত যেটি প্রসেস করে। এটা কি অনুমোদিত তা বলার চেয়ে বেশি কি হবে পরবর্তীতে তা নিয়ে। ওয়ার্কফ্লোতে প্রায়ই থাকে:

• স্টেটস: submitted → under review → approved/denied → completed
• স্টেপস ও হ্যান্ডঅফস: কাস্টমার সাপোর্ট → ফাইন্যান্স → কাস্টমার
• সময়ভিত্তিক ইভেন্ট: রেমাইন্ডার, SLA, 14 দিনের পর অটো-ক্যানসেল
• আর্টিফ্যাক্টস: ফর্ম, অ্যাটাচমেন্ট, রিজন কোড, অডিট নোট

ছোট একটি উদাহরণ: রিফান্ড অনুরোধ

কল্পনা করুন একটি রিফান্ড অনুরোধ।

নিয়মের অংশ: “রিফান্ড ক্রয়ের 30 দিনের মধ্যে অনুমোদিত। ব্যতিক্রম: ডিজিটাল ডাউনলোড একবার অ্যাক্সেস করলে অ-রিফান্ডেবল। ব্যতিক্রম: চার্জব্যাক হলে তা এস্ক্যালেট করা উচিত।”

ওয়ার্কফ্লো স্নিপেট:

1. কাস্টমার অনুরোধ সাবমিট করে (স্টেট: submitted)।
2. সিস্টেম ক্রয় তারিখ ও পণ্য ধরন চেক করে (স্টেট: under review)।
3. যদি যোগ্য, রিফান্ড ইস্যু করে ও কাস্টমারকে নোটিফাই করে (স্টেট: completed)।
4. যদি চার্জব্যাক থাকে, ফাইন্যান্সের কাছে তদন্তের জন্য রুট করে (স্টেট: escalated)।

কেন নিয়মগুলো দেখায় তার থেকেও কঠিন

নিয়মগুলো জটিল হয় যখন তারা বিরোধ করে ("ভিআইপি কাস্টমার সব সময় রিফান্ড পায়" বনাম "ডিজিটাল ডাউনলোড কখনই নয়"), মিসিং কনটেক্সট-এর উপর নির্ভর করে (ডাউনলোড একবার অ্যাক্সেস করা হয়েছে কি না?), বা এজ-কেস লুকায় (বণ্ডেল, আংশিক রিফান্ড, আঞ্চলিক আইন)। ওয়ার্কফ্লো আরেকটি স্তর যোগ করে: সিদ্ধান্তগুলোকে বর্তমান স্টেট, পূর্ববর্তী অ্যাকশন এবং ডেডলাইনগুলোর সাথে সামঞ্জস্য রাখতে হয়।

LLM কিভাবে “যুক্তি” করে: সহায়ক স্ট্রাকচারের সাথে প্যাটার্ন-অন্তর্ভুক্ত করা

LLM গুলো মানুষের মতো ব্যবসায়িক নিয়ম "বুঝে" না। তারা বড় টেক্সট ডাটার প্যাটার্ন থেকে পরবর্তী সম্ভাব্য শব্দ জেনারেট করে। তাই একটি LLM বিশ্বাসযোগ্য শোনালেও তা আন্দাজে কাজ করছে—অথবা অনুপস্থিত বিবরণ চুপচাপ পূরণ করছে যা দেয়া হয়নি।

এই সীমাবদ্ধতা ওয়ার্কফ্লো ও সিদ্ধান্ত লজিকের জন্য গুরুত্বপূর্ণ। একটি মডেল এমন নিয়ম প্রয়োগ করতে পারে যা "ঠিক শোনায়" ("কর্মচারীদের সবসময় ম্যানেজারের অনুমোদন দরকার") যদিও বাস্তব নীতিতে ব্যতিক্রম আছে ("শুধু $500 উপরে।" বা "শুধু কনট্রাক্টরদের জন্য")। এটি একটি সাধারণ ব্যর্থতা মোড: আত্মবিশ্বাসী কিন্তু ভুল নিয়ম প্রয়োগ।

কেন তারা এখনও ব্যবসায়িক নিয়মের জন্য কাজের

সত্যিকারের “বোধ” না থাকা সত্ত্বেও, LLM গুলো সাহায্য করতে পারে যদি আপনি তাদের একটি কাঠামোবদ্ধ সহকারী হিসেবে ব্যবহার করেন:

• দীর্ঘ নীতিমালা সংক্ষেপ করা পর্যালোচনার জন্য পরিষ্কার ভাষায়
• অগোছালো টেক্সটকে ধারাবাহিক ফিল্ডে ম্যাপ করা (who, what, threshold, exception, effective date)
• প্রস্তাবিত সিদ্ধান্তটি উল্লেখিত নিয়মের বিরুদ্ধে চেক করা ("কোন ধারা এটি সমর্থন করে?")

চাবিকাঠি হলো মডেলকে এমন একটি অবস্থায় রাখা যাতে এটি সহজে অনুপ্রবেশ না করতে পারে।

মডেলকে ঘোরাঘুরি না করতে বাধ্য করা

অস্পষ্টতা কমানোর একটি ব্যবহারিক উপায় হলো সংকুচিত আউটপুট: মডেলকে একটি নির্দিষ্ট স্কিমা বা টেমপলেটে উত্তর দিতে বাধ্য করা (উদাহরণস্বরূপ নির্দিষ্ট ফিল্ড সহ JSON, অথবা নির্ধারিত কলাম সহ একটি টেবিল)। যখন মডেলকে rule_id, conditions, exceptions, এবং decision পূরণ করতে হয়, তখন গ্যাপ স্পট করা ও স্বয়ংক্রিয়ভাবে ভ্যালিডেশন করা সহজ হয়।

সঙ্কুচিত ফরম্যাটগুলো যখন মডেল কোনো তথ্য জানে না তখন সেটাও পরিষ্কার করে তোলে। যদি একটি প্রয়োজনীয় ফিল্ড অনুপস্থিত থাকে, আপনি একটি ফলো-আপ প্রশ্ন জোর করতে পারেন শ্যাষ একটা অনিশ্চিত উত্তর গ্রহণ করার পরিবর্তে।

টেকঅওয়ে: LLM "যুক্তি"কে প্যাটার্ন-ভিত্তিক জেনারেশন হিসেবে দেখুন যাকে কাঠামো দ্বারা পরিচালিত করা হয়েছে—নীতিগুলো সংগঠিত ও ক্রস-চেক করার জন্য কার্যকর, কিন্তু যদি আপনি এটিকে অটল সিদ্ধান্তকারী ধরে নেন তবে ঝুঁকিপূর্ণ।

গরমান নীতিমালা টেক্সটকে ব্যবহারযোগ্য নিয়ম-প্রতিনিধিত্বে পরিণত করা

নীতির ডকুমেন্টগুলো মানুষের জন্য লেখা: তারা লক্ষ্য, ব্যতিক্রম, এবং "সাধারণ যুক্তি" একই অনুচ্ছেদে মিশায়। একটি LLM সেই টেক্সট সংক্ষেপ করতে পারে, কিন্তু এটি আরও নির্ভরযোগ্যভাবে চলবে যখন আপনি নীতিটিকে স্পষ্ট, পরীক্ষাযোগ্য ইনপুটে রূপান্তর করবেন।

“ব্যবহারযোগ্য” নিয়মগুলো কেমন দেখায়

ভালো নিয়ম-প্রতিনিধিত্ব দুটো বৈশিষ্ট্য শেয়ার করে: তারা অস্পষ্ট নয় এবং পরীক্ষা করা যায়।

নিয়মগুলো এমনভাবে লিখুন যা আপনি পরীক্ষা করতে পারবেন:

• IF/THEN সিদ্ধান্তের জন্য (যোগ্যতা, রাউটিং, অনুমোদন)
• MUST / MUST NOT কঠোর সীমাবদ্ধতার জন্য
• MAY অনুমোদিত বিকল্পের জন্য (প্রায়ই একটি টাই-ব্রেকার দরকার)

নীতিগুলো মডেলে কয়েকটি ফর্মে প্রদান করা যায়:

• সাধারণ ভাষার বুলেট (সবচেয়ে দ্রুত, এখনও কাঠামোবদ্ধ)
• একটি টেবিল (থ্রেশহোল্ড ভিত্তিক নীতির জন্য চমৎকার)
• YAML/JSON (সর্বোত্তম যখন আপনি সংকুচিত আউটপুট ও স্বয়ংক্রিয় ভ্যালিডেশনও চান)

সংঘাত ও অগ্রাধিকার মোকাবেলা

বাস্তব নীতিগুলো দ্বন্দ্ব করে। যখন দুটি নিয়ম একে অপরের সাথে বিরোধে থাকে, মডেলটির একটি পরিষ্কার অগ্রাধিকার নীতি প্রয়োজন। প্রচলিত পদ্ধতি:

• বিশেষ সাধারণের উপর জয়ী (একটি ব্যতিক্রম ডিফল্টকে ওভাররাইড করে)
• উচ্চতর কর্তৃত্ব জয়ী (আইনি/কমপ্লায়েন্স টিমের নিয়ম দলের পছন্দের উপর জয়ী)
• নতুনতম জয়ী (নতুন সংস্করণ পুরানোটি অতিক্রম করে)
• স্পষ্ট অগ্রাধিকার নম্বর (সবচেয়ে নির্ভরযোগ্য)

সংঘাত-নিয়মটি সরাসরি উল্লেখ করুন, বা এটিকে এনকোড করুন (উদাহরণস্বরূপ, 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)
• স্টেবল আইডি (request ID, employee ID) যাতে মডেল কেসগুলো মিশিয়ে না ফেলে
• টাইমস্ট্যাম্প (submitted at, last updated) যাতে "নতুনতম জয়ী" পরিস্থিতি সমাধান হয়
• ফ্ল্যাগস (policy exceptions, missing documents, escalation required)

প্রতিটি ইতিহাস বার্তা ডাম্প করা এড়িয়ে চলুন। পরিবর্তে, বর্তমান স্টেট এবং কী মূল ট্রানজিশন ঘটেছে তার একটি সংক্ষিপ্ত অডিট ট্রেল দিন।

একক সত্যের উৎস বজায় রাখুন

ওয়ার্কফ্লো ইঞ্জিন (ডাটাবেস, টিকিট সিস্টেম, বা অর্কেস্ট্রেটর)-কে 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
  }
}

এমন একটি স্ন্যাপশট থাকলে মডেল সঙ্গত থাকতে পারে: এটি আবার ম্যানেজার অনুমোদন চাইবে না, ফাইন্যান্স চেকগুলোতে ফোকাস করবে, এবং বর্তমান ফ্ল্যাগ ও স্টেপের কারনে সিদ্ধান্ত ব্যাখ্যা করতে পারবে।

প্রম্পট প্যাটার্ন যা নিয়ম-অনুসরণ ও সিদ্ধান্ত উন্নত করে

ভালো একটি প্রম্পট কেবল উত্তর চাইবে না—এটি সেট করবে মডেল কিভাবে আপনার নিয়ম প্রয়োগ করবে এবং কিভাবে ফলাফল রিপোর্ট করবে। লক্ষ্য হচ্ছে পুনরাবৃত্তিমূলক সিদ্ধান্ত, না উজ্জ্বল প্রাঞ্জল লেখনী।

1) রোল প্রম্পটিং: একটি কাজ নির্ধারণ করুন, শুধু ভঙ্গি নয়

মডেলটিকে একটি নির্দিষ্ট ভূমিকা দিন যা আপনার প্রসেসের সাথে সংযুক্ত। তিনটি ভূমিকাই ভালভাবে কাজ করে:

• Policy analyst: নীতির টেক্সট ব্যাখ্যা করে এবং বর্তমান কেসে ম্যাপ করে।
• Validator: সিদ্ধান্তটি প্রয়োজনীয়তাগুলোর বিরুদ্ধে চেক করে এবং অনুপস্থিত ইনপুট ফ্ল্যাগ করে।
• Agent: পরবর্তী ওয়ার্কফ্লো অ্যাকশন নেয় (টিকিট তৈরি, ইমেইল খসড়া, স্ট্যাটাস সেট)।

আপনি এগুলো ধারাবাহিকভাবে চালাতে পারেন ("analyst → validator → agent") অথবা একই স্ট্রাকচার্ড রেসপন্সে সব তিনটি আউটপুট চাইতে পারেন।

2) ধাপে ধাপে নির্দেশনা (লুকানো চিন্তার চেইন না চাইলে)

"চেইন-অফ-থট" চাইবার পরিবর্তে দৃশ্যমান ধাপ ও আর্টিফ্যাক্ট নির্দিষ্ট করুন:

1. প্রাসঙ্গিক নিয়ম চিহ্নিত করুন।
2. কেস থেকে প্রয়োজনীয় ইনপুট বের করুন।
3. অগ্রাধিকার অনুযায়ী নিয়ম প্রয়োগ করুন।
4. সিদ্ধান্ত এবং পরবর্তী ধাপ প্রদান করুন।

এটি মডেলকে সংগঠিত রাখে এবং সরবরাহযোগ্যতায় মনোযোগী করে: কোন নিয়ম ব্যবহৃত হয়েছে এবং ফলাফল কি।

3) একটি কাঠামোবদ্ধ যুক্তি চাইুন: রুল আইডি + প্রমাণ

ফ্রি-ফর্ম ব্যাখ্যা ভাসমান হয়ে যায়। একটি সংক্ষিপ্ত যুক্তি দাবি করুন যা সূত্র দেখায়:

• Rule IDs used (উদাহরণ: R-12, R-18)
• Evidence (নীতির টেক্সট থেকে উদ্ধৃত অংশ এবং নির্দিষ্ট কেস ফিল্ড)
• Assumptions (শুধুমাত্র যদি ইনপুট অনুপস্থিত)

এটি পর্যালোচনাকে দ্রুত করে এবং বিরোধের সময় ডিবাগ করতে সাহায্য করে।

4) চেকলিস্ট প্রম্পট প্যাটার্ন: ইনপুটস, সিদ্ধান্ত, ব্যতিক্রম, পরবর্তী ধাপ

প্রতিটি সময় একটি নির্দিষ্ট টেমপ্লেট ব্যবহার করুন:

• Inputs received: …
• Inputs missing: …
• Decision: approve/deny/needs-review
• Rule references: [R-…]
• Exceptions considered: …
• Next workflow step: update status / request info / escalate

টেমপ্লেটটি অস্পষ্টতা কমায় এবং মডেলকে অনিশ্চয়তার ক্ষেত্রে দৃঢ়ভাবে গ্যাপ সারফেস করতে প্রণোদিত করে।

সিদ্ধান্তগুলো বাস্তব ডেটায় গ্রাউন্ড করার জন্য টুল ও রিট্রিভাল ব্যবহার

একটি LLM মজারভাবে উত্তর লিখতে পারে এমনকি যখন এটি গুরুত্বপূর্ণ বিষয়গুলো অনুপস্থিত। সেটি ড্রাফ্টিংয়ের জন্য ভাল, কিন্তু ব্যবসায়িক-নিয়ম সিদ্ধান্তের জন্য ঝুঁকিপূর্ণ। যদি মডেলকে একটি অ্যাকাউন্টের স্ট্যাটাস, কাস্টমারের টিয়ার, আঞ্চলিক ট্যাক্স রেট, বা সীমা ইতিমধ্যে কি পৌঁছেছে তা অনুমান করতে হয়, আপনি আত্মবিশ্বাসী দেখানো ভুল পাবেন।

টুলগুলো এটি সমাধান করে: “প্রথমে প্রমাণ ফেচ করুন, তারপর সিদ্ধান্ত নিন”—এই দুই-ধাপ প্রক্রিয়ায় রূপান্তর করে যুক্তি।

মডেলকে সৎ রাখার সাধারণ টুলগুলো

রুল ও ওয়ার্কফ্লো-ভিত্তিক সিস্টেমে কয়েকটি সাধারণ টুলই বেশিরভাগ কাজ করে:

• ডাটাবেস লুকআপ (কাস্টমার প্রোফাইল, অ্যাকাউন্ট স্ট্যাটাস, এন্টাইটলমেন্ট, ইউসেজ টোটাল)
• পলিসি/রুল স্টোর (অনুমোদিত রুল টেক্সট, সংস্করণযুক্ত পদ্ধতি, ব্যতিক্রম তালিকা)
• ক্যালকুলেটর (ফি, প্রোরেশন, ট্যাক্স, সময় উইন্ডো, থ্রেশহোল্ড)
• টিকেটিং / ওয়ার্কফ্লো API (ওপেন কেস, SLA টাইমার, অনুমোদন, স্টেপ কমপ্লিশন)

চাবিকাঠি হলো মডেল অপারেশনাল ফ্যাক্টস "করছে না"—এটি তাদের অনুরোধ করছে।

রিট্রিভাল: কেবলমাত্র প্রাসঙ্গিক নিয়ম আনুন

আপনি সব নীতিগুলো কেন্দ্রীয় স্টোরে রাখলেও, সাধারণত সেগুলো পুরোপুরি প্রম্পটে পেস্ট করতে চান না। রিট্রিভাল সাহায্য করে কেবল বর্তমান কেসের জন্য সর্বাধিক প্রাসঙ্গিক ফ্রাগমেন্ট বাছাই করতে—উদাহরণস্বরূপ:

• কাস্টমারের প্ল্যানের জন্য ক্যান্সেলেশন নীতি
• দেশ/রাজ্যের উপর ভিত্তি করে আঞ্চলিক কমপ্লায়েন্স ক্লজ
• চার্জব্যাক_pending হলে প্রযোজ্য ব্যতিক্রম

এটি বিরোধ কমায় এবং মডেলকে আপডেটেড না হওয়া নিয়ম অনুসরণ করার বদলে গুরুত্বপূর্ণ অংশগুলোতে ফোকাস করায়।

টুল আউটপুটকে সিদ্ধান্ত প্রমাণে পরিণত করা

একটি নির্ভরযোগ্য প্যাটার্ন হলো টুল ফলাফলকে প্রমাণ হিসেবে ধরার নিয়ম। উদাহরণ:

1. Tool: get_account(account_id) → status="past_due", plan="Business", usage_this_month=12000
2. Tool: retrieve_policies(query="overage fee Business plan") → returns rule: “Overage fee applies above 10,000 units at $0.02/unit.”
3. Tool: calculate_overage(usage=12000, threshold=10000, rate=0.02) → $40.00

এখন সিদ্ধান্ত আর আন্দাজ নয়: এটি নির্দিষ্ট ইনপুটের ওপর ভিত্তি করে উপসংহার ("past_due", "12,000 units", "$0.02/unit")। পরবর্তীতে যদি অডিট করা হয়, আপনি দেখতে পারবেন কোন তথ্য ও কোন রুল সংস্করণ ব্যবহার করা হয়েছিল—এবং যখন কিছু পরিবর্তন করে ঠিক করতে হবে তখন সঠিক অংশ ঠিক করা যাবে।

সংকুচিত আউটপুট: অস্পষ্টতা কমাতে স্কিমা

ফ্রি-ফর্ম টেক্সট নমনীয় কিন্তু এটি ভাঙার সহজ উপায়। একটি মডেল "উচিত মনে হচ্ছে" এমন একটি উত্তর দিতে পারে যা অটোমেট করার অনুপযোগী ("ঠিক মনে হচ্ছে") বা ধাপে অসমঞ্জস ("approve" বনাম "approved")। সংকুচিত আউটপুট প্রতিটি সিদ্ধান্তকে একটি পূর্বানুমিত আকারে বাধ্য করে।

JSON হিসেবে সিদ্ধান্ত ফিরিয়ে দিন

একটি ব্যবহারিক প্যাটার্ন হলো মডেলকে একটি একক 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_review
• next_action: approve_case | deny_case | request_more_info | escalate_to_human

এনামগুলো থাকলে ডাউনস্ট্রীম সিস্টেমকে পরিভাষা, বিরচন, বা টোন ব্যাখ্যা করতে হবে না—তারা সহজে পরিচিত মানের উপর ব্রাঞ্চ করতে পারে।

কেন স্কিমা ওয়ার্কফ্লোকে সুরক্ষিত করে

স্কিমা গার্ডরেইল হিসেবে কাজ করে। তারা:

• প্রয়োজনীয় ফিল্ড দাবি করে "আংশিক উত্তর"কে প্রতিরোধ করে।
• কেন একটি সিদ্ধান্ত হয়েছে তা audit করতে সহজ করে (via reasons)।
• নির্ভরযোগ্য অটোমেশন সক্ষম করে: কিউ, নোটিফিকেশন, টাস্ক নির্মাণ সরাসরি decision ও next_action থেকে ট্রিগার করা যায়।
• ভ্যালিডেশন সমর্থন করে: আপনি স্কিমা-ম্যাচ না করলে আউটপুট প্রত্যাখ্যান করে মডেলকে আবার চেষ্টা করতে বলবেন।

ফলাফল হলো কম অস্পষ্টতা, কম এজ-কেস ব্যর্থতা, এবং ধারাবাহিকভাবে ওয়ার্কফ্লোতে চলাচল করে এমন সিদ্ধান্ত।

ভ্যালিডেশন কৌশল: রিলিজের আগে ভুল ধরুন

একটি ভাল প্রম্পট থাকা সত্ত্বেও মডেল "ঠিক শোনায়" এমনকি যখন এটি নীতিভঙ্গ করছে, প্রয়োজনীয় ধাপ ছাড়ছে, বা একটি মান উদ্ভাবিত করছে। ভ্যালিডেশন হলো সেই সেফটি নেট যা একটি সম্ভাব্য উত্তরকে নির্ভরযোগ্য সিদ্ধান্তে পরিণত করে।

প্রি-চেক: যুক্তি করার আগে ইনপুটগুলো যাচাই করুন

শুরুতে যাচাই করুন যে নিয়ম প্রয়োগের জন্য ন্যূনতম তথ্য আছে কি না। প্রি-চেকগুলো মডেল সিদ্ধান্ত নেওয়ার আগে চালান।

সাধারণ প্রি-চেকের মধ্যে রয়েছে প্রয়োজনীয় ফিল্ড (উদাহরণ: কাস্টমার টাইপ, অর্ডার টোটাল, অঞ্চল), মৌলিক ফরম্যাট (তারিখ, আইডি, মুদ্রা), এবং অনুমোদিত রেঞ্জ (নেগেটিভ নয়, শতাংশ 100% কাপে)। যদি কিছু ব্যর্থ করে, একটি স্পষ্ট, অ্যাকশেনযোগ্য ত্রুটি ফেরত দিন ("Missing 'region'; cannot choose tax rule set") মডেলকে আন্দাজ করতে দিয়ে না।

পোস্ট-চেক: সিদ্ধান্তকে নিয়মগুলোর বিরুদ্ধে যাচাই করুন

মডেল আউটপুট করার পরে যাচাই করুন যে সেটি আপনার রুল সেটের সাথে সঙ্গত।

ফোকাস করুন:

• Rule coverage: সিদ্ধান্ত কি প্রযোজ্য নিয়মগুলোকে উদ্ধৃত বা ম্যাপ করেছে, নাকি এটি কোনো বাধ্যত নীতি বাদ দিয়েছে?
• বিরোধ পরীক্ষা: আউটপুট কি ইনপুটের সাথে বিরোধ করছে (উদাহরণ: একটি হ্যার্ড-ব্লক শর্ত সত্য থাকলে "approved" বলা)?
• বর্ডার কেস: থ্রেশহোল্ডগুলোর উপর টেস্ট করুন (নির্দিষ্ট $10,000), খালি স্টেট ("no prior violations"), এবং "ঠিক একসাথে" পরিস্থিতি।

সেকেন্ড-পাস ভ্যালিডেশন: ইচ্ছাকৃত রিভিউ স্টেপ

প্রথম উত্তরের পরে একটি "সেকেন্ড পাস" যোগ করুন যা প্রথম উত্তরটি আবার মূল্যায়ন করে। এটি অন্য একটি মডেল কল হতে পারে বা একই মডেলকে একটি ভ্যালিডেটর-স্টাইল প্রম্পট দিয়ে চালানো হতে পারে যা কেবল কমপ্লায়েন্স চেক করে, সৃষ্টিশীলতা নয়।

সহজ একটি প্যাটার্ন: প্রথম পাস সিদ্ধান্ত + যুক্তি উৎপন্ন করে; সেকেন্ড পাস valid অথবা ব্যর্থতাগুলোর একটি স্ট্রাকচার্ড তালিকা দেয় (মিসিং ফিল্ড, লঙ্ঘিত বাধ্যবাধকতা, অস্পষ্ট নিয়ম ব্যাখ্যা)।

লগিং: সিদ্ধান্তগুলো অডিটযোগ্য করুন

প্রতিটি সিদ্ধান্তের জন্য ব্যবহৃত ইনপুট, রুল/পলিসি সংস্করণ, এবং ভ্যালিডেশন ফলাফল লগ করুন (সেকেন্ড-পাস ফলসহ)। যখন কিছু ভুল হয়, এটি আপনাকে ঠিক একই শর্ত পুনরায় তৈরি করতে দেয়, রুল ম্যাপিং ঠিক করতে সাহায্য করে, এবং সংশোধন নিশ্চিত করে—মডেল "কী বোঝাতে চেয়েছিল" অনুমান না করেই।

রুল ও ওয়ার্কফ্লো নির্ভরতার জন্য টেস্টিং ও মনিটরিং

রুল- এবং ওয়ার্কফ্লো-চালিত LLM ফিচারের টেস্টিং হলো "কী জেনারেট করল?" চেক করা নয়, বরং "এক সুচিন্তিত মানুষ ঠিক একই সিদ্ধান্ত নিত কি, সঠিক কারণ দেখিয়ে, প্রতিবার?" ভালো খবর: আপনি এটি ঐ একই শৃঙ্খলায় পরীক্ষা করতে পারেন যেভাবে প্রচলিত সিদ্ধান্ত লজিককে টেস্ট করেন।

ব্যবসায়িক নিয়মের ইউনিট টেস্ট (ছোট, পূর্বানুমানযোগ্য চেক)

প্রতিটি নিয়মকে একটি ফাংশনের মতো বিবেচনা করুন: ইনপুট দিলে একটি আউটকাম ফেরত দেয় যা আপনি assert করতে পারেন।

উদাহরণস্বরূপ, যদি আপনার একটি রিফান্ড নিয়ম থাকে "খোলা না থাকা আইটেমের জন্য 30 দিনের মধ্যে রিফান্ড অনুমোদিত", লক্ষ্যভিত্তিক কেস লিখুন:

• Order age = 10 days, unopened = true → approve
• Order age = 10 days, unopened = false → deny
• Order age = 45 days, unopened = true → deny
• পরিধির কেস: ঠিক 30 দিন, "unopened" ফিল্ড অনুপস্থিত, বিরোধপূর্ণ সংকেত

এই ইউনিট টেস্টগুলো অফ-বাই-ওয়ান সংখ্যা, মিসিং ফিল্ড, এবং "সহায়ক" মডেল আচরণ যা অজানা ভরাট করে তা ধরবে।

ওয়ার্কফ্লো জন্য সিনারিও টেস্ট (মাল্টি-স্টেপ, সময়-সচেতন পথ)

ওয়ার্কফ্লো তখনই ব্যর্থ হয় যখন স্টেট ধাপে ধাপে অসঙ্গত থাকে। সিনারিও টেস্টগুলো বাস্তব ভ্রমণ সিমুলেট করে:

• পথ টেস্ট: submit claim → request documents → documents received → decision
• সময়ভিত্তিক কোল: "7 দিনে প্রতিক্রিয়া না পেলে রেমাইন্ডার পাঠাও", "30 দিন পার হলে কেস বন্ধ করো"
• শাখা: কাস্টমার এস্কেলেট করে, পলিসি ব্যতিক্রম অনুরোধ করা, ডুপ্লিকেট কেস সনাক্ত

লক্ষ্য হলো যাচাই করা যে মডেল বর্তমান স্টেটকে সম্মান করে এবং কেবল অনুমোদিত ট্রানজিশনগুলোই নেয়।

“গোল্ড সেট” তৈরি করুন: পরিচিত-ভাল কেসগুলো

কিছু বাস্তব, অ্যানোনিমাইজড উদাহরণ সংগ্রহ করুন যেগুলোর সম্মত ফলাফল আছে (সংক্ষিপ্ত যুক্তিসহ)। এটি ভার্শন করা রাখুন এবং নীতি পরিবর্তন হলে রিভিউ করুন। একটি ছোট গোল্ড সেট (এমনকি 100–500 কেস) শক্তিশালী কারণ এটি অনিয়মিত বাস্তবতা—মিসিং ডেটা, অদ্ভুত ভাষা, বর্ডারলাইন সিদ্ধান্ত—প্রতিফলিত করে।

প্রোডাকশনে মনিটরিং (গ্রাহকের আগে ড্রিফট ধরুন)

সময়ভিত্তিক সিদ্ধান্ত বিতরণ ও মান সংকেত ট্র্যাক করুন:

• ড্রিফট: নীতির আপডেট ছাড়া অনুমোদন/অস্বীকৃতি হার বদলে যায়
• needs_review বা মানব হস্তক্ষেপে স্পাইক (প্রায়শই প্রম্পট, রিট্রিভাল, বা upstream ডেটা সমস্যা)
• পণ্য, অঞ্চল, বা পলিসি ক্যাটেগরির দ্বারা ত্রুটি ক্লাস্টার

মনিটরিংকে সেফ রোলব্যাকে জোড়া দিন: পূর্ববর্তী প্রম্পট/রুল প্যাক রাখুন, নতুন ভার্সন ফিচার ফ্ল্যাগ করুন, এবং মেট্রিক ক্ষুণ্ণ হলে দ্রুত রিভার্টের জন্য প্রস্তুত থাকুন। অপারেশনাল প্লেবুক ও রিলিজ গেটিং-এর জন্য দেখুন /blog/validation-strategies।

এই পাইপলাইনে Koder.ai-এর অবস্থান

আপনি উপরোক্ত প্যাটার্নগুলো বাস্তবায়ন করলে সাধারণত মডেলের চারপাশে একটি ছোট সিস্টেম বানাতে হয়: স্টেট স্টোরেজ, টুল কল, রিট্রিভাল, স্কিমা ভ্যালিডেশন, এবং একটি ওয়ার্কফ্লো অর্কেস্ট্রেটর। Koder.ai এমন ধরনের ওয়ার্কফ্লো-ব্যাকড অ্যাসিস্ট্যান্ট দ্রুত প্রোটোটাইপ ও ডিপ্লয় করার একটি ব্যবহারিক উপায়: আপনি চ্যাটে ওয়ার্কফ্লো বর্ণনা করে একটি কাজ করা ওয়েব অ্যাপ (React) প্লাস ব্যাকএন্ড সার্ভিসেস (Go with PostgreSQL) জেনারেট করতে পারেন, এবং স্ন্যাপশট ও রোলব্যাক ব্যবহার করে নিরাপদে ইটারেট করতে পারেন।

এটি ব্যবসায়িক-নিয়ম যুক্তির জন্য গুরুত্বপূর্ণ কারণ "গার্ডরেইল" প্রায়শই অ্যাপ্লিকেশনে থাকে, প্রম্পটে নয়:

• Planning mode আপনাকে ফ্লো ডিজাইন করতে সাহায্য করে (স্টেট, অনুমোদিত ট্রানজিশন, এস্কেলেশন পথ) বাস্তবায়নের আগে।
• Schema-constrained responses API বাউন্ডারিতে জোর করা যায়, তাই আপনি কেবল পার্সেবল সিদ্ধান্তই গ্রহণ করেন।
• Tooling hooks (DB রিড, পলিসি রিট্রিভাল, ক্যালকুলেটর, টিকিট আপডেট) স্পষ্ট এন্ডপয়েন্ট হিসেবে ইমপ্লিমেন্ট করা যায়, ফলে "প্রথমে প্রমাণ ফেচ, তারপর সিদ্ধান্ত" ডিফল্ট হয়।
• Source code export আপনাকে লক-ইনে পড়তে দেয় না যখন প্রোটোটাইপ প্রোডাকশন-সমালোচনীয় হয়ে ওঠে।

সীমাবদ্ধতা, সুরক্ষিত ব্যবহারের নির্দেশ, এবং কখন মানব রাখতে হবে

LLM গুলো দৈনন্দিন নীতিগুলো প্রয়োগে বিস্ময়কর হতে পারে, কিন্তু তারা নির্ধারিত রুল ইঞ্জিন নয়। তাদেরকে সিদ্ধান্ত-সহকারী হিসেবে দেখুন যা গার্ডরেইল চায়—না যে তারা চূড়ান্ত কর্তৃপক্ষ।

LLM গুলো কোথায় সংগ্রাম করে

তিনটি ব্যর্থতা মোড নিয়মভিত্তিক ওয়ার্কফ্লোতে বারবার দেখা যায়:

• দুর্লভ ব্যতিক্রম ও এজ-কেস: বছরেক বা তারও কম ফ্রিকোয়েন্সিতে ঘটা ব্যতিক্রম ট্রেনিং ডাটায় কম প্রতিনিধিত্ব পেতে পারে এবং যদি প্রম্পট বা রিট্রিভালে স্পষ্টভাবে না দেওয়া হয় সহজে মিস হয়ে যায়।
• দীর্ঘ কনটেক্সট ও 'গোপন' বিধিনিষেধ: যখন গুরুত্বপূর্ণ বিবরণ অনেক পৃষ্ঠায় বা বার্তায় ছড়িয়ে থাকে, মডেল সাম্প্রতিক বা বেশি স্মরণীয় টেক্সটকে অধিক গুরুত্ব দিতে পারে এবং আগের সীমাবদ্ধতাগুলো কম প্রয়োগ করতে পারে।
• সংখ্যাগত নির্ভুলতা ও কঠোর গণনা: টোটাল, প্রোরেশন, থ্রেশহোল্ড, রাউন্ডিং নিয়ম ক্ষীণ হয়ে যেতে পারে। গণনার জন্য টুল ব্যবহার করুন এবং মডেলকে ব্যবহার করা সংখ্যাগুলো উদ্ধৃত করতে বলুন।

কখন মানব পর্যালোচনা বাধ্যতামূলক করবেন

মানব পর্যালোচনা যোগ করুন যখন:

• ফলাফল উচ্চ ঝুঁকির (টাকা স্থানান্তর, কমপ্লায়েন্স, সেফটি, আইনি প্রতিশ্রুতি, কাস্টমার ক্রেডিট/যোগ্যতা)
• মডেল কম আত্মবিশ্বাস দেখায় (অনুমান করতে বলে, নীতি ভিত্তি না পায়, বা বিরোধপূর্ণ যুক্তি দেয়)
• কেসটি নতুন (নতুন পণ্য, নতুন অঞ্চল, নীতি সম্প্রতি পরিবর্তিত) বা অস্বাভাবিকভাবে সংবেদনশীল

এস্কেলেশন পথ যা গতিশীল রাখে

মডেলকে "কিছু বানাতে দেয়ার" পরিবর্তে পরিষ্কার পরবর্তী ধাপ নির্ধারণ করুন:

1. স্পষ্টকরণ প্রশ্ন করুন (মিসিং তারিখ, কাস্টমার টিয়ার, আইন ক্ষেত্র, অনুমোদন অবস্থা)।
2. নিষ্কাশিত তথ্য সহ একজন এজেন্টের কাছে রুট করুন, প্রস্তাবিত সিদ্ধান্ত ও উদ্ধৃতি সহ।
3. টিকিট তৈরি করুন যখন পলিসি অস্পষ্ট বা বিরোধপূর্ণ, যাতে সেটি সোর্সে ঠিক করা যায় (এবং পরে স্বয়ংক্রিয়ভাবে রিট্রিভ করা যায়)।

একটি সহজ অ্যাডপশন ফ্রেমওয়ার্ক

নিম্নলিখিতগুলোর বেশিরভাগের উত্তর যদি "হ্যাঁ" হয় তবেই LLM-কে রুল-ভিত্তিক ওয়ার্কফ্লোতে ব্যবহার করুন:

• আমরা কি অনুমোদিত পলিসি টেক্সট বা সিস্টেম ডেটা দিয়ে সিদ্ধান্ত গ্রাউন্ড করতে পারি?
• আমরা কি আউটপুটকে সংকুচিত করতে পারি (স্কিমা, অনুমোদিত অ্যাকশন, প্রয়োজনীয় উদ্ধৃতি)?
• আমরা কি ভ্যালিডেট করতে পারি (চেক, থ্রেশহোল্ড, ইউনিট টেস্ট, স্যাম্পলিং) কার্যকর করার আগে?
• ঝুঁকিপূর্ণ বা অনিশ্চিত কেসগুলোর জন্য কি আমাদের একটি মানব এস্কেলেশন পথ আছে?

যদি না হয়, LLM-কে খসড়া/সহকারী ভূমিকায় রাখুন যতক্ষণ না সেই নিয়ন্ত্রণগুলি বিদ্যমান হয়।