Skip to main content

[AI] Introducing the Open Knowledge Format VS Vactor Database

 এই লেখাটিতে Open Knowledge Format (OKF) নামে একটি নতুন এবং সহজ ফাইল ফরম্যাট নিয়ে আলোচনা করা হয়েছে

এটি কী এবং কেন তৈরি করা হয়েছে?

আজকাল AI (যেমন ChatGPT, Gemini ইত্যাদি) অনেক কাজ করতে পারলেও একটি মূল সমস্যায় পড়ে—তাহলো সঠিক ও আপডেট তথ্যের অভাব (Context)।

একটি কোম্পানিতে বিভিন্ন তথ্য ছড়িয়ে-ছিটিয়ে থাকে (যেমন: ডেটাবেজ স্কিমা, কোড কমেন্ট, গুগল ড্রাইভের ফাইল, বিভিন্ন নোট)। AI এর জন্য এত জায়গা থেকে তথ্য এনে সঠিক উত্তর দেওয়া কঠিন হয়ে পড়ে।

এই সমস্যার সমাধানের জন্য গুগল ক্লাউড টিম Open Knowledge Format (OKF) নিয়ে এসেছে। এটি AI এবং মানুষ—উভয়ের জন্যই পড়া ও ব্যবহারের উপযোগী এক ধরনের উন্মুক্ত ফাইল স্ট্যান্ডার্ড (Open Standard)।


💡 OKF এর মূল বৈশিষ্ট্যসমূহ

OKF কোনো জটিল সফটওয়্যার বা সার্ভিস নয়, বরং এটি খুব সাধারণ কিছু ফাইল সাজানোর নিয়ম:

  • শুধুমাত্র Markdown (মার্কডাউন): সাধারণ টেক্সট ফাইল (.md), যা খুব সহজেই সাধারণ নোটপ্যাডে বা GitHub-এ পড়া ও এডিট করা যায়।

  • YAML Frontmatter (তথ্য চিহ্নিতকরণ): প্রতিটি ফাইলের ওপর ছোট একটি সেকশন থাকে, যেখানে টাইপ, শিরোনাম, ক্যাটাগরি, ট্যাগ ও সময় লেখা থাকে।

  • ফোল্ডার ও ফাইল নির্ভর: পুরো জ্ঞান বা তথ্যগুলোকে কিছু ফোল্ডার এবং ফাইলে সাজিয়ে রাখা হয়। ফাইলগুলোর মধ্যে স্বাভাবিক লিঙ্ক বা সংযোগের মাধ্যমে একটি নেটওয়ার্ক বা Graph তৈরি হয়।


🎯 OKF ব্যবহারের লাভ কী?

  1. AI এবং মানুষের জন্য সমান উপযোগী: ফাইলগুলো মানুষ সহজেই পড়তে পারে, আবার AI এজেন্টও কোনো রূপান্তর ছাড়া সরাসরি বুঝতে পারে।

  2. কোনো নির্দিষ্ট প্ল্যাটফর্মের ওপর নির্ভরতা নেই: এটি ব্যবহারে নির্দিষ্ট কোনো SDK বা সফটওয়্যারের প্রয়োজন নেই। যেকোনো সিস্টেমে এটি স্থানান্তর বা হোস্ট (যেমন Git) করা সম্ভব।

  3. নিয়মিত আপডেট করা সহজ: মানুষের যেমন একাধিক ফাইলের হিসাব রাখতে অলসতা লাগে, AI এজেন্টগুলো সহজেই ফাইলগুলো নিয়মিত পড়ে ও আপডেট রাখতে পারে (যাকে LLM-wiki প্যাটার্ন বলা হয়)।



OKF vs Vactor Database


Open Knowledge Format (OKF) এবং Vector Database—উভয়ই AI মডেলকে সঠিক তথ্য (Context) দেওয়ার জন্য ব্যবহার করা হয়। তবে নির্দিষ্ট কিছু ক্ষেত্রে Vector Database-এর চেয়ে OKF অনেক বেশি কার্যকর ও সুবিধাজনক।

🔑 মূল পার্থক্যসমূহ

