پشته GraphRAG شما دو پایگاه داده است. باید یکی باشه

اکثر سیستم های GraphRAG امروزه با حداقل دو لایه ذخیره سازی ساخته می شوند.

یک سیستم بردارها را ذخیره می کند.

سیستم دیگری روابط را ذخیره می کند.

پایگاه داده برداری به سوالاتی مانند:

کدام تکه ها، موجودیت ها، اسناد یا مفاهیم از نظر معنایی به این پرس و جو نزدیک هستند؟

پایگاه داده گراف به سوالاتی مانند:

این موجودات چگونه به هم مرتبط هستند و چه مسیرهایی این رابطه را توضیح می دهند؟

این معماری کار می کند، اما یک مشکل مهم ایجاد می کند:

پیوند بین بازیابی معنایی و استدلال گراف در خارج از پایگاه داده اتفاق می افتد.

معمولاً این پیوستن در کد برنامه، کد هماهنگ یا یک گردش کار عامل اتفاق می‌افتد. برنامه مطابقت های برداری را بازیابی می کند، آن شناسه ها را به پایگاه داده گراف می فرستد، پیمایش را انجام می دهد، گره های بیشتری دریافت می کند و سپس از یک LLM می خواهد که پاسخ نهایی را جمع آوری کند.

کار می کند.

اما ایده آل نیست.

زیرا هنگامی که اتصال به خارج از پایگاه داده حرکت می کند، برنامه ریز پرس و جو کنترل خود را از دست می دهد.

این سیستم دیگر نمی تواند جستجوی برداری، پیمایش نمودار، فیلتر کردن، رتبه بندی و الگوریتم های نمودار را با هم بهینه کند. هر لایه فقط بخشی از مشکل را می بیند.

این مشکل معماری است که ما در حال بررسی آن هستیم نمودار سامیاما.

Samyama Graph یک پایگاه داده گراف برداری بومی Rust است که برای GraphRAG، نمودارهای دانش، حافظه عامل هوش مصنوعی و تجزیه و تحلیل روابط در مقیاس بزرگ طراحی شده است.

گرد هم می آورد:

• پرس و جو گراف به سبک OpenCypher
• جستجوی برداری
• الگوریتم های نمودار
• دسترسی سازگار با Redis
• زمان اجرا Rust تک باینری

ایده ساده است:

پیمایش نمودار و جستجوی برداری همیشه نباید در سیستم های جداگانه زندگی کنند. برای بسیاری از بارهای کاری GraphRAG، آنها به یک موتور تعلق دارند.

چرا GraphRAG به چیزی بیش از جستجوی برداری نیاز دارد

جستجوی برداری در شباهت معنایی بسیار خوب است.

می‌تواند متن، موجودیت‌ها یا اسنادی را پیدا کند که «احساس نزدیکی» به یک پرس و جو دارند. این برای RAG بسیار مفید است.

اما جستجوی برداری به تنهایی روابط را درک نمی کند.

برای مثال، اگر کاربر بپرسد:

کدام کارآزمایی‌های بالینی با یک دارو، یک مسیر، و یک وضعیت از طریق حمایت از ادبیات زیست پزشکی مرتبط هستند؟

یک سیستم جستجوی برداری ممکن است اسناد مربوطه را بازیابی کند. اما به طور طبیعی جواب نمی دهد:

• کدام دارو به چه شرایطی مرتبط است؟
• کدام مسیر آنها را به هم پیوند می دهد؟
• کدام مقاله این رابطه را پشتیبانی می کند؟
• کدام کارآزمایی بالینی مرتبط است؟
• کدام مسیر از طریق نمودار دانش پاسخ را توضیح می دهد؟

اینها سوالات نموداری هستند.

یک نمودار می تواند موجودیت ها و روابط را به طور مستقیم نشان دهد:

Drug -> targets -> Protein
Protein -> participates_in -> Pathway
Pathway -> associated_with -> Condition
Condition -> studied_in -> ClinicalTrial
Paper -> supports -> Relationship

اینجاست که GraphRAG از RAG اولیه قدرتمندتر می شود.

به جای بازیابی فقط متن مشابه، سیستم می تواند موجودیت های مرتبط را بازیابی کند و سپس بر روی روابط استدلال کند.

معماری رایج GraphRAG

یک معماری رایج GraphRAG به شکل زیر است:

User query
   ↓
Embedding model
   ↓
Vector database
   ↓
Application code / agent logic
   ↓
Graph database
   ↓
Application code / reranking
   ↓
LLM response

این عملی است، اما پیچیدگی را اضافه می کند.

برنامه باید تصمیم بگیرد:

