সরাসরি সম্পাদনার বদলে কেন পরিবারটি ChatGPT দিয়ে একটি PDF টুল লিখিয়ে নিল

একটি ছোট PDF সমস্যা কীভাবে মানুষ AI-কে কতটা বিশ্বাস করবে তার একটি উপযোগী পরীক্ষায় পরিণত হলো

সপ্তাহের আরও বাস্তবধর্মী AI কাহিনিগুলির একটি কোনো পণ্য উন্মোচন বা বেঞ্চমার্ক চার্ট থেকে আসেনি। এটি এসেছে একটি পারিবারিক workflow সমস্যার থেকে। ZDNET-এর ৫ জুনের একটি বিবরণে, ডেভিড গেভার্টজ জানান যে তিনি ChatGPT-কে সরাসরি একটি নথি পরিবর্তন করতে না বলে, বরং একটি command-line Python script লিখতে বলেছেন, যা কাজটি deterministic উপায়ে করতে পারে। লক্ষ্য ছিল হলুদ কাগজে ছাপা, স্ক্যান করা একটি choir booklet। উদ্দেশ্য ছিল হলুদ ব্যাকগ্রাউন্ড সরিয়ে দেওয়া, যাতে পাতাগুলি আরও স্পষ্টভাবে পুনর্মুদ্রণ করা যায় এবং সঙ্গীত সফটওয়্যারে আরও কার্যকরভাবে ব্যবহার করা যায়।

এই গল্পটিকে গুরুত্বপূর্ণ করে তুলেছে PDF পরিষ্কার করা নিজে নয়। সেটি হলো সেই যুক্তি, যা সমাধানের দিকে নিয়ে গিয়েছিল। ChatGPT-তৈরি PDF নিয়ে সরাসরি পরীক্ষা কাজ করেছিল, কিন্তু তাতে বিশ্বাসযোগ্যতার সমস্যা তৈরি হয়। যদি একটি generative মডেল sheet music-কে স্পর্শ করে, তবে কি সেটি নোট, লিরিক্স বা লেআউট সামান্য বদলে দিতে পারে? সাধারণ টেক্সটের ক্ষেত্রে সেই ঝুঁকি সহনীয় হতে পারে। সঙ্গীত অনুশীলনের ক্ষেত্রে নয়।

তাই মডেলকে সম্পাদক হতে বলার বদলে, পরিবারটি তাকে toolmaker হিসেবে ব্যবহার করল।

জেনারেটিভ আউটপুট থেকে deterministic workflow-এ

এই পরিবর্তনটি বাস্তব পরিবেশে AI সবচেয়ে কার্যকরভাবে কীভাবে ব্যবহার হতে পারে, সে বিষয়ে একটি বৃহত্তর শিক্ষা ধরে। Generative system শক্তিশালী, কিন্তু সেগুলি non-deterministicও, অর্থাৎ তাদের আউটপুট বদলাতে পারে এবং তারা এমন পরিবর্তন আনতে পারে যা কখনও উদ্দেশ্য ছিল না। যখন উৎসের প্রতি নিখুঁততা গুরুত্বপূর্ণ, তখন সেই অনিশ্চয়তাই বিশ্বাসের বাধা হয়ে দাঁড়ায়।

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

বিকল্প ছিল ChatGPT দিয়ে এমন software লিখিয়ে নেওয়া, যা একটি নির্দিষ্ট রূপান্তর করবে। একবার তৈরি হলে, script প্রতিবার একইভাবে কাজ করে, যতক্ষণ না কেউ code বদলায়। এতে কাজটি probabilistic generation থেকে procedural execution-এ চলে যায়। বহু বাস্তব ক্ষেত্রে, সেটাই “interesting demo” আর “usable tool”-এর পার্থক্য।

তাৎক্ষণিক ব্যবহারটি ছিল সাধারণ, আর সেটাই মূল কথা

