46 ریپوزٹریز (repositories) پر مشتمل ایک نالج گراف (knowledge graph) کی تعمیر

میں ریان ہوں، airCloset کا CTO۔

میں نے code-graph بنانے میں تین ماہ صرف کیے۔ یہ ایک واحد نالج گراف ہے جو متعدد سروسز کے 46 ریپوزٹریز کو یکجا کرتا ہے۔

بہت سے لوگ سمجھتے ہیں کہ آپ اپنا تمام کوڈ AI کو دے کر سوالات پوچھ سکتے ہیں۔ یہ دو وجوہات کی بنا پر ناکام ہو جاتا ہے:

  • کانٹیکسٹ ونڈوز (Context windows): آپ 46 ریپوزٹریز کے برسوں پر محیط کوڈ کو ایک ہی پرامپٹ (prompt) میں نہیں سما سکتے۔
  • ہالوسینیشن (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 سے بھی کال کیا جاتا ہے۔" یہ ہالوسینیشن سے بچاتا ہے۔

مشکل حصہ: فریم ورک کا جنگل (The Framework Zoo)

اصل جنگ ان حدود کو نکالنے کی تھی۔ ہر فریم ورک حدود کو مختلف طریقے سے لکھتا ہے۔

ایک ٹیم NestJS decorators استعمال کرتی ہے۔ دوسری Express routes استعمال کرتی ہے۔ کوئی اور خام jQuery استعمال کرتا ہے۔ ہر ایک کوڈ میں ایک مختلف ڈھانچہ تخلیق کرتا ہے۔

اسے کام کرنے کے قابل بنانے کے لیے، ہمیں ان کے لیے کسٹم پارسرز (custom parsers) بنانے پڑے:

  • NestJS اور TypeORM
  • Express اور Fastify
  • AngularJS اور Redux
  • مختلف path-alias schemes

ہمیں 99% درستگی کا ہدف رکھنا تھا۔ اگر ہماری کنکشن ریٹ صرف 90% ہے، تو AI 10% رابطوں کو مس کر دیتا ہے۔ پروڈکشن سسٹم میں، وہ 10% وہ جگہ ہے جہاں بگ (bugs) چھپے ہوتے ہیں۔

اب ہم روزانہ چیک کرتے ہیں۔ اگر ہماری کنکشن ریٹ 5% سے زیادہ گرتی ہے، تو ہمیں الرٹ مل جاتا ہے۔ اس سے پتہ چل جاتا ہے کہ کب نئے کوڈ پیٹرنز ہمارے پارسرز کو خراب کر رہے ہیں۔

موجودہ حدود

گراف مکمل طور پر درست نہیں ہے۔

  • تلاش مشکل ہے۔ اکثر اپنی تلاش شروع کرنے کے لیے آپ کو فنکشن کا نام معلوم ہونا ضروری ہے۔
  • نوڈ ایکسپلوژن (Node explosion)۔ ایک راستے پر چلنے سے ہزاروں چھوٹے، غیر ضروری ہیلپر فنکشنز شامل ہو سکتے ہیں۔
  • دیکھ بھال (Maintenance)۔ جب بھی ہمارے اسٹیک میں کوئی نیا فریم ورک شامل ہوتا ہے، ہمیں ایک نیا پارسر لکھنا پڑتا ہے۔

یہ حصہ 1 ہے۔ حصہ 2 میں، میں اس سروس-پروڈکٹ-گراف (SPG) لیئر پر بات کروں گا جو میں نے ان خامیوں کو دور کرنے کے لیے بنائی ہے۔

Source: https://dev.to/ryantsuji/building-one-knowledge-graph-across-46-repositories-with-static-analysis-part-1-egm

Optional learning community: https://t.me/GyaanSetuAi