اگر پایگاه داده‌ای با میلیون‌ها تکه متن مدیریت می‌کنید، احتمالاً هزینه زیرساخت شما بیشتر از آنکه به تعداد فراخوانی‌های API وابسته باشد، به اندازه بردارها گره خورده است. استفاده از مدل text-embedding-3-small با ابعاد پیش‌فرض ۱۵۳۶ یک نقطه شروع امن است، اما ممکن است گیگابایت‌های اضافی از حافظه و میلی‌ثانیه‌های حیاتی از تأخیر را هزینه شما کند.
بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که می‌گوید این کلمه «همسایه‌ی» چه کلمات دیگری است — متن را به لیستی از اعداد تبدیل می‌کند. آن لیست، یک بردار است. در مدل text-embedding-3-small، این لیست به‌طور پیش‌فرض ۱۵۳۶ عدد دارد. طبق مستندات OpenAI، اگر جمله‌ای مثل «درگاه‌های API به توسعه‌دهندگان در مسیریابی فراخوانی‌های مدل کمک می‌کنند» را ارسال کنید، مدل یک بردار برمی‌گرداند که معنای کل ورودی را نمایندگی می‌کند. بردار به این معنا نیست که برای هر کلمه یک عدد وجود داشته باشد؛ بلکه یک نمایش معنایی واحد برای کل متن ورودی شماست. برای اکثر توسعه‌دهندگان، تنظیمات پیش‌فرض تنها گزینه مورد استفاده است، اما در سیستم‌های تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — چالش اصلی از کیفیت تولید به بهره‌وری ذخیره‌سازی در مقیاس بالا تغییر کرده است.
تصور کنید توسعه‌دهنده‌ای ۱ میلیون تکه سند ذخیره می‌کند. در ابعاد پیش‌فرض ۱۵۳۶، او به حدود ۷.۷۲ گیگابایت فضای ذخیره‌سازی (با احتساب سربار ایندکس) نیاز دارد. با تغییر ابعاد به ۵۱۲، این نیاز به ۲.۵۷ گیگابایت می‌رسد؛ یعنی ۶۷٪ کاهش در نیازهای خام ذخیره‌سازی. شما سپس این بردارها را در یک پایگاه داده برداری مانند pgvector، Pinecone، Milvus، Weaviate، Chroma یا Qdrant ذخیره می‌کنید. هنگامی که کاربر جستجو می‌کند، شما پرس‌وجو (Query) را به بردار تبدیل کرده و آن را با بردارهای ذخیره شده مقایسه می‌کنید.
زمینه: درک مفهوم ابعاد
بر اساس مستندات رسمی OpenAI، مدل text-embedding-3-small پیش‌فرض ۱۵۳۶ و مدل text-embedding-3-large پیش‌فرض ۳۰۷۲ بُعد دارد. این مدل‌ها از یک پارامتر dimensions پشتیبانی می‌کنند که می‌تواند طول بردار خروجی را کاهش دهد.
ابعاد ۱۵۳۶ به دلیل پیش‌فرض بودن، بسیار محبوب است. این مقدار تعادلی عملی بین کیفیت و هزینه برای بسیاری از حجم‌های کاری جستجوی معنایی و RAG فراهم می‌کند. شما باید از این مقدار پیش‌فرض ۱۵۳۶ استفاده کنید اگر:
- در حال ساخت اولین سیستم بازیابی خود هستید.
- هنوز داده‌های ارزیابی (Evaluation Data) ندارید.
- مجموعه داده شما به اندازه کافی کوچک است که ذخیره‌سازی بردارها فشار مالی ایجاد نمی‌کند.
- کیفیت جستجو برای شما مهم‌تر از چند گیگابایت حافظه است.
- می‌خواهید در اولین عرضه، قطعات متحرک و پیچیدگی‌های فنی کمتری داشته باشید.
اگر اپلیکیشن شما هنوز در مراحل اولیه است، بزرگ‌ترین ریسک معمولاً اندازه بردار نیست. ریسک‌های واقعی تکه‌بندی (Chunking) بد، ارزیابی ضعیف بازیابی، نبود فیلترهای متادیتای لازم یا پرامپت‌های نامناسب هستند. ابتدا ساده شروع کنید و سپس بهینه‌سازی را پیش بگیرید.
سازوکار کاهش ابعاد
پارامتر dimensions در APIهای سازگار با OpenAI به شما اجازه می‌دهد بردارهای کوتاه‌تری درخواست کنید. برای مثال، به‌جای ۱۵۳۶، می‌توانید ۱۰۲۴، ۷۶۸ یا ۵۱۲ بُعد را درخواست کنید، مشروط بر اینکه ارائه‌دهنده شما از آن پشتیبانی کند.
بسیار مهم است که درک کنید چه چیزهایی تغییر می‌کند و چه چیزهایی ثابت می‌ماند:
- ذخیره‌سازی بردار: با کاهش ابعاد، کوچک‌تر می‌شود.
- حافظه ایندکس: با کاهش ابعاد، کوچک‌تر می‌شود.
- تأخیر جستجو: اغلب با ابعاد کمتر، کاهش می‌یابد.
- کیفیت بازیابی: در ۱۵۳۶ یک خط پایه قوی دارد؛ برای ابعاد کوچک‌تر باید تست شود.
- هزینه توکن ورودی API: معمولاً بدون تغییر می‌ماند.
آنچه معمولاً تغییر نمی‌کند، تعداد توکن‌های ورودی است که ارسال می‌کنید. قیمت‌گذاری APIهای Embedding معمولاً بر اساس توکن‌های ورودی است، نه اندازه نهایی بردار. این بدان معناست که ابعاد کوچک‌تر عمدتاً به ذخیره‌سازی، حافظه ایندکس و سرعت بازیابی کمک می‌کنند. آن‌ها راهی جادویی برای کاهش صورت‌حساب تولید Embedding نیستند.
ریاضیات ذخیره‌سازی: ۱۵۳۶ در برابر ۱۰۲۴ و ۵۱۲
هر عدد float32 از ۴ بایت استفاده می‌کند. اندازه خام بردار را می‌توان این‌گونه محاسبه کرد: vector_size_bytes = dimensions × 4.
برای یک بردار واحد:
- ۱۵۳۶ بُعد: ۶,۱۴۴ بایت (خط پایه)
- ۱۰۲۴ بُعد: ۴,۰۹۶ بایت (حدود ۳۳٪ کوچک‌تر)
- ۷۶۸ بُعد: ۳,۰۷۲ بایت (حدود ۵۰٪ کوچک‌تر)
- ۵۱۲ بُعد: ۲,۰۴۸ بایت (حدود ۶۷٪ کوچک‌تر)
وقتی مقیاس به ۱ میلیون تکه می‌رسد، ذخیره‌سازی خام float32 و سربار تخمینی ایندکس (حدود ۳۵٪) به این شکل است:
- ۱۵۳۶ بُعد: حدود ۵.۷۲ گیگابایت خام / ۷.۷۲ گیگابایت با ایندکس
- ۱۰۲۴ بُعد: حدود ۳.۸۱ گیگابایت خام / ۵.۱۵ گیگابایت با ایندکس
- ۷۶۸ بُعد: حدود ۲.۸۶ گیگابایت خام / ۳.۸۶ گیگابایت با ایندکس
- ۵۱۲ بُعد: حدود ۱.۹۱ گیگابایت خام / ۲.۵۷ گیگابایت با ایندکس
به همین دلیل است که ابعاد در مقیاس بالا اهمیت پیدا می‌کنند. یک تفاوت کوچک در هر بردار، هنگام ذخیره میلیون‌ها تکه، به هزینه واقعی زیرساخت تبدیل می‌شود.
ابزارهای محاسبه و مثال‌ها
برای تخمین این هزینه‌ها، می‌توانید از یک ابزار پایتون برای محاسبه گیگابایت خام و سربار ایندکس استفاده کنید. برای مثال، اگر ۱,۰۰۰,۰۰۰ سند با میانگین ۳۵۰ توکن در هر تکه داشته باشید، هزینه تولید Embedding با نرخ ۰.۰۲ دلار به ازای هر میلیون توکن، ۷ دلار خواهد بود. در حالی که هزینه تولید پایین می‌ماند، فضای ذخیره‌سازی به‌شدت تغییر می‌کند:
- ۱۵۳۶ بُعد: ۵.۷۲ گیگابایت خام / ۷.۷۲ گیگابایت ایندکس
- ۱۰۲۴ بُعد: ۳.۸۱ گیگابایت خام / ۵.۱۵ گیگابایت ایندکس
- ۷۶۸ بُعد: ۲.۸۶ گیگابایت خام / ۳.۸۶ گیگابایت ایندکس
- ۵۱۲ بُعد: ۱.۹۱ گیگابایت خام / ۲.۵۷ گیگابایت ایندکس
این موضوع درس مهمی را برجسته می‌کند: هزینه تولید می‌تواند کوچک بماند، اما هزینه پایگاه داده برداری و حافظه می‌تواند به‌سرعت رشد کند.
پیاده‌سازی و محدودیت‌ها
توسعه‌دهندگان می‌توانند از پارامتر dimensions استفاده کنند. با استفاده از یک فراخوانی استاندارد از طریق curl:
curl https://crazyrouter.com/v1/embeddings \ -H "Authorization: Bearer $CRAZYROUTER_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "text-embedding-3-small", "input": "Explain API gateway routing in one paragraph." }'
در سرویس Crazyrouter، شما فقط آدرس پایه (https://crazyrouter.com/v1) و کلید API را تغییر می‌دهید. پاسخ شامل یک آرایه برداری است که در تنظیمات پیش‌فرض، طول آن ۱۵۳۶ است.
با استفاده از SDK پایتون OpenAI، می‌توانید طول بردار را بررسی کنید یا ابعاد سفارشی درخواست کنید:
from openai import OpenAI
client = OpenAI(api_key="your-key", base_url="https://crazyrouter.com/v1")
# بررسی پیش‌فرض
response = client.embeddings.create(
model="text-embedding-3-small",
input="A vector database stores embeddings for semantic search",
)
vector = response.data[0].embedding
print(len(vector)) # معمولاً ۱۵۳۶
# درخواست ابعاد سفارشی
response = client.embeddings.create(
model="text-embedding-3-small",
input="Shorter embeddings can reduce vector database storage.",
dimensions=1024,
)
vector = response.data[0].embedding
print(len(vector)) # انتظار می‌رود: ۱۰۲۴
برای کاربران Node.js، الگو مشابه است و از بسته openai با تنظیم baseURL روی https://crazyrouter.com/v1 استفاده می‌شود.
یک محدودیت فنی حیاتی وجود دارد: شما نمی‌توانید ابعاد مختلف را در یک ایندکس واحد ترکیب کنید. پایگاه داده‌های برداری انتظار ابعاد ثابت برای هر مجموعه (Collection) را دارند. اگر جدول pgvector شما با vector(1536) ساخته شده باشد، تلاش برای درج یک بردار ۱۰۲۴-بعدی باعث شکست سیستم می‌شود.
برای مثال در pgvector، طرحواره شما ممکن است این‌گونه باشد:CREATE TABLE documents ( id bigserial PRIMARY KEY, content text, embedding vector(1536) );
اگر به ۱۰۲۴ تغییر وضعیت دهید، به ستون یا جدول متفاوتی نیاز دارید:CREATE TABLE documents_1024 ( id bigserial PRIMARY KEY, content text, embedding vector(1024) );
گردش کار ارزیابی
انتخاب بُعد مناسب باید بر اساس داده باشد، نه حدس و گمان. گردش کار توصیه شده شامل این مراحل است:
۱. انتخاب ۱۰۰ تا ۲۰۰ پرس‌وجوی واقعی کاربر.
۲. برچسب‌گذاری اسناد صحیح برای هر پرس‌وجو.
۳. ایجاد ایندکس‌های مجزا برای ابعاد ۱۵۳۶، ۱۰۲۴، ۷۶۸ و ۵۱۲.
۴. اجرای پرس‌وجوهای یکسان روی هر ایندکس.
۵. مقایسه نرخ بازیابی (recall@5 و recall@10)، تأخیر و حافظه.
با مقایسه این معیارها، می‌توانید کوچک‌ترین اندازه برداری را پیدا کنید که کیفیت بازیابی را به‌طور معناداری کاهش نمی‌دهد. این روش بسیار قابل‌اعتمادتر از خواندن بنچمارک‌های کلی است.
انتخاب بر اساس مورد استفاده
برنامه‌های مختلف نیازهای متفاوتی دارند. این نقاط شروع را در نظر بگیرید:
- نمونه اولیه / اپلیکیشن کوچک: ۱۵۳۶ (بیشینه کردن کیفیت در حین یادگیری)
- RAG اسناد پشتیبانی: ۱۵۳۶ یا ۱۰۲۴ (کیفیت مهم است، اما ذخیره‌سازی رشد می‌کند)
- جستجوی FAQ حجیم: ۱۰۲۴ (تعادل خوب برای تست)
- کش معنایی با حجم بالا: ۷۶۸ یا ۵۱۲ (سرعت و حافظه اولویت دارند)
- بازیابی حقوقی / پزشکی / مالی: ۱۵۳۶ (تست دقیق قبل از کاهش ابعاد)
- جستجوی موبایل / لبه (Edge): ۵۱۲ یا ۷۶۸ (بردارهای کوچک‌تر راحت‌تر جابجا می‌شوند)
اشتباهات رایج در بهینه‌سازی
بسیاری از تیم‌ها اشتباهاً ابعاد را قبل از اصلاح استراتژی تکه‌بندی (Chunking) بهینه می‌کنند. تکه‌بندی بد — مثل بلوک‌های عظیم با موضوعات مخلوط — بسیار بیشتر از بردار بزرگ به بازیابی آسیب می‌زند. ابتدا تکه‌بندی را اصلاح کنید: تکه‌ها را متمرکز نگه دارید، متادیتای مفید اضافه کنید و به‌جای حدس زدن، میزان هم‌پوشانی (Overlap) را تست کنید.
سایر خطاهای رایج عبارت‌اند از:
- تصور اینکه ابعاد کمتر هزینه API را کاهش می‌دهد: قیمت‌گذاری بر اساس توکن‌های ورودی است. صرفه‌جویی در پایگاه داده (RAM و Disk) رخ می‌دهد، نه در داشبورد صورت‌حساب API.
- انتخاب ۵۱۲ بدون ارزیابی: بردارهای ۵۱۲-بعدی ممکن است در پرس‌وجوهای ظریف، دقت بازیابی (Recall) را از دست بدهند. پیش از انتقال به تولید، آن‌ها را تست کنید.
- ترکیب بردارها: تلاش برای قرار دادن بردارهای ۱۵۳۶ و ۱۰۲۴ در یک ایندکس در زمان درج شکست می‌خورد. باید ایندکس جدید بسازید و کل مجموعه را دوباره بردار کنید.
- فراموش کردن تغییرات طرحواره: تغییر ابعاد مستلزم تغییر ساختار جدول پایگاه داده است (مثلاً در pgvector)، و نه فقط تغییر در فراخوانی API.
این تغییر رویکرد به این معناست که هدف دیگر یافتن «بهترین» مدل نیست، بلکه یافتن کوچک‌ترین برداری است که هنوز پاسخ درست را بازیابی می‌کند. با اولویت دادن به ارزیابی به‌جای تنظیمات پیش‌فرض، تیم‌ها می‌توانند سیستم‌های RAG خود را بدون افزایش خطی در هزینه‌های زیرساخت مقیاس کنند.
گام بعدی شما
- اگر از text-embedding-3-small استفاده می‌کنید، هزینه RAM پایگاه داده خود را با ابعاد فعلی محاسبه کنید.
- یک مجموعه تست شامل ۲۰۰ پرس‌وجوی واقعی بسازید و Recall را برای ابعاد ۵۱۲ و ۱۰۲۴ مقایسه کنید.
- پیش از تغییر ابعاد، استراتژی تکه‌بندی (Chunking) خود را بازبینی کنید تا مطمئن شوید گلوگاه شما اندازه بردار نیست.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو