Postgres কি আপনার RAG পাইপলাইন সামলাতে পারে?

• LLM একসঙ্গে সীমিত পরিমাণ টেক্সটই “দেখতে” পারে (কনটেক্সট উইন্ডো). ছোট কাজের ক্ষেত্রে এটি কার্যকর, কিন্তু কোনো নলেজ বেস হাজার হাজার পৃষ্ঠা জুড়ে বিস্তৃত হলে এটি ভেঙে পড়ে. কনটেক্সট উইন্ডো যথেষ্ট হলেও, “খড়ের গাদায় সূচ” ধরনের সমস্যার কারণে পারফরম্যান্স কমে যেতে পারে.

• RAG (‘retrieval augmented generation’) খুব প্রচলিত একটি প্যাটার্ন হয়ে উঠেছে, যেখানে আপনি একটি নলেজ বেস (ডকুমেন্ট, উইকি, নীতি, ট্রান্সক্রিপ্ট ইত্যাদি) বজায় রাখেন, ব্যবহারকারীর প্রশ্নে সেম্যান্টিক সার্চ চালিয়ে এমবেডিং ব্যবহার করে সবচেয়ে প্রাসঙ্গিক অংশগুলো উদ্ধার করেন, তারপর প্রশ্নের সঙ্গে সেই অংশগুলো LLM-এ দেন. এতে মডেলের কনটেক্সট সীমিত থাকে এবং সঠিকভাবে করা হলে উত্তরের মান বাড়তে ও হ্যালুসিনেশন কমতে পারে.

• pgai একটি ওপেন সোর্স Postgres এক্সটেনশন (এবং সহায়ক টুলিং), যা বিশ্বস্ত ওপেন সোর্স ডাটাবেস PostgreSQL-এর ওপর “AI retrieval” ওয়ার্কফ্লো তৈরি করতে সাহায্য করে.

• মূল ধারণা হলো স্ট্যান্ডার্ড RAG পাইপলাইনের আরও বেশি অংশ ডাটাবেস স্তরে নিয়ে যাওয়া (ইনজেস্ট → চাঙ্ক → এমবেড → এমবেডিং সিঙ্ক রাখা), এমবেডিংয়ের জন্য DB-কে “শুধু স্টোরেজ” হিসেবে না দেখা.

• প্রাথমিক ধারণা হলো এটি আশাব্যঞ্জক, তবে আপনার RAG পাইপলাইন সামান্য জটিল হলেই (বিশেষ করে চাঙ্কিং পদ্ধতি) এটি উপযুক্ত নয়. তবু আমরা এই প্রজেক্টটি নিবিড়ভাবে পর্যবেক্ষণ করব.

RAG তৈরির অনেক উপায় আছে, এবং বিভিন্ন RAG পদ্ধতির আরও দীর্ঘ বিশ্লেষণের জন্য পড়ুন কাস্টমাইজড RAG সমাধানের বাস্তব উদাহরণ. গুণমানকে গুরুত্ব দিলে ডিজাইনের পরিসর আশ্চর্যজনকভাবে গভীর হয়, আর সাধারণ “ডিফল্ট” পদ্ধতি সাধারণত এমন দেখায়:

1. একগুচ্ছ ডকুমেন্ট নিন.

2. সেগুলোকে চাঙ্কে ভাগ করুন. এটি করার অনেক পদ্ধতি আছে (যেমন অনুচ্ছেদ, সেম্যান্টিক গ্রুপিং).

3. প্রতিটি চাঙ্ককে একটি এমবেডিংয়ে রূপান্তর করুন.

4. এমবেডিংগুলো ভেক্টর ডাটাবেসে (Pinecone, Milvus ইত্যাদি) সংরক্ষণ করুন, অথবা pgvector ব্যবহার করে Postgres-এ রাখুন.