বিষয়Vector Database (RAG)Open Knowledge Format (OKF)
কাজের পদ্ধতিটেক্সটকে গাণিতিক সংখ্যায় (Vector embeddings) রূপান্তর করে মিল খুঁজে বের করে।ফাইল ও ফোল্ডারে সাজানো সাধারণ Markdown ফাইল, যা লিঙ্কের মাধ্যমে যুক্ত থাকে।
ইনফ্রাস্ট্রাকচার (Infrastucture)ডেটাবেস সার্ভার, নতুন API এবং জটিল সেটআপের প্রয়োজন হয়।কোনো নতুন ইনফ্রাস্ট্রাকচার লাগে না। শুধু Git এবং ফোল্ডার স্ট্রাকচারই যথেষ্ট।
সম্পর্ক (Relationships)তথ্যের ভেতরের যৌক্তিক সম্পর্ক বুঝতে পারে না (শুধু শব্দের মিল খোঁজে)।হাইপারলিঙ্কের মাধ্যমে সরাসরি সঠিক সম্পর্ক যুক্ত থাকে (Knowledge Graph তৈরি করে)।
মানুষের পড়ার উপযোগিতামানুষ সরাসরি পড়ে বুঝতে পারে না (কোড বা সংখ্যার মতো থাকে)।১০০% মানুষের পাঠযোগ্য। যেকোনো টেক্সট এডিটরে সহজেই পড়া ও এডিট করা যায়।
খরচ ও স্পিডখরচ বেশি। ডেটা পরিবর্তন হলে বারবার Embedding চালাতে হয়।খরচ অনেক কম। AI এজেন্ট সরাসরি টেক্সট ফাইল পড়ে কাজ করতে পারে।

🚀 কেন OKF-কে Vector Database-এর চেয়ে সেরা বলা হচ্ছে?

১. কোনো জটিল ইনফ্রাস্ট্রাকচার বা অতিরিক্ত খরচ নেই

Vector Database চালাতে হলে বিশেষ ডেটাবেস সার্ভার সেটআপ করতে হয় এবং Embedding মডেল ব্যবহার করতে হয়, যা খরচ সাপেক্ষ।

  • OKF সুবিধা: OKF কোনো সফটওয়্যার বা সার্ভিস নয়। এটি সাধারণ ফাইলের মতো Git বা যেকোনো ফোল্ডারে রাখা যায়। ফলে কোনো বাড়তি খরচ বা সার্ভারের ঝামেলা নেই।

২. সঠিক ও যৌক্তিক সম্পর্ক বজায় রাখে

Vector Database বড় বড় লেখাকে ছোট ছোট টুকরো (Chunks) করে ফেলে। এর ফলে অনেক সময় AI দুটি তথ্যের মধ্যকার আসল সম্পর্ক বা লজিক হারিয়ে ফেলে।

  • OKF সুবিধা: OKF-এ একটি ফাইলের সাথে আরেকটি ফাইলের লিঙ্ক সরাসরি দেওয়া থাকে (যেমন: [customers](/tables/customers.md))। ফলে AI একদম মানুষের মতো এক পেজ থেকে অন্য পেজে গিয়ে পুরো বিষয়টি সঠিকভাবে বুঝতে পারে।

৩. মানুষ এবং AI—উভয়েই ব্যবহার করতে পারে

Vector Database-এর ডেটা মানুষ সরাসরি পড়ে বুঝতে বা ঠিক করতে পারে না। যদি AI ভুল উত্তর দেয়, তবে কোথায় ভুল হয়েছে তা খুঁজে বের করা বেশ কঠিন।

  • OKF সুবিধা: OKF ফাইলগুলো সাধারণ Markdown হওয়ায় মানুষ সহজেই এগুলো পড়তে ও আপডেট করতে পারে। আবার AI-ও কোনো রূপান্তর ছাড়াই সরাসরি তা বুঝতে পারে।

৪. তথ্য আপডেট করা খুব সহজ

Vector Database-এ কোনো তথ্য পরিবর্তন হলে পুরো ডেটাবেসকে আবার প্রসেস করতে হয় (Re-indexing), যা সময় ও টাকা দুটোই নষ্ট করে।

  • OKF সুবিধা: OKF-এ ফাইল আপডেট করা সাধারণ একটা নোট এডিট করার মতোই সহজ। এমনকি AI এজেন্ট নিজেই প্রয়োজন অনুযায়ী ফাইল তৈরি ও আপডেট করে নিতে পারে (LLM-wiki প্যাটার্ন)।

৫. নিখুঁত ফিল্টারিং করার ক্ষমতা

নির্দিষ্ট সময় বা ক্যাটাগরি অনুযায়ী ফিল্টার করতে Vector Database অনেক সময় ভুল করে।

  • OKF সুবিধা: OKF ফাইলের শুরুতে YAML মটাডেটা (যেমন: type, title, tags, timestamp) থাকে। এর ফলে AI খুব দ্রুত বুঝে ফেলে কোন ফাইলটি তার দরকার আর কোনটি দরকার নেই।


