৪৬টি রিপোজিটরির মাধ্যমে একটি নলেজ গ্রাফ তৈরি করা
আমি রায়ান, airCloset-এর CTO।
আমি code-graph তৈরি করতে তিন মাস ব্যয় করেছি। এটি একটি একক নলেজ গ্রাফ যা একাধিক সার্ভিস জুড়ে ৪৬টি রিপোজিটরির সমন্বয় ঘটায়।
অনেকে মনে করেন যে আপনি আপনার সমস্ত কোড একটি AI-কে দিয়ে প্রশ্ন করতে পারেন। এটি দুটি কারণে ব্যর্থ হয়:
- Context windows: আপনি ৪৬টি রিপোজিটরির বছরের পর বছর ধরে জমে থাকা কোড একটি প্রম্পটে ফিট করতে পারবেন না।
- Hallucination: সম্পর্কগুলো অনুমান করার চেষ্টা করার সময় AI ভুল করে। এটি সংযোগগুলো মিস করে।
এটি সমাধান করতে, আমি একটি 'source of truth' তৈরি করতে static analysis ব্যবহার করেছি।
চ্যালেঞ্জ: সীমানা অতিক্রম করা
একটি বড় codebase বেশ অগোছালো হয়। একটি API পাঁচটি ভিন্ন রিপোজিটরি থেকে কল করা হতে পারে। একটি ডাটাবেস টেবিল তিনটি ভিন্ন সার্ভিস দ্বারা ব্যবহৃত হতে পারে।
আপনি যদি কেবল একটি রিপোজিটরির দিকে তাকান, তবে আপনি পুরো চিত্রটি দেখতে পাবেন না। এটি বিপজ্জনক। আপনি যদি কোড পরিবর্তন করেন এবং এর প্রকৃত প্রভাবের পরিধি (blast radius) দেখতে না পান, তবে আপনি সিস্টেমটি ভেঙে ফেলতে পারেন।
আমার পদ্ধতিটি কোডকে syntax trees-এ পার্স করার জন্য tree-sitter ব্যবহার করে। কিন্তু tree-sitter একা রিপোজিটরির সীমানা অতিক্রম করতে পারে না।
এটি সমাধান করতে আমি boundary nodes তৈরি করেছি।
এটি যেভাবে কাজ করে:
- আমরা tree-sitter ব্যবহার করে একটি রিপোজিটরির ভেতরের সম্পর্কগুলো বের করি।
- আমরা types এবং variables সমাধান করতে TypeScript Compiler API ব্যবহার করি।
- টুলগুলো যে ডায়নামিক কেসগুলো মিস করে, সেগুলো হ্যান্ডেল করতে আমরা Gemini ব্যবহার করি।
AI-কে অনুমান করতে বলার পরিবর্তে, আমরা তাকে তথ্য দিই। আমরা তাকে বলি: "এই API-টি Repo X থেকেও কল করা হয়।" এটি hallucination প্রতিরোধ করে।
কঠিন অংশ: ফ্রেমওয়ার্কের জঙ্গল (The Framework Zoo)
আসল লড়াই ছিল এই সীমানাগুলো বের করা। প্রতিটি ফ্রেমওয়ার্ক ভিন্ন ভিন্ন উপায়ে সীমানা নির্ধারণ করে।
একটি টিম NestJS decorators ব্যবহার করে। অন্যটি Express routes ব্যবহার করে। অন্যটি raw jQuery ব্যবহার করে। প্রতিটি কোডে ভিন্ন ভিন্ন কাঠামো তৈরি করে।
এটি কার্যকর করতে আমাদের নিচের বিষয়গুলোর জন্য কাস্টম পার্সার (custom parsers) তৈরি করতে হয়েছে:
- NestJS এবং TypeORM
- Express এবং Fastify
- AngularJS এবং Redux
- বিভিন্ন path-alias schemes
আমাদের লক্ষ্য ছিল ৯৯% নির্ভুলতা। যদি আমাদের connection rate মাত্র ৯০% হয়, তবে AI ১০% সংযোগ মিস করবে। একটি প্রোডাকশন সিস্টেমে, সেই ১০%-এর মধ্যেই বাগগুলো লুকিয়ে থাকে।
আমরা এখন প্রতিদিন একটি চেক চালাই। যদি আমাদের connection rate ৫%-এর বেশি কমে যায়, তবে আমরা একটি অ্যালার্ট পাই। এটি নতুন কোড প্যাটার্ন আমাদের পার্সারগুলোকে নষ্ট করে ফেললে তা শনাক্ত করতে সাহায্য করে।
বর্তমান সীমাবদ্ধতাগুলো
গ্রাফটি নিখুঁত নয়।
- সার্চ করা কঠিন। সার্চ শুরু করার জন্য প্রায়ই আপনাকে একটি ফাংশনের নাম জানতে হবে।
- Node explosion। একটি পাথ অনুসরণ করলে হাজার হাজার ছোটখাটো, অপ্রয়োজনীয় হেল্পার ফাংশন (helper functions) চলে আসতে পারে।
- রক্ষণাবেক্ষণ (Maintenance)। আমাদের স্ট্যাকে প্রতিবার যখন একটি নতুন ফ্রেমওয়ার্ক আসে, আমাদের একটি নতুন পার্সার লিখতে হয়।
এটি পার্ট ১। পার্ট ২-এ, আমি এই ঘাটতিগুলো পূরণের জন্য তৈরি করা service-product-graph (SPG) লেয়ার নিয়ে আলোচনা করব।
ঐচ্ছিক লার্নিং কমিউনিটি: https://t.me/GyaanSetuAi