Embedding چیست؟

«جست‌وجوی برداری» در بحث‌های هوش مصنوعی زیاد شنیده می‌شود، اما برای تصمیم محصول باید دانست دقیقاً چه کاری می‌کند و کجا شکست می‌خورد. این مقاله embedding را با مثال کوچک توضیح می‌دهد، تفاوتش با جست‌وجوی کلیدواژه‌ای را نشان می‌دهد و معیار انتخاب و سنجش «مرتبط بودن» را می‌دهد.

منابع: دو صفحه از Google Machine Learning Crash Course (فضای embedding و به‌دست‌آوردن embedding)، راهنمای Vector embeddings از OpenAI و مقالهٔ Contextual Retrieval از Anthropic؛ همه در ۱۹ اکتبر ۲۰۲۶ خوانده شد. نام مدل‌ها، اندازهٔ بردارها و قیمت‌ها را عمداً نمی‌آوریم، چون تغییر می‌کنند و باید از مستندات روز ارائه‌دهنده گرفته شوند. مثال‌ها ساختگی‌اند. برای فهم ارتباط سرویس‌ها API چیست را ببینید.

embedding چیست؟

طبق Google، embedding «بردار نمایش داده در فضای embedding» است: هر مورد (کلمه، جمله، تصویر) با n عدد اعشاری نشان داده می‌شود. مثال خود Google: غذاها را روی یک بعد خیالی «ساندویچ‌بودن» بچینید؛ بعد «شیرینی‌بودن» را اضافه کنید و حالا هر غذا دو عدد دارد و «استرودل سیب» نزدیک دسر‌هاست و دور از ساندویچ‌ها. فاصلهٔ ریاضی بین دو نقطه به‌عنوان شباهت نسبی تفسیر می‌شود: نزدیک‌ترها در نمایش مدل از داده به هم مرتبط‌ترند. در عمل بعدها صدها یا هزاران‌اند و معنی هر بعد برای انسان قابل‌تفسیر نیست؛ Google هم می‌گوید موقعیت‌ها گاهی قابل‌فهم نیستند.

OpenAI تعریف کاربردی می‌دهد: embedding متن «رابطه‌مندی رشته‌های متنی» را می‌سنجد؛ کاربردها جست‌وجو (رتبه‌بندی بر پایهٔ ارتباط)، خوشه‌بندی، توصیه، تشخیص ناهنجاری و دسته‌بندی است و فاصلهٔ کم یعنی رابطه‌مندی زیاد.

جست‌وجوی برداری یا کلیدواژه؟

جست‌وجوی کلیدواژه‌ای واژه‌ها را تطبیق می‌دهد؛ جست‌وجوی برداری شباهت معنایی را. مثال: کاربر می‌نویسد «پول را پس بگیرم» و سند می‌گوید «بازگشت وجه». کلیدواژه‌ای ممکن است نیابد و برداری بیابد. در مقابل، Anthropic هشدار می‌دهد embeddingها روابط معنایی را عالی می‌گیرند اما ممکن است تطبیق دقیق را از دست بدهند: برای «Error code TS-999» ممکن است سندهای مربوط به کدهای خطا بیاید و همان کد نه؛ BM25 که تطبیق واژگانی است، برای شناسه‌ها و اصطلاحات فنی مناسب است و ترکیب هر دو (با rank fusion) پیشنهاد شده است.

ستون‌های «قوی/ضعیف» جمع‌بندی نویسنده از ساختار روش‌ها و نمونهٔ Anthropic است و بر آزمون ما تکیه ندارد؛ با داده خودتان بسنجید.

embedding ایستا و بافتی

Google تفاوتی را شرح می‌دهد که برای زبان مهم است: embedding ایستا (مثل word2vec) هر واژه را با یک نقطه نشان می‌دهد و همهٔ معناهای آن را در یک نقطه ادغام می‌کند؛ embedding بافتی برای هر واژه بسته به بافت نمایش‌های مختلف دارد. در متن فارسی واژه‌هایی با چند معنا زیادند؛ برای جست‌وجوی متن امروز مدل‌های بافتی رایج‌ترند، اما کیفیتشان برای فارسی را باید خودتان بسنجید: ما در منابع رسمی عدد مقایسه‌ای برای فارسی نیافتیم.

پارامترهایی که اهمیت دارند