কখন OKF ব্যাবহার করা উচিত আর কখন Vactor Database ব্যাবহার করা উচিত ?


📂 কখন OKF (Open Knowledge Format) ব্যবহার করা উচিত?

যখন আপনার লক্ষ্য হয় ডেটা গুছিয়ে রাখা, নিখুঁত সম্পর্ক রক্ষা করা এবং এমন ডেটা ব্যবহার করা যা মানুষ ও AI উভয়েরই পড়া দরকার, তখন OKF ব্যবহার করা উচিত:

  • অভ্যন্তরীণ জ্ঞান বা ডকুমেন্টেশন (Internal Knowledge Base): কোম্পানির নীতিমালা, বিভিন্ন সিস্টেমের ডেটাবেস স্কিমা, রানবুক (Runbooks) বা API স্পেসিফিকেশনের মতো দরকারি তথ্যগুলো গুছিয়ে রাখতে।

  • যেখানে মানুষের সরাসরি নজরদারি প্রয়োজন: ডেটাগুলো যদি এমন হয় যা ডেভেলপার বা টিমের সদস্যরা মাঝে মাঝে নিজে পড়ে ঠিক করবেন বা আপডেট করবেন।

  • ভার্সন কন্ট্রোল বা গিট (Git) ভিত্তিক কাজ: পুরো নলেজ বেজটিকে যদি গিট রিপোজিটরিতে (যেমন GitHub) কোডের মতো ট্র্যাক করতে চান।

🔍 কখন Vector Database ব্যবহার করা উচিত?

যখন আপনার ডেটা অনেক বেশি বিশৃঙ্খল, বিশাল এবং সেগুলোকে হাতে বা উইকির মাধ্যমে গুছিয়ে রাখা অসম্ভব, তখন Vector Database ব্যবহার করা উচিত:

  • বিশাল ও অসংগঠিত ডেটা (Unstructured Data): হাজার হাজার গ্রাহকের ফিডব্যাক, দীর্ঘ পিডিএফ রিপোর্ট, মেডিকেল পেপার বা গ্রাহকদের সাথে চ্যাট করার পুরনো হিস্ট্রি।

  • রিয়েল-টাইম বা গতিশীল ডেটা: ডেটা যদি প্রতি মুহূর্তে পরিবর্তন হয় এবং সেগুলোকে তাৎক্ষণিকভাবে গাণিতিক উপায়ে (Semantic Search) খুঁজতে হয়।

  • স্বয়ংক্রিয় সার্চ সিস্টেম: যেখানে পুরো ডেটা সেটকে কাস্টমাইজ বা সাজানোর সময় নেই, বরং স্বয়ংক্রিয়ভাবে যেকোনো বিশাল টেক্সট থেকে উত্তর খুঁজে বের করা দরকার।



OKF ফাইল স্ট্রাকচার বানানোর পরে কিভাবে AI এর সাথে ইন্ট্রিগ্রেট করতে হয় ?

OKF (Open Knowledge Format) ফাইল স্ট্রাকচার তৈরি করার পর এটিকে AI-এর সাথে ইন্ট্রিগ্রেট করা বা কাজ লাগানোর পদ্ধতি খুবই সহজ, কারণ এর জন্য কোনো বিশেষ API বা জটিল ডেটাবেস সার্ভারের প্রয়োজন হয় না।

আপনার তৈরি করা OKF ফাইল বা ফোল্ডারটি AI-এর সাথে যেভাবে যুক্ত করতে পারেন:

১. AI এজেন্টকে প্রজেক্ট ফোল্ডারটি দেওয়া (Direct Access / Workspace Mount)

OKF-এর সবচেয়ে বড় সুবিধা হলো এটি সরাসরি ফাইল আকারে থাকে।

  • আপনি যদি এমন কোনো AI কোডিং অ্যাসিস্ট্যান্ট বা এজেন্ট ব্যবহার করেন (যেমন Claude, ChatGPT Plus, Cursor বা অন্যান্য এআই টুল), যা লোকাল ফোল্ডার বা Git রিপোজিটরি পড়তে পারে, তবে সরাসরি পুরো OKF ফোল্ডারের পাথ বা গিট লিংকটি AI-কে দিয়ে দিন।

  • AI এজেন্ট তখন কোডের মতো এই ফাইলগুলো (index.md, orders.md ইত্যাদি) নিজের মতো করে পড়তে পারে এবং হাইপারলিংক ধরে এক ফাইল থেকে অন্য ফাইলে নেভিগেট করে সঠিক তথ্য খুঁজে বের করতে পারে।