• چند نتیجه برداری برای واکشی
• کدام شناسه ها را در نمودار ارسال کنیم
• چقدر باید پیمود
• کدام مسیرها مهم است
• نحوه ترکیب نمرات نمودار و نمرات برداری
• چگونه از بافت تکراری، نامربوط یا ضعیف جلوگیری کنیم
• چگونه توضیح دهیم که چرا زمینه نهایی انتخاب شده است

با گذشت زمان، لایه ارکستراسیون به موتور جستجوی سفارشی تبدیل می شود.

اما در واقع یک موتور پرس و جو نیست. معمولاً مدل هزینه، بهینه‌ساز یکپارچه و درک عمیقی از طرح داده در هر دو حالت بازیابی ندارد.

این بوی طراحی است.

اگر برنامه اتصال بین جستجوی برداری و پیمایش نمودار را انجام دهد، پایگاه داده دیگر مشکل بازیابی کامل را حل نمی کند.

یک شرط طراحی متفاوت

سامیاما گراف رویکرد متفاوتی دارد.

به جای اینکه نمودار و بردار را به عنوان ذخیره‌های جداگانه در نظر بگیرد، بررسی می‌کند که وقتی هر دو بخشی از یک موتور پایگاه داده هستند چه اتفاقی می‌افتد.

هدف پشتیبانی از گردش کار است که در آن توسعه دهندگان می توانند ترکیب کنند:

• بازیابی معنایی
• تطبیق الگوی نمودار
• پیمایش رابطه
• الگوریتم های نمودار
• فیلتر ساختاری

داخل یک سیستم

در عمل، این مهم است زیرا GraphRAG به ندرت فقط “نزدیک ترین تکه ها” را پیدا می کند.

یک پرس و جوی مفید GraphRAG اغلب بیشتر شبیه به این است:

مفاهیم مرتبط معنایی را پیدا کنید، سپس از طریق روابط قابل اعتماد گسترش دهید، بر اساس نوع موجودیت فیلتر کنید، بر اساس ساختار نمودار رتبه بندی کنید و یک مسیر قابل توضیح را برگردانید.

این یک مشکل بردار گراف است.

نه فقط یک مشکل برداری.

چرا یک موتور می تواند مفید باشد

نزدیک نگه داشتن پیمایش نمودار و جستجوی برداری به یکدیگر مزایای متعددی دارد.

1. کد ارکستراسیون کمتر

هنگامی که بردار و نمودار به طور جداگانه زندگی می کنند، کد چسب زیادی مورد نیاز است.

توسعه دهندگان باید منطق سفارشی بنویسند تا شناسه ها، امتیازها، ابرداده ها و فیلترها را بین سیستم ها جابجا کنند.

یک موتور می تواند آن سطح را کاهش دهد.

2. قابلیت توضیح بهتر

سیستم های GraphRAG نه تنها باید یک پاسخ را برگردانند.

آنها باید توضیح دهند که چرا آن پاسخ بازیابی شده است.

نمودارها به طور طبیعی قابل توضیح هستند زیرا می توانند مسیرها را نشان دهند:

Question
 -> matched entity
 -> related concept
 -> supporting source
 -> final answer context

این امر به ویژه در حوزه هایی مانند مراقبت های بهداشتی، مالی، امنیت سایبری، انطباق، و مدیریت دانش سازمانی مهم است.

3. مناسب تر برای داده های سنگین رابطه

برخی از داده ها به طور طبیعی متصل می شوند:

• دانش زیست پزشکی
• آزمایشات بالینی
• شبکه های کلاهبرداری
• وابستگی های زیرساختی
• معماری نرم افزار
• روابط زنجیره تامین
• نمودارهای دانش سازمانی
• حافظه عامل

برای این بارهای کاری، روابط فراداده اختیاری نیستند. آنها هسته اصلی مشکل هستند.

4. تجربه توسعه دهنده تمیزتر

یک پایگاه داده بردار گراف می تواند استدلال پشته را آسان تر کند.

به جای پرسیدن:

کدام پایگاه داده مالک این بخش بازیابی است؟

توسعه دهندگان می توانند بپرسند:

چه پرس و جوی بردار گراف را باید اجرا کنم؟

چرا زنگ؟

سامیاما گراف به زبان Rust نوشته شده است.

Rust برای زیرساخت پایگاه داده مناسب است زیرا کنترل قوی بر حافظه، عملکرد و همزمانی را بدون نیاز به زمان اجرا جمع آوری شده می دهد.

برای پایگاه داده گراف-بردار، این مهم است.

حجم کاری نمودار می تواند حافظه فشرده باشد. جستجوی برداری می تواند محاسباتی سنگینی داشته باشد. ترکیب هر دو در یک موتور مستلزم توجه دقیق به عملکرد و اجرای قابل پیش بینی است.

زنگ به ما یک پایه قوی برای آن جهت می دهد.