• مدل embedding: مستندات هر ارائه‌دهنده چند مدل با کیفیت و هزینهٔ متفاوت دارد؛ نام و قیمت روز را از مستندات بخوانید. هزینهٔ فراخوانی بر اساس توکن ورودی است (OpenAI).
• طول بردار: OpenAI می‌گوید طول بردار پیش‌فرض به مدل بستگی دارد و می‌توان با پارامتر dimensions کوتاهش کرد؛ بردار بزرگ‌تر حافظه، ذخیره و محاسبهٔ بیشتری می‌خواهد. بنابراین طول را با کیفیت بازیابی و هزینهٔ ذخیره‌سازی بسنجید.
• معیار فاصله: رابطه‌مندی با فاصله سنجیده می‌شود؛ معیار مناسب را از مستندات همان مدل و پایگاه برداری بخوانید (ما ادعای ترجیح معیار خاصی نداریم).
• زبان و دامنه: مدلی که عمومی خوب است ممکن است برای اصطلاحات تخصصی یا فارسی ضعیف باشد.
• نسخهٔ مدل: embeddingهای مدل‌های مختلف با هم قابل‌مقایسه نیستند (احتیاط نویسنده)؛ تعویض مدل یعنی نمایه‌سازی مجدد.

سنجش مرتبط بودن

1. ۴۰ تا ۱۰۰ پرسش واقعی (عدد پیشنهادی نویسنده) را همراه سند درست برای هر پرسش آماده کنید؛ شامل پرسش‌های هم‌معنی، کد و شناسه و مبهم.
2. برای هر روش (کلیدواژه، برداری، ترکیبی) ببینید سند درست در k نتیجهٔ اول هست یا نه (recall@k) و چه کسری از نتایج مفیدند (precision@k).
3. خطاها را دسته‌بندی کنید: «هم‌معنی را نیافت»، «کد را نیافت»، «نتیجهٔ نامرتبط آورد».
4. نتیجه‌ها را بین روش‌ها و مدل‌ها مقایسه کنید و هزینه (توکن، ذخیره، تأخیر) را کنارش بگذارید.

مثال ساختگی نتیجه: کلیدواژه‌ای ۷ از ۱۰ پرسش کد را یافت و ۳ از ۱۰ پرسش هم‌معنی را؛ برداری برعکس؛ ترکیبی هر دو گروه را بهتر پوشش داد. این اعداد فرضی‌اند و فقط شیوهٔ تحلیل را نشان می‌دهند.

معیار انتخاب

آزمون کوچک یک‌روزه

پیش از سرمایه‌گذاری روی زیرساخت، یک آزمون کوچک بسازید (طرح پیشنهادی نویسنده). ۲۰۰ تکه از اسناد واقعی (مثلاً سؤالات متداول و راهنماها) انتخاب کنید و برای هر کدام embedding بگیرید؛ بردارها را حتی در یک فایل یا آرایهٔ ساده در حافظه نگه دارید. سپس ۳۰ پرسش واقعی بنویسید، برای هر پرسش نزدیک‌ترین پنج تکه را بیاورید و کنار جواب درست بگذارید. همین‌طور با یک جست‌وجوی کلیدواژه‌ای ساده (مثلاً تمام‌متن پایگاه داده) همان پرسش‌ها را اجرا کنید. اگر روش ساده در بیشتر موارد کافی است، لزومی به پایگاه برداری و پایپ‌لاین جدید نیست؛ اگر پرسش‌های هم‌معنی را مشخصاً از دست می‌دهد، نمونه‌های شکست را فهرست کنید و فقط به‌دنبال راه‌حلی بروید که آن‌ها را درست کند. این آزمون چند ساعت کار می‌برد و جلوی تصمیم‌گیری بر اساس تبلیغات یا حس را می‌گیرد؛ هزینهٔ آن فقط توکن‌های ورودی تعداد کمی متن است که طبق صفحهٔ رسمی ارائه‌دهنده باید محاسبه شود.

اشتباهات رایج

• فرض اینکه جست‌وجوی برداری همیشه از کلیدواژه بهتر است.
• انتخاب طول بردار و مدل بدون آزمون و بدون در نظر گرفتن هزینهٔ ذخیره.
• تعویض مدل embedding بدون نمایه‌سازی دوبارهٔ همه‌چیز.
• اعتماد به مدلی که برای فارسی آزموده نشده.
• مقایسهٔ روش‌ها بدون مجموعه‌سؤال یکسان.

چک‌لیست

1. انواع پرسش (کد، هم‌معنی، محاوره‌ای) شناسایی شده است.
2. مجموعه‌سؤال با سند درست داریم.
3. کلیدواژه‌ای، برداری و ترکیبی با همان مجموعه مقایسه شده‌اند.
4. مدل، طول بردار و معیار فاصله با داده فارسی خودمان آزموده شده‌اند.
5. هزینهٔ توکن، ذخیره و تأخیر ثبت شده است.
6. نسخهٔ مدل و برنامهٔ نمایه‌سازی مجدد مشخص است.

برای انتخاب فناوری انتخاب تکنولوژی و برای معیارهای انتشار نرم‌افزار آمادهٔ تولید را ببینید.

منابع و مراجع

• Embeddings: Embedding space and static embeddings — Google for Developers (Machine Learning Crash Course).
• Embeddings: Obtaining embeddings — Google for Developers (Machine Learning Crash Course).
• Vector embeddings — OpenAI API Docs، 2026-10-19.
• Introducing Contextual Retrieval — Anthropic Engineering، 2024-09-19.