২. গিট রিপোজিটরি (GitHub) হিসেবে যুক্ত করা

  • আপনার OKF ফোল্ডারটি একটি GitHub রিপোজিটরিতে আপলোড করে রাখতে পারেন।

  • যখনই কোনো AI এজেন্ট বা কাস্টম LLM অ্যাপ্লিকেশন তৈরি করবেন, তখন সেটিকে ওই GitHub রিপোজিটরির রিড-অনলাই অ্যাক্সেস দিন। AI এজেন্টগুলো সহজেই ইন্টারনেট থেকে বা নির্দিষ্ট কোডবেজ থেকে Markdown ফাইলগুলো ফেচ (Fetch) করে নিতে পারে।

৩. প্রম্পটের মাধ্যমে কনটেক্সট দেওয়া (Context Injection)

ছোট প্রজেক্টের ক্ষেত্রে বা নির্দিষ্ট কোনো প্রশ্নের উত্তর পাওয়ার জন্য:

  • আপনার OKF ফোকাসড ফাইলটির ভেতরের টেক্সট কপি করে সরাসরি AI চ্যাটে দিয়ে বলতে পারেন:

    "নিচের OKF ফরম্যাটের ফাইলটি পড়ে আমার এই প্রশ্নের উত্তর দাও..."

  • যেহেতু OKF ফাইলে YAML মেটাডাটা ও Markdown বডি সুন্দরভাবে সাজানো থাকে, তাই AI খুব সহজেই এর ভেতরের লজিক, স্কিমা বা সম্পর্কগুলো বুঝতে পারে।

৪. কাস্টম AI অ্যাপ্লিকেশনে ব্যবহার (LLM-Wiki প্যাটার্ন)

আপনি যদি নিজে কোনো AI এজেন্ট বা অ্যাপ তৈরি করেন (যেমন Python দিয়ে):

  • আপনার অ্যাপ্লিকেশনের ব্যাকএন্ডে লোকাল ফাইল সিস্টেম থেকে সরাসরি .md ফাইলগুলো রিড করার ফাংশন যুক্ত করতে পারেন।

  • ব্যবহারকারী কোনো প্রশ্ন করলে AI এজেন্ট প্রথমে OKF ফোল্ডারের index.md বা নির্দিষ্ট ফাইলগুলো পড়ে প্রাসঙ্গিক ফাইল খুঁজে বের করে এবং সঠিক উত্তর তৈরি করে দেয়। Google Cloud-এর Knowledge Catalog-এর মতো আধুনিক টুলগুলো এখন সরাসরি OKF ইনপুট নিয়ে তাদের নিজস্ব AI এজেন্টদের সার্ভ করতে পারে।




আমার কাছে যদি ১০০ md ফাইল থাকে তাহলে লোকাল LLM এর অনেক সময় লাগবে না এইসব ফাইল রিড করতে ?



একসাথে ১০০টি বা তার বেশি Markdown (.md) ফাইল লোকাল LLM-কে পড়তে দিলে প্রসেসটি ধীরগতির হতে পারে এবং অনেক সময় মডেলের কনটেক্সট উইন্ডো (Context Window) ওভারফ্লো হয়ে যেতে পারে।

তবে Open Knowledge Format (OKF) বা এই ধরনের নলেজ সিস্টেমে পুরো ১০০টি ফাইল একসাথে বা প্রতিবার পুরো ফাইল রিড করার প্রয়োজন হয় না। নিচে এর সমাধানগুলো দেওয়া হলো:

১. এজেন্টরা যেভাবে কাজ করে (Progressive Disclosure)

OKF-এর ডিজাইনে Progressive Disclosure বা ধীরে ধীরে তথ্য উন্মোচনের পদ্ধতি ব্যবহার করা হয়:

  • পুরো ফোল্ডারের শুরুতে একটি index.md ফাইল থাকে, যেখানে মূল ক্যাটাগরি ও ফাইলগুলোর একটি ছোট্ট তালিকা বা ম্যাপ দেওয়া থাকে।

  • AI এজেন্ট প্রথমে শুধু এই ইনডেক্স ফাইলটি পড়ে এবং বোঝে যে আপনার কাঙ্ক্ষিত তথ্যটি কোন ফোল্ডার বা ফাইলে আছে।

  • এরপর এজেন্ট শুধু ওই নির্দিষ্ট ১ বা ২টি ফাইল ওপেন করে পড়ে। এর ফলে একসাথে ১০০টি ফাইল পড়ার দরকার হয় না।

