معماری retrieval:
خب راجب مدلهای نهفته (embedding model) صحبت کردیم و راجب خود embedd و vector store هم آشنا شدیم
داستان بعدی ما از چه قراره
اینکه ما میخوایم دادههای زیاد و سنگین رو داخل vector store ذخیره کنیم
برای اینکار ما دو شیوه کلی داریم granular (دانه ریز) و coarse (دانه درشت)
دانه ریز یعنی ما سند و متن بزرگ رو به به چند متن کوچکتر بشکنیم و ذخیره کنیم
دانه درشت یعنی کل متن رو یکجا ذخیره کنیم
اما هر کدوم مشکلات و مزایای خودشون رو دارن تو حالت دانه ریز دقت بالاست ولی جواب جامع نیست
تو حالت دانه درشت دقت پایین ولی جواب جامع هستش
بهترین رویکرد ترکیب هر دو هستش
بعلاوه اینکه ذخیره متون بزرگ در vector store خودش ضعفهای زیادی هم داره
راهکار چیه؟؟؟
ما دانه درشت رو در بیرون از vector store ذخیره میکنیم و یک شماره ارجاع براش در نظر میگیریم و در vector store دانه ریز رو ذخیره میکنیم همراه شماره ارجاع، به این روش parentdocument گفته میشه
یعنی جستجوی مفهومی برای دقت بیشتر به vector store میدیم شماره ارجاع رو بر میداریم و کتن اصلی رو برمیگردونیم که تو این حالت هم دقت داریم و هم جامعیت
آیا میتونیم کاری کنیم تا جواب یکسری سوالات نامفهوم (کاربری که پرامپت خوب بلد نیست) بنویس رو هم بدیم، از یک رویکرد باحال استفاده میکنیم، خودمون یکسری متن کوتاه تولید میکنیم از روی متن برش خورده (دانه ریز) و اونم در vector store ذخیره میکنیم که به این روش multi vector retrieval گفته میشه
اگه نیاز داشته باشیم یک سیستم فیلترینگ هم داشته باشیم(متن بزرگ ما شامل چند بخش مختلف و متفاوت باشد مثلا در یک کتاب ما چندین فصل و موضوع متفاوت داریم) با استفاده از meta data میتونیم این رو هم هندل کنیم یعنی تو بخش متادیتامون برای هر متن دانه ریز یکسری تگ ذخیره میکنیم برای مثال -فصل سوم -لانگچین، با استفاده از meta data میتونیم این رو هم هندل کنیم
یک نکته vector store بسیار متفاوت از ذخیره سازهای گرافی هستش (دیتابیسهایی که روابط بزرگ و پیچیده رو نشون میدن، هر نود یک آبجکت و هر یال ارتباط اون آبجکت با سایر آبجکتهای موجود رو نشون میده) برای داشتن چیزی حدودی شبیه گراف هم در همین بخش metadata میتونیم یکسری روابط بین امبدینگ هارو هم مشخص کنیم برای مثال تومتادیتا یه همچین چیزی ذخیره میکنیم
relate:{"ai engineering", "hands on"}
@code_crafters
3August 11, 2026 277 1 2