5. কোয়েরির সময় সবচেয়ে কাছের চাঙ্কগুলো খুঁজে বের করুন `এবং সেগুলো LLM-এ পাঠান (আবারও...এটি করারও অনেক উপায় আছে).

অনেক স্ট্যাকে ধাপ (1)–(3) ডাটাবেসের বাইরে অ্যাপ্লিকেশন কোড বা ডেটা পাইপলাইনে ঘটে, আর ডাটাবেস মূলত ব্যবহৃত হয়:

• এমবেডিং সংরক্ষণে

• এমবেডিং সার্চে

pgai একটি Postgres এক্সটেনশন (ওপেন সোর্স, Timescale-এর তৈরি) যা সেই সীমারেখা অস্পষ্ট করতে চায়.

এমবেডিংকে আপনার অ্যাপ ম্যানুয়ালি পরিচালনা করে এমন কিছু হিসেবে না দেখে, pgai এমবেডিংকে ডাটাবেসের একটি ফিচারে পরিণত করে:

• আপনি কোন টেবিল / ডকুমেন্ট এমবেড করতে চান তা নির্ধারণ করেন.

• আপনি এমবেডিং মডেল এবং চাঙ্কিং কৌশল নির্দিষ্ট করেন.

• বাকি কাজ pgai সামলায়, যার মধ্যে সোর্স ডেটা বদলালে এমবেডিং আপ টু ডেট রাখাও আছে.

প্রতিশ্রুতিটি আকর্ষণীয়:

• রক্ষণাবেক্ষণ করতে হয় এমন কাস্টম গ্লু কোড কম লাগে.

• মূল সোর্স ডকুমেন্ট বদলালে এমবেডিংগুলো ‘সতেজ’ রাখা সহজ হওয়ার কথা.

• Postgres/pgai আপনার রিট্রাই, রেট লিমিট, ব্যর্থ জব ইত্যাদি সামলায়.

পাঠক নোট: pgai-এর মধ্যে pgvector (আরেকটি খুব জনপ্রিয় RAG Postgres এক্সটেনশন) অন্তর্ভুক্ত থাকে. pgvector Postgres-এ ভেক্টর স্টোরেজ এবং সিমিলারিটি সার্চ যোগ করে, আর pgai তার ওপর ভিত্তি করে চাঙ্কিং, এমবেডিং এবং সেগুলো আপ টু ডেট রাখার মতো RAG পাইপলাইনের ধাপগুলো স্বয়ংক্রিয় করে.

1) চালু করা বেশ সহজ.

সবকিছু ঠিকঠাক চললে পথটি যথেষ্ট সহজ:

• Timescale-এর Docker ইমেজগুলো (ডাটাবেস + worker) টেনে নিন.

• আপনার এমবেডিং প্রোভাইডারের API key দিন.

• ভেক্টরাইজার ঘোষণা করতে অল্প কিছু SQL চালান (মূলত: কী এমবেড করবেন, কীভাবে চাঙ্ক করবেন, কোন মডেল ব্যবহার করবেন).

এরপর pgai একটি ভেক্টরাইজার worker-কে আলাদা প্রক্রিয়া হিসেবে চালানোর ব্যবস্থা করে এবং অ্যাসিঙ্ক্রোনাসভাবে এমবেডিং তৈরি করে (যেমন প্রতি 5 মিনিটে, বা আপনার পছন্দের যেকোনো ছন্দে).

2) পুরো পাইপলাইনটি ডাটাবেসের “কাছে” করা সুবিধাজনক.

pgai টেবিল থেকে কনটেন্ট ইনজেস্ট করতে পারে, এবং S3-এর মতো জায়গা থেকেও ডকুমেন্ট লোড করে সেগুলো পার্স + চাঙ্ক + এমবেড করতে পারে. এটি PDF, Markdown ইত্যাদি বিভিন্ন টেক্সট ডকুমেন্ট ফরম্যাটও সামলাতে পারে.

1) আপনি অনেক নিয়ন্ত্রণ হারান (আর RAG-এর কখনও কখনও নিয়ন্ত্রণ দরকার হয়).

উচ্চ-পারফরম্যান্স RAG সিস্টেমে (উত্তরের মান দিয়ে মাপলে) প্রায়ই কাস্টম পাইপলাইন দরকার হয়, যেমন:

• কাস্টম চাঙ্কিং নিয়ম (শিরোনাম ধরে, পৃষ্ঠা ধরে, বক্তার পালা ধরে ইত্যাদি)

• মেটাডেটা-সচেতন চাঙ্কিং (সেকশন শিরোনাম, টাইমস্ট্যাম্প, লেখক, ডক টাইপ রাখা)

• ডকুমেন্টের ধরনভেদে ভিন্ন এমবেডিং কৌশল

উপরের বিষয়ে pgai কম নমনীয়তা দেয়.

এই মুহূর্তে দুটি প্রধান চাঙ্কিং কৌশল আছে: character text splitter এবং recursive character text splitter, সঙ্গে no chunking অপশন. কিছু ব্যবহারের ক্ষেত্রে এটি যথেষ্ট হতে পারে, কিন্তু অনেক প্রোডাকশন RAG সিস্টেমে আরও কাস্টমাইজেশন দরকার হয়.

Timescale যদি Chonkie-এর মতো লাইব্রেরিতে দেখা আরও উন্নত চাঙ্কিং কৌশলগুলো অন্তর্ভুক্ত করতে পারে এবং একইভাবে Anthropic-এর contextual retrieval-এর মতো উন্নত ডিজাইন সমর্থন করে, তা দারুণ হবে.

2) টেক্সট-প্রথম, মাল্টিমোডাল নয়.

অনেক আকর্ষণীয় RAG সমস্যা এখন আর শুধু টেক্সটনির্ভর নয়:

• ডায়াগ্রামসহ PDF

• স্ক্রিনশট / ছবি

• অডিও রেকর্ডিং

• ভিডিও ক্লিপ

এই সোর্সগুলো থেকে আপনি “টেক্সট বের” করতে পারলেও, সেটি সত্যিকারের মাল্টিমোডাল এমবেডিং পাইপলাইনের সমান নয়.

pgai যদি শেষ পর্যন্ত মাল্টিমোডাল মডেল এন্ড-টু-এন্ড সমর্থন করে (S3-তে সংরক্ষিত বড় ছবি/অডিও/ভিডিওর জন্য load → chunk → embed, শক্তিশালী সিঙ্কিংসহ), সেটি আকর্ষণীয় হবে; কিন্তু আজ এটি একটি টেক্সট এমবেডিং ওয়ার্কফ্লো.

3) আপনার যদি শুধু এমবেডিং দরকার হয়, pgai দরকার নাও হতে পারে.

আপনার ইনজেশন পাইপলাইন যদি ইতিমধ্যেই কাস্টম হয় (বা হওয়া দরকার), তাহলে “টেক্সটের চাঙ্ক এমবেড করা” RAG-এর সবচেয়ে কঠিন অংশ নয়. সেই ক্ষেত্রে pgai সমস্যার সবচেয়ে সহজ অংশটিই সমাধান করছে.

আর আপনার নলেজ বেস যদি খুব ঘন ঘন আপডেট না হয়, স্বয়ংক্রিয় এমবেডিং সিঙ্কিংয়ের মূল্য তত বেশি নয়.

pgai ব্যবহার করার একটি বিশেষ ভালো উপায় হলো আপনার ডাটাবেসগুলোর ওপর একটি টেক্সট-টু-sql ইন্টারফেস ডিপ্লয় করা. pgai প্রদত্ত semantic_catalog মডিউল দিয়ে এটি বেশ সহজে করা যায়. শুধু এভাবে সেটআপ করুন:

1OPENAI_API_KEY="your-OpenAPI-key-goes-here"2TARGET_DB="postgres://user:password@host:port/database"3CATALOG_DB="postgres://user:password@host:port/database"

এবং pgai semantic-catalog create দিয়ে semantic catalog-কে আপনার ডেটা ডিকশনারি স্ক্র্যাপ করতে দিন. এটি আপনার datastore থেকে কনটেক্সট তৈরি করে, যা দেখতে কিছুটা এমন:

1---2schema: postgres_air3name: aircraft4type: table5description: Lists aircraft models with performance characteristics and unique codes.6columns:7- name: model8  description: Commercial name of the aircraft model.9- name: range10  description: Maximum flight range in kilometers.11- name: class12  description: Airframe class category or configuration indicator.13- name: velocity14  description: Cruising speed of the aircraft.15- name: code16  description: Three-character aircraft code serving as the primary key.17...

এই কনটেক্সট এখন pgai-এর জন্য বিভিন্নভাবে উপলভ্য;

সেম্যান্টিক সার্চের মাধ্যমে:

এই কোয়েরি আপনার natural language query-র সঙ্গে প্রাসঙ্গিক হতে পারে এমন টেবিল, ফাংশন এবং অন্যান্য অবজেক্ট ফেরত দেবে:

1pgai semantic-catalog search -p "Your natural language question goes here!"

র কনটেক্সট নিন:

এটি আপনার natural language query-র সঙ্গে সম্পর্কিত raw YAML context রেন্ডার করবে:

1pgai semantic-catalog search -p "Your natural language question goes here!" --render

SQL তৈরি করুন:

অথবা আপনার কোয়েরির উত্তর দিতে প্রয়োজনীয় raw SQL সরাসরি তৈরি করতে পারেন. আগের ধাপের কনটেক্সট একটি LLM-এ পাঠানো হয় এবং রেসপন্স তৈরি হয়:

1pgai semantic-catalog generate-sql -p "Your natural language question goes here!"

আপনি তুলনামূলক সহজ RAG সিস্টেম তৈরি করলে, নিচেরগুলো চাইলে pgai পরীক্ষা করে দেখা মূল্যবান:

• আপনার system of record হিসেবে Postgres,

• ন্যূনতম গ্লু কোড,

• যে এমবেডিংগুলো স্বয়ংক্রিয়ভাবে সিঙ্ক থাকে,

• আপনার ডাটাবেসে টেক্সট-টু-SQL প্রয়োগের দ্রুত উপায়,

• নতুন RAG টুল এবং Postgres এক্সটেনশন নিয়ে পরীক্ষা-নিরীক্ষা করা.

আপনার RAG পাইপলাইনে নিচের কোনোটি দরকার হলে pgai নিয়ে অপেক্ষা করাই সম্ভবত ভালো:

• ভারী কাস্টম ইনজেশন বা চাঙ্কিং লজিক

• ভিন্ন পার্সিং চাহিদাসম্পন্ন অনেক ধরনের ডকুমেন্ট

• মাল্টিমোডাল এমবেডিং

শেষে, pgvector যে ব্যাপকভাবে গ্রহণ করা হয়েছে তা স্পষ্ট হলেও, pgai একই মাত্রার আগ্রহ এবং তাই সমর্থন পাবে কি না তা পরিষ্কার নয় (যদিও এটি মাত্র প্রায় 18 মাস ধরে আছে).

pgai হলো RAG-এ একটি আকর্ষণীয় পদ্ধতি, যেখানে ডাটাবেসকে নিয়মিত অপারেশনাল কাজের বেশি অংশ করতে দেওয়া হয়, ফলে আপনার অ্যাপ্লিকেশন কোড সহজ হতে পারে.

এই মুহূর্তে এটি:

• সহজ RAG সেটআপে ব্যবহারযোগ্য এবং সত্যিই স্বাচ্ছন্দ্যদায়ক

• আরও কাস্টম পাইপলাইনের জন্য যথেষ্ট নমনীয় নয় (বিশেষ করে মাল্টিমোডাল)

এটি আশাব্যঞ্জক, এবং কীভাবে এগোয় তা দেখার জন্য অবশ্যই নজরে রাখার মতো.