স্ক্যান করা choir পাতাগুলি হলুদ stock-এ মুদ্রিত ছিল। সেগুলি হুবহু আবার ছাপলে হয় অনেক বেশি color ink লাগত, নয়তো black-and-white output-এ ধূসর background থেকে যেত। পাতাগুলিকে PlayScore 2-এর সঙ্গেও কাজ করতে হত, যা একটি music-reading app, তাই মানুষের পাশাপাশি মেশিনের জন্যও visual clarity জরুরি ছিল।

প্রথমে Photoshop বিবেচনা করা হয়েছিল, কিন্তু article বলছে, manual process খুব ঝামেলাপূর্ণ ছিল, কারণ প্রতিটি image-এর জন্য আলাদা slider adjustment দরকার পড়ত। এটি AI-সংশ্লিষ্ট আরেকটি পরিচিত প্যাটার্ন। Traditional software সমস্যা সমাধান করতে পারে, কিন্তু নিয়মিত ব্যবহারের জন্য শ্রমের খরচ খুব বেশি। AI সঠিকভাবে ব্যবহার করলে, ঠিক সেই নির্দিষ্ট কাজের জন্য একটি custom utility তৈরি করে সেটআপের ঝামেলা কমানো যায়।

যা তৈরি হলো, তা কোনো চটকদার consumer application নয়। এটি ছিল ছোট উদ্দেশ্যের একটি command-line Python tool। কিন্তু সেটাই উদাহরণটিকে গুরুত্বপূর্ণ করে তোলে। AI-এর প্রকৃত অর্থনৈতিক মূল্যর বড় অংশ আসতে পারে এমন সব অনাড়ম্বর, খুব নির্দিষ্ট software থেকে, যা গতকাল ছিল না, কারণ সেটি লিখতে কাজটির চেয়েও বেশি সময় লাগত।

বিশ্বাসের মডেল বদলাচ্ছে

AI নিয়ে গল্পগুলো সাধারণত এই দিকেই জোর দেয় যে model সরাসরি কী করতে পারে: লেখা, সারসংক্ষেপ, অঙ্কন, code লেখা, বা ফাইল নিজে থেকেই পরিচালনা করা। এই ঘটনাটি অন্য একটি trust model-এর দিকে ইঙ্গিত করে। ব্যবহারকারীরা AI-কে একটি পদ্ধতি প্রস্তাব করতে বা code তৈরি করতে দিতে স্বচ্ছন্দ হতে পারেন, কিন্তু মূল্যবান উৎস উপকরণের চূড়ান্ত রূপান্তরের জন্য তারা একটি স্বচ্ছ, পুনরাবৃত্তিযোগ্য tool-ই বেশি পছন্দ করতে পারেন।

এই পার্থক্য enterprise-এর পাশাপাশি পরিবারগুলির জন্যও গুরুত্বপূর্ণ। আইন, চিকিৎসা, আর্থিক ও আর্কাইভ সংক্রান্ত ক্ষেত্রে প্রশ্নটি শুধু এই নয় যে AI কোনো কাজ করতে পারে কি না। প্রশ্ন হলো, সিস্টেমটি traceability-সহ এবং এতটা আত্মবিশ্বাসের সঙ্গে তা করতে পারে কি না, যাতে পথে কোনো অনুমোদনহীন পরিবর্তন ঢুকে না পড়ে।

ফলে সবচেয়ে বাস্তবসম্মত AI workflow-টি অনেক সময় দুই ধাপের হতে পারে। প্রথমে, software creation-এর accelerator হিসেবে একটি model ব্যবহার করুন। তারপর, তৈরি হওয়া deterministic process-টি মূল files-এর উপর চালান। এতে code পর্যালোচনা বা output যাচাইয়ের প্রয়োজন শেষ হয় না, কিন্তু অনিশ্চয়তা কমে যায়।

আরেকটি AI trick-এর চেয়ে এটি কেন বেশি গুরুত্বপূর্ণ