آنچه سامیاما گراف امروز پشتیبانی می کند

سامیاما گراف در حال حاضر بر روی موارد زیر تمرکز دارد:

• پرس و جو گراف به سبک OpenCypher
• جستجوی برداری مبتنی بر HNSW
• الگوریتم های نمودار
• دسترسی به پروتکل سازگار با Redis
• استقرار تک باینری
• راه اندازی محلی مبتنی بر داکر
• نمودار دانش و بارهای کاری به سبک GraphRAG

این تلاش نمی کند که همه پایگاه داده ها به طور همزمان باشد.

هدف این است که برای توسعه دهندگانی که نیاز به استدلال داده های متصل و بازیابی معنایی در یک سیستم دارند مفید باشد.

جایی که امروز کم است

سامیاما گراف هنوز در حال رشد است و ما می خواهیم در این مورد شفاف باشیم.

امروز چند محدودیت مهم:

• پشتیبانی OpenCypher هنوز کامل نشده است
• محصول و اکوسیستم هنوز در حال تکامل هستند
• نمونه ها، ادغام ها و آموزش ها در حال گسترش هستند
• برخی ادعاهای بزرگتر به سبک معیار نیاز به پشتیبانی تکرارپذیری عمومی بیشتری دارند

ما بر این باوریم که زیرساخت منبع باز زمانی اعتماد را به دست می آورد که نقاط قوت و شکاف های فعلی مشخص باشد.

با Samyama Graph چه چیزی می توانید بسازید؟

Samyama Graph زمانی مفید است که برنامه شما هم به استدلال داده های متصل و هم به بازیابی معنایی نیاز دارد.

مثالها عبارتند از:

• سیستم های GraphRAG که جستجوی برداری را با پیمایش نمودار ترکیب می کنند
• برنامه های کاربردی نمودار دانش برای داده های سازمانی، تحقیقاتی، مراقبت های بهداشتی و عملیاتی
• حافظه عامل هوش مصنوعی که در آن موجودیت ها، ابزارها، اقدامات و زمینه به عنوان یک نمودار ذخیره می شوند
• نمودارهای زیست پزشکی و بالینی در مقالات، آزمایشات، مسیرها، داروها و شرایط
• نمودارهای تقلب و تحقیق برای کشف رابطه و تجزیه و تحلیل الگو
• نمودارهای زیرساخت و وابستگی برای تجزیه و تحلیل تاثیر و کاوش ریشه
• تجزیه و تحلیل گراف در مقیاس بزرگ با استفاده از الگوریتم های گراف داخلی

آن را به صورت محلی امتحان کنید

می توانید Samyama Graph را با Docker اجرا کنید:

docker run -d -p 6379:6379 -p 8080:8080 ghcr.io/samyama-ai/samyama-graph:latest

سپس با یک کلاینت Redis ارتباط برقرار کنید:

redis-cli -p 6379

یک نمودار ساده ایجاد کنید:

GRAPH.QUERY mydb "CREATE (a:Person {name: 'Alice'})-[:KNOWS]->(b:Person {name: 'Bob'})"

پرس و جو کن:

GRAPH.QUERY mydb "MATCH (a)-[:KNOWS]->(b) RETURN a.name, b.name"

چرا ما این را می سازیم

ما معتقدیم که نسل بعدی برنامه های کاربردی هوش مصنوعی به چیزی بیش از بازیابی متن نیاز دارند.

آنها نیاز خواهند داشت:

• جستجوی معنایی
• روابط ساختار یافته
• پیمایش نمودار
• مسیرهای قابل توضیح
• حافظه بر موجودیت ها و رویدادها
• رتبه بندی از نظر شباهت و ساختار

به همین دلیل است که ما در حال ساخت سامیاما گراف هستیم.

نه به عنوان “فقط یک پایگاه داده برداری دیگر.”

نه به عنوان “فقط یک پایگاه داده گراف دیگر.”

اما به عنوان یک پایگاه داده گراف-بردار برای توسعه دهندگانی که GraphRAG، نمودار دانش و زیرساخت های هوش مصنوعی را می سازند.

منبع باز

Samyama Graph منبع باز در GitHub است:

https://github.com/samyama-ai/samyama-graph

اگر این پروژه برای GraphRAG، نمودار دانش یا زیرساخت های هوش مصنوعی مفید است، ستاره GitHub به توسعه دهندگان بیشتری کمک می کند آن را کشف کنند.

ما همچنین از بازخورد، مسائل، مثال‌ها و مشارکت‌های توسعه‌دهندگانی که روی پایگاه‌های داده نمودار، جستجوی برداری، زیرساخت Rust، RAG و عوامل هوش مصنوعی کار می‌کنند، استقبال می‌کنیم.