Channels

Top 100 Trending New

Categories

Crypto Gaming News Entertainment Music Sports Tech Gambling Bots and mini apps Finance Business Education Lifestyle Health Travel Auto Fashion Jobs Dating Deals and shopping

Stickers

Stickers Emoji Themes Wallpapers

Bots Gifts Tools

Currency

$ USD ₽ RUB € EUR ₴ UAH ₸ KZT ₺ TRY zł PLN ₪ ILS AED AED R$ BRL Rp IDR RM MYR ¥ JPY ₩ KRW CN¥ CNY

Theme

Português (Brasil)

Bahasa Indonesia

Беларуская

Українська

Channels Categories Stickers Bots Gifts Tools

Premium Wiki Glossary Legal

Notifications Settings Log in

CodeCrafters: post #1011 — TG.ME

CodeCrafters@Code_Crafters · 711 subscribers Open in TelegramOpen

t.me/Code_Crafters/1011

2

July 20, 2026 290 2

More from this channel

Thought of the day from Stoic philosopher Seneca: *Associate with those who will make a better man of you. Welcome those whom you yourself can improve* #موقت 29·Aug 25

این کتاب کوبرنتیز رو حتما بخونید، سبکه و خیلی سریع مفاهیم کلی کوبرنتیز رو بهتون انتقال میده @code_crafters 139·Aug 24 Semantic Search و Vector Databaseها در متن‌های قبلی درباره‌ی Embedding صحبت کردیم و با چند تکنیک برای افزایش Performance و دقت جستجو آشنا شدیم. اما یک سؤال مهم وجود دارد: آیا دقت بالاتر در Search الزاماً به معنی کیفیت بالاتر پاسخ است؟ لزوماً نه. در Semantic Search ما به دنبال معنا هستیم، اما وقتی Query کاربر پیچیده‌تر می‌شود، صرفاً پیدا کردن نزدیک‌ترین Embeddingها نمی‌تواند کیفیت پاسخ را تضمین کند. برای مثال ممکن است یک Query به چند مفهوم مختلف اشاره کند و یک Vector Search ساده، اسناد مرتبط با هر مفهوم را پیدا کند، اما نتواند بهترین ترکیب از اطلاعات را برای پاسخ نهایی در اختیار LLM قرار دهد. اینجاست که صرفاً بهینه‌سازی Embedding یا Vector Search دیگر کافی نیست و باید سراغ الگوهای پیشرفته‌تر برویم. دو مورد مهم: Hybrid Search ترکیب Semantic/Vector Search و Keyword Search برای اینکه هم مفهوم Query و هم کلمات و عبارات دقیق آن را در نظر بگیریم. Reranking بعد از اینکه چندین Document اولیه را با Search پیدا کردیم، یک مرحله‌ی دوم برای رتبه‌بندی مجدد آن‌ها انجام می‌دهیم تا مرتبط‌ترین Documents در بالاترین رتبه قرار بگیرند. در نتیجه Pipeline ما می‌تواند چیزی شبیه این باشد: Query → Vector Search + Keyword Search → Hybrid Search → Reranking → Context → LLM اما بحث فقط Search نیست. وقتی با داده‌های حجیم، Big Data و داده‌های چندوجهی (Multimodal) مثل Text، Image، Audio و Video سروکار داریم، انتخاب Storage و Data Architecture نیز اهمیت بیشتری پیدا می‌کند. اینجاست که ابزارهایی مانند LanceDB مطرح می‌شوند. LanceDB یک Vector Database/AI Data Platform مبتنی بر Lance است که برای Workloadهای AI و داده‌های Embedding طراحی شده و قابلیت‌هایی مانند: * Semantic / Vector Search * Hybrid Search * Metadata Filtering * مدیریت داده‌های Multimodal * کار با حجم بالای داده * و استفاده از Storageهایی مانند Local Filesystem و Object Storageهایی مثل S3 را فراهم می‌کند. البته این به معنی آن نیست که PostgreSQL، Chroma یا Elasticsearch در حجم بالا دیگر قابل استفاده نیستند. هرکدام برای Workload و معماری خاصی مناسب هستند. بنابراین مسئله اصلی دیگر فقط این نیست که: «چطور Search را دقیق‌تر کنیم؟» بلکه سؤال مهم‌تر این است: «چطور یک Retrieval Architecture طراحی کنیم که بتواند اطلاعات درست را از بین حجم زیادی از داده، با توجه به معنا، Keyword، Metadata و Context پیدا کند؟» و این دقیقاً جایی است که مفاهیمی مثل: Embedding → Semantic Search → Hybrid Search → Reranking → Context Optimization → RAG در کنار یکدیگر قرار می‌گیرند. @code_crafters 170·Aug 17 معماری 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 290·Aug 11 فرض کنید جمله‌ی زیر را داریم: «من گرسنه هستم.» این جمله برای انسان کاملاً قابل فهم است، اما کامپیوتر در ابتدا آن را فقط به‌عنوان یک رشته (String) از کاراکترها می‌بیند و هیچ درکی از مفهوم آن ندارد. برای اینکه کامپیوتر بتواند مفهوم متن را درک کند، از یک Embedding Model استفاده می‌کنیم. این مدل متن را به یک لیست از اعداد تبدیل می‌کند؛ برای مثال: [0.1, 1.0, -0.75] به این لیست از اعداد Vector (بردار) گفته می‌شود. این بردار در واقع مختصات متن در یک فضای n بعدی است؛ یعنی هر عدد یکی از ابعاد این فضا را نشان می‌دهد و مجموع این اعداد مشخص می‌کند که متن در چه موقعیتی از فضای معنایی قرار گرفته است. حالا جمله‌ی دیگری را در نظر بگیرید: «من غذا می‌خواهم.» برای انسان، مفهوم این جمله به «من گرسنه هستم» نزدیک است، اما کامپیوتر هنوز این موضوع را نمی‌داند. بنابراین این جمله نیز توسط همان Embedding Model به یک بردار تبدیل می‌شود؛ مثلاً: [0.1, 1.2, -0.65] اکنون کامپیوتر این دو بردار را با هم مقایسه می‌کند. اگر فاصله‌ی آن‌ها کم باشد (یا شباهت آن‌ها زیاد باشد)، نتیجه می‌گیرد که این دو متن از نظر معنایی به یکدیگر نزدیک هستند، حتی اگر دقیقاً از کلمات یکسانی استفاده نکرده باشند. اگر هزاران یا میلیون‌ها متن را به همین روش به بردار تبدیل کنیم، مجموعه‌ای از بردارها خواهیم داشت که می‌توان آن‌ها را به‌صورت یک ماتریس در نظر گرفت؛ ماتریسی که هر سطر آن بردار مربوط به یک متن است. از آنجا که این بردارها معمولاً صدها یا هزاران بعد دارند، به این محیط فضای چندبعدی (Vector Space) گفته می‌شود. برای ذخیره و جستجوی سریع این حجم از بردارها از Vector Store یا Vector Database استفاده می‌کنیم. این سیستم‌ها با استفاده از الگوریتم‌های جستجوی شباهت، نزدیک‌ترین بردارها را در میان میلیون‌ها بردار با سرعت بالا پیدا می‌کنند. در این فرآیند، Embedding Model وظیفه‌ی تبدیل متن به بردار را بر عهده دارد و خروجی آن Embedding نامیده می‌شود. سپس این بردارها در یک Vector Store ذخیره می‌شوند تا بتوان بر اساس شباهت معنایی بین آن‌ها جستجو انجام داد. @code_crafters 320·Aug 7

An open web layer over public Telegram — search, stats and channel reading right in your browser, no account, no install.

Not affiliated with Telegram FZ-LLC; all data comes from public sources.

Catalog

Top channels Categories Countries Search

Content

Stickers Emoji Gifts Themes Wallpapers

Help

Tools Wiki Glossary Blockchain Safety Premium Advertisers Advertising

© 2026 TG.ME · G.Media network· Updated 08/23/2026 · v0.2.0 · ba12f6a

Privacy Terms DMCA & complaints Report a violation

Similar channels

Python BackendHub8.1K subscribers

Sadra Codes4K subscribers

سید فرندز / برنامه نویسی / هک و امنیت / تکنولوژی12.3K subscribers

Linuxor ?29.8K subscribers

‌BenDev2.9K subscribers

CleverDevs10.1K subscribers

DevTwitter | توییت برنامه نویسی31.4K subscribers

Seyed Mahdi Notes2.5K subscribers