এই anecdote-টিকে একটিমাত্র বুদ্ধিদীপ্ত life hack হিসেবে দেখে এগিয়ে যাওয়ার প্রলোভন থাকে। কিন্তু এটি আসলে generative AI adoption curve-এর একটি কেন্দ্রীয় সমস্যাকে ছুঁয়ে যায়: মানুষ শুধু সক্ষমতা চায় না। তারা নিয়ন্ত্রণযোগ্যতা চায়।

choir booklet উদাহরণটি বিশেষভাবে স্পষ্ট, কারণ ঝুঁকিটি সহজেই বোঝা যায়। পাতার একটি note বদলে গেলে, পুরো অনুশীলনের উদ্দেশ্য ব্যর্থ হয়। কিন্তু একই যুক্তি অনেক কাজের পরিবেশেও প্রযোজ্য, যেখানে documents, images বা data এমন অর্থ বহন করে, যা অক্ষুণ্ণ থাকতে হবে। ব্যবহারকারীরা প্রায়ই এমন একটি system পছন্দ করবেন, যা যাচাই করা যায়, পুনরায় চালানো যায় এবং scope-এ সীমিত থাকে, এমন একটি system-এর চেয়ে যা বেশি বুদ্ধিমান মনে হলেও কম পূর্বানুমেয়।

এর মানে এই নয় যে direct AI editing-এর কোনো স্থান নেই। বহু creative এবং low-stakes কাজের জন্য এটি দ্রুত ও পুরোপুরি গ্রহণযোগ্য। কিন্তু articleটি দেখায়, “model-ই file সামলাক” সবসময় সবচেয়ে ভালো উত্তর নয়। কখনও কখনও AI-এর সবচেয়ে ভালো ব্যবহার হলো কাজটির চূড়ান্ত ফল নয়, বরং তার চারপাশের boring infrastructure তৈরি করানো।

AI adoption-এর পরবর্তী ধাপের জন্য একটি কার্যকর pattern

ZDNET-এর গল্পটি তাই প্রভাব ফেলে, কারণ এটি এমন একটি pattern বর্ণনা করে, যা ছড়িয়ে পড়তে পারে। মানুষ increasingly AI ব্যবহার করবে অনুরোধমতো ছোট software utility বানাতে, বিশেষ করে যখন traditional tool খুব জটিল মনে হয় এবং পুরোপুরি generative workflow খুব ঝুঁকিপূর্ণ মনে হয়। এর ফলে AI কমে যায় না। এটি stack-এ এক ধাপ গভীরে সরে যায়, যেখানে এটি সুর বাজানোর বদলে যন্ত্র তৈরি করতে সাহায্য করে।

এটি দৈনন্দিন computing-এ model-গুলোর সবচেয়ে স্পষ্ট practical ভূমিকার একটি হতে পারে। তারা custom scripting-এর সময়ের খরচ কমাতে পারে, development-এর বিরক্তিকর অংশগুলো automate করতে পারে এবং সাধারণ ব্যবহারকারীদের জন্য এককালীন tool-ও সম্ভব করে তুলতে পারে। কিন্তু উৎস উপকরণ গুরুত্বপূর্ণ হলে, অনেকেই এখনও চূড়ান্ত কাজটিকে deterministic হিসেবেই দেখতে চাইবেন।

সেই অর্থে, PDF-এর গল্পটি আসলে হলুদ কাগজ বা choir practice নিয়ে নয়। এটি trust কীভাবে engineered হয়, তা নিয়ে। সবচেয়ে টেকসই AI workflow-গুলো হতে পারে সেগুলো, যা generative speed-এর সঙ্গে conventional software reliability মেলাতে পারে, যাতে ব্যবহারকারীরা দুটিরই সুবিধা পান, কিন্তু একটিকে অন্যটির সঙ্গে গুলিয়ে না ফেলেন।

এই নিবন্ধটি ZDNET-এর প্রতিবেদনের ওপর ভিত্তি করে। মূল নিবন্ধ পড়ুন.