২. সঠিক ফাইল খুঁজে বের করতে সাহায্য নেওয়া (Search / Indexing)

আপনার যদি মনে হয় লোকাল LLM-এর জন্য সরাসরি ফাইল পড়া স্লো হয়ে যাচ্ছে, তবে আপনি নিচের পদ্ধতিগুলো ব্যবহার করতে পারেন:

  • RAG বা লোকাল সার্চ টুল: আপনি চাইলে সাধারণ ছোট একটি স্ক্রিপ্ট বা হালকা সার্চ টুল (যেমন ripgrep বা সাধারণ লোকাল ইমবেডিং/কী-ওয়ার্ড সার্চ) ব্যবহার করতে পারেন, যা ১০০টি ফাইল থেকে কি-ওয়ার্ড বা YAML frontmatter (যেমন tags, title) দেখে মুহূর্তেই সঠিক ফাইলটি খুঁজে AI-কে ধরিয়ে দেবে।

  • YAML Frontmatter ফিল্টারিং: OKF ফাইলের উপরে থাকা মেটাডাটা দেখে AI প্রোগ্রামমেটিক্যালি ফিল্টার করে ফেলতে পারে কোন ফাইলগুলো অপ্রাসঙ্গিক, ফলে রিডিং টাইম অনেক কমে যায়।

Comments

Post a Comment

Popular posts from this blog

WSGI vs ASGI: What Every Django Developer Should Know !

  If you've been developing with Django, you've probably come across WSGI (Web Server Gateway Interface), the trusted friend of all traditional, synchronous web apps. But in this fast-moving, real-time world, you may have also heard about its dynamic, asynchronous cousin ASGI (Asynchronous Server Gateway Interface). WSGI (Web Server Gateway Interface): 1. The OG (original) Django interface, designed for synchronous HTTP requests. 2. Perfect for blogs, CMS, e-commerce, and standard web apps. 3. Uses servers like Gunicorn or uWSGI. 4. Limited to handling one request at a time. ASGI (Asynchronous Server Gateway Interface): 1. The modern, scalable interface designed for asynchronous web apps. 2. Ideal for handling WebSockets, HTTP/2, and real-time features like chat apps. 3. Built for high concurrency; uses Uvicorn, Daphne, or similar ASGI servers. 4. Allows you to leverage Python’s async and await for non-blocking code. When to Choose What: WSGI: Traditional apps where synchronou...
Post a Comment
Read more

How Django stores passwords

  Django Password Django provides a flexible password storage system and uses PBKDF2 by default. Django saves the password as below. <algorithm>$<iterations>$<salt>$<hash> example of a Hashed password stored in database: pbkdf2_sha256$390000$LCm33kvO7rbjbZhwJA90Sf$xfuGOzl/MJyUxqWNhsNdSThaQUvn1EjEfxZ48HA8HF4= Those are the components used for storing a User’s password,separated by the dollar-sign character and consist of:  1. The hashing algorithm 2. The number of algorithm iterations (work factor) 3. The random salt 4. The resulting password hash.  Most password hashes include a salt along with their password hash in order to protect against rainbow table attacks. Example of Making Hashed password: Here’s a simplified overview of how Django handles password storage: 1. Password Creation or Change : # When someone creates a new account or decides to change their password, Django takes their chosen password and performs a process called hashing. Has...
Post a Comment
Read more

Django pk vs id

 Django pk VS id If you don’t specify primary_key=True for any fields in your model, Django will automatically add an IntegerField to hold the primary key, so you don’t need to set primary_key=True on any of your fields unless you want to override the default primary-key behavior. The primary key field is read-only. If you change the value of the primary key on an existing object and then save it, a new object will be created alongside the old one Example: class UserProfile ( models . Model ): name = models . CharField ( max_length = 500 ) email = models . EmailField ( primary_key = True ) def __str__ ( self ): return self . name suppose we have this model. In this model we have make email field as primary key. now django default primary key id field will be gone. It'll remove from database. we can not query as   UserProfile.objects.get(id=1) after make email as primary key this query will throw an error.  Now we have to use pk  Us...
Post a Comment
Read more