مهندس دیتابیس‌های برداری
Vector Database Engineer
مهندس دیتابیس‌های برداری لایه‌ای را می‌سازد و اداره می‌کند که embedding ها را نگه می‌دارد و برای هر پرسش شبیه‌ترین بردارها را پیدا می‌کند: ساختار نمایه (مثل HNSW)، چیدمان داده روی حافظه و دیسک، مسیر اجرای پرسش، جستجوی فیلترشده و توازن میان recall، تأخیر و هزینه. این کار بیشتر مهندسی سیستم و پایگاه داده است تا یادگیری ماشین. عنوان دقیق «Vector Database Engineer» در آگهی‌ها کم است و بیشتر در شرکت‌های مشاوره دیده می‌شود. کارفرماها این کار را معمولاً با عنوان Software Engineer یا Database Engineer و پسوندهایی مثل Vector Search، VectorDB، Vector Index یا Search Infrastructure آگهی می‌کنند؛ هم در شرکت‌های سازندهٔ پایگاه برداری مثل Pinecone، Zilliz و turbopuffer و هم در Elastic، MongoDB و آزمایشگاه‌های هوش مصنوعی مثل Anthropic.
مقدمه و تعریف شغل
پایگاه برداری، طبق تعریف ویکی‌پدیا، پایگاه داده‌ای است که embedding ها را ذخیره و بازیابی می‌کند و معمولاً با الگوریتم‌های نزدیک‌ترین همسایهٔ تقریبی (ANN) رکوردهایی را پیدا می‌کند که از نظر معنا به ورودی نزدیک‌اند، نه رکوردهایی که دقیقاً با آن برابرند. مهندس دیتابیس‌های برداری همین سیستم را می‌سازد و اداره می‌کند. آگهی Anthropic این نقش را مالکیت «لایهٔ پایگاه برداری» تعریف می‌کند: ساختار نمایه، چیدمان ذخیره‌سازی، اجرای پرسش و لایهٔ سرویس‌دهی، به‌علاوهٔ توازن recall، تأخیر و هزینه. ابزار اصلی کار زبان‌های سیستمی (Rust، C++، Go یا Java)، دانش درون پایگاه داده و سیستم توزیع‌شده و شناخت عمیق نمایه‌های ANN است. یادگیری ماشین در این نقش بیشتر دانش جانبی است: Anthropic آشنایی با مدل‌های embedding را فقط در شرایط ترجیحی آورده است.
جستجوی نزدیک‌ترین همسایه مسئلهٔ قدیمی‌ای است؛ ویکی‌پدیا می‌نویسد جستجوی کامل، یعنی مقایسهٔ پرسش با همهٔ داده‌ها، در دیتاست‌های بزرگ کند می‌شود و روش‌های درختی هم در ابعاد بالا کارایی‌شان را از دست می‌دهند. روش‌های تقریبی مثل locality-sensitive hashing و product quantization کمی دقت را با سرعت عوض می‌کنند. در ۲۰۱۶ Malkov و Yashunin الگوریتم HNSW را منتشر کردند، یک گراف چندلایه که طبق ویکی‌پدیا امروز در Apache Lucene، pgvector، Milvus، Qdrant، Redis و سیستم‌های دیگر پشتیبانی می‌شود. Meta کتابخانهٔ Faiss را ساخت که خودش را به الگوریتم محدود کرده و قابلیت‌های پایگاه داده و محاسبات توزیع‌شده را عمداً کنار گذاشته است؛ پر کردن همین فاصله کار پایگاه‌های برداری است. Milvus از ۲۰۱۷ در Zilliz توسعه یافته، پژوهشگران Microsoft در ۲۰۱۸ پروژهٔ DiskANN را برای جستجوی نزدیک‌ترین همسایهٔ تقریبی شروع کردند و به گفتهٔ Qdrant، پروژهٔ آن در ۲۰۲۱ از آنجا شروع شد که کتابخانه‌هایی مثل FAISS نیازهای قابلیت و مقیاس‌پذیری را برآورده نمی‌کردند. ویکی‌پدیا می‌نویسد بخش بازیابی در RAG «اغلب» با یک پایگاه برداری پیاده می‌شود. امروز جستجوی برداری در پایگاه‌های عمومی هم هست، از MongoDB و Elasticsearch تا PostgreSQL با pgvector، و Anthropic آن را برای جستجوی وب، حافظهٔ گفت‌وگوها و بارهای کاری یادگیری تقویتی روی میلیاردها بردار به کار می‌برد.
چه چیزی می‌سازید؟
مثال‌های واقعی از خروجی کار یک مهندس دیتابیس‌های برداری
لایهٔ برداری پشت یک دستیار هوش مصنوعی
تیم VectorDB در Anthropic لایه‌ای را می‌سازد که جستجوی وب در claude.ai و API، حافظه در طول گفت‌وگوها و بارهای کاری یادگیری تقویتی برای آموزش مدل‌ها به آن وابسته‌اند: جستجوی نزدیک‌ترین همسایهٔ سریع، ارزان و با recall بالا روی میلیاردها بردار.
جستجوی برداری داخل یک موتور جستجو
مهندسان Vector Search در Elastic قابلیت جستجوی شباهت برداری را در Elasticsearch طراحی و پیاده می‌کنند و باگ‌هایش را رفع می‌کنند. آگهی می‌نویسد گاهی باید الگوریتم یا ساختمان داده‌ای تازه ابداع یا پیاده کنید و به سیستم‌عامل و سخت‌افزار نزدیک شوید.
جستجوی برداری بومی در یک پایگاه دادهٔ عمومی
تیم Search Systems در MongoDB موتور mongot را می‌سازد که Search و Vector Search را اجرا می‌کند. این تیم Apache Lucene را با عملگرهایی مثل $vectorSearch به MongoDB وصل می‌کند و pipeline های نمایه‌سازی ناهمگام مبتنی بر change stream را جدا از بار تراکنشی مقیاس می‌دهد.
الگوریتم‌های نمایه برای یک پایگاه برداری متن‌باز
تیم Vector Index در Zilliz قابلیت‌های بازیابی برداری Milvus و Zilliz Cloud را می‌سازد: الگوریتم‌های ANN، ساختار نمایه، کوانتیزه‌سازی، فشرده‌سازی، بهبود recall و شتاب‌دهی با CPU و GPU. کار از خواندن مقاله و ساخت نمونهٔ اولیه شروع می‌شود و به کد پروداکشن می‌رسد.
موتور جستجو روی object storage
طبق مستندات turbopuffer، باینری‌های Rust آن داده را از object storage می‌خوانند و بعد از اولین پرسش روی NVMe کش می‌کنند. اولین پرسش به یک namespace با یک میلیون سند کند است (میانهٔ ۸۷۴ میلی‌ثانیه) و پرسش‌های بعدی از کش سریع‌اند (میانهٔ ۱۴ میلی‌ثانیه). مهندسانش روی لایه‌های ذخیره‌سازی، نمایه‌سازی و پرسش کار می‌کنند.
جستجوی برداری داخل PostgreSQL
pgvector افزونهٔ متن‌بازی است که جستجوی شباهت برداری را به PostgreSQL می‌آورد و دو نوع نمایهٔ تقریبی دارد: HNSW که در توازن سرعت و recall بهتر است ولی کندتر ساخته می‌شود و حافظهٔ بیشتری می‌گیرد، و IVFFlat که سریع‌تر ساخته می‌شود و حافظهٔ کمتری می‌خواهد.
تخصص‌های مختلف مهندس دیتابیس‌های برداری
این شغل یک عنوان واحد نیست — مسیرهای تخصصی متعددی دارد
الگوریتم و ساختار نمایه
Vector Index Algorithms
پژوهش و پیاده‌سازی الگوریتم‌های ANN، ساختار نمایه، کوانتیزه‌سازی و فشرده‌سازی. آگهی Vector Index Research در Zilliz نمونهٔ این تخصص است و Elastic هم می‌نویسد گاهی باید الگوریتم یا ساختمان داده‌ای تازه ابداع کنید.
لایهٔ ذخیره‌سازی و سیستم توزیع‌شده
Storage & Distributed Database Layer
ذخیره‌سازی، replication، کش و جدا کردن compute از storage. تیم Database شرکت Pinecone، storage engine در turbopuffer و طراحی‌های مبتنی بر object storage که Anthropic آن را امتیاز می‌داند، در این دسته‌اند.
جستجوی hybrid و relevance
Hybrid Search & Relevance
ترکیب جستجوی متنی و برداری و ادغام رتبه‌بندی. turbopuffer API های جستجوی متن کامل، بردار و reranking را با هم توسعه می‌دهد و Anthropic گسترش جستجو به سمت بازیابی hybrid را جزو مسئولیت‌های نقش آورده است.
شتاب‌دهی سخت‌افزاری (SIMD و GPU)
Hardware Acceleration
بهینه‌سازی محاسبهٔ فاصله و ساخت نمایه با SIMD و GPU. Zilliz شتاب‌دهی CPU و GPU و SIMD را در شرح کار آورده، Anthropic تجربهٔ GPU برای ساخت نمایه یا جستجو را امتیاز می‌داند و طبق ویکی‌پدیا Milvus برای این کار از کتابخانهٔ cuVS شرکت NVIDIA استفاده می‌کند.
جستجوی برداری در پایگاه‌ها و موتورهای عمومی
Vector Search in General-Purpose Databases
افزودن جستجوی برداری به سیستمی که برای کار دیگری ساخته شده است: mongot در MongoDB، جستجوی برداری Elasticsearch روی Java و Lucene، یا pgvector در PostgreSQL. چالش اصلی این است که جستجو با بقیهٔ پایگاه داده، مثل فیلترها و بار تراکنشی، خوب کار کند.
تفاوت با شغل‌های مشابه
کجا این شغل تمام می‌شود و شغل دیگری شروع می‌شود؟
مهندس RAG از پایگاه برداری استفاده می‌کند؛ مهندس دیتابیس برداری خودِ آن را می‌سازد. آگهی Senior RAG Engineer شرکت Newcode.ai کار با پایگاه برداری را انتخاب پارامترهای نمایه، مدیریت توازن حافظه و تأخیر و reindex بدون قطع جستجو تعریف می‌کند و آن را کنار chunking، reranking و ارزیابی پاسخ‌ها می‌گذارد. این نقش یک لایه پایین‌تر است: ساختار نمایه، چیدمان ذخیره‌سازی، اجرای پرسش و لایهٔ سرویس‌دهی. در Anthropic این مرز در سازمان هم دیده می‌شود: نقش VectorDB در سازمان Databases است و هر روز با تیم Memory & Search کار می‌کند که جستجو و حافظه را داخل claude.ai در اختیار دارد.
مهندس جستجو روی نمایهٔ معکوس، BM25 و کیفیت رتبه‌بندی کار می‌کند و مرزش با این نقش باریک است. آگهی‌های Vector Search شرکت Elastic در تیم Search Relevance قرار دارند، turbopuffer یکی از تخصص‌های قابل قبولش را درون موتور جستجو (نمایهٔ معکوس، نمایهٔ ANN، reranker) می‌داند و Anthropic تجربه در relevance و رتبه‌بندی را شرط کرده است. تفاوت در تمرکز است: مهندس دیتابیس برداری بیشتر وقتش را روی نمایهٔ برداری، کوانتیزه‌سازی، کارایی و هزینهٔ سیستم می‌گذارد تا روی تنظیم رتبه‌بندی برای یک محصول.
مهندس پلتفرم داده زیرساختی می‌سازد که pipeline های داده روی آن اجرا می‌شوند: انبار داده و lakehouse، Spark و Kafka، orchestrator، کیفیت و پایش داده. پایگاه برداری برای او یکی از سیستم‌هایی است که ممکن است در کنار بقیه راه بیندازد و اداره کند. مهندس دیتابیس برداری خودِ موتور ذخیره‌سازی و جستجو را می‌سازد و با جزئیاتی مثل memory layout، ساختار نمایه و مسیر اجرای پرسش سروکار دارد. نقطهٔ مشترک pipeline نمایه‌سازی است؛ تیم MongoDB مثلاً نمایه‌سازی را با pipeline های ناهمگام مبتنی بر change stream جدا از بار تراکنشی مقیاس می‌دهد.
مهندسی که روی درون موتور پایگاه داده کار می‌کند (storage engine، replication، transaction) نزدیک‌ترین نقش به این کار است و بسیاری از آگهی‌های این حوزه همین عنوان را دارند: turbopuffer عنوان «database engineer» را به کار برده و Pinecone آگهی را برای «Database Team» داده است. تفاوت در نوع پرسش است: پایگاه برداری به‌جای تطابق دقیق، شبیه‌ترین رکوردها را با الگوریتم‌های تقریبی پیدا می‌کند، پس باید نمایه‌های ANN، کوانتیزه‌سازی و سنجش recall را هم بشناسید. DBA کلاسیک که پایگاه داده را اداره می‌کند ولی موتورش را نمی‌سازد، از این نقش دورتر است.
تأثیر در صنایع مختلف
مهندس دیتابیس‌های برداری در همه صنایع مشغول به کار است — نه فقط شرکت‌های فناوری
آزمایشگاه‌ها و دستیارهای هوش مصنوعی
Anthropic جستجوی وب، حافظهٔ گفت‌وگوها و بارهای کاری آموزش مدل را روی لایهٔ برداری خودش اجرا می‌کند. OpenAI هم تیم جداگانه‌ای دارد که سیستم‌های جستجو را در سراسر ChatGPT می‌سازد.
سازندگان پایگاه برداری
Pinecone، Zilliz (Milvus و Zilliz Cloud)، turbopuffer، Qdrant، Weaviate و Chroma خودِ موتور را می‌سازند. اما تعدادشان کم است و همه در هر زمان نقش مهندسی هسته ندارند.
موتورهای جستجو
Elastic برای توسعهٔ جستجوی برداری Elasticsearch در آمریکا، کانادا و هشت کشور اروپایی آگهی داده است. OpenSearch هم جستجوی برداری را با افزونهٔ k-NN ارائه می‌کند.
پایگاه‌های دادهٔ عمومی
MongoDB با موتور mongot، PostgreSQL با افزونهٔ pgvector و Redis جستجوی برداری را کنار داده‌های معمولی آورده‌اند. پس این مهارت در شرکت‌های پایگاه دادهٔ عمومی هم به کار می‌آید.
داده و lakehouse برای AI
LanceDB خودش را lakehouse چندرسانه‌ای برای AI معرفی می‌کند. طبق ویکی‌پدیا، Milvus 3.0 که در ژوئیهٔ ۲۰۲۶ منتشر شد، پردازش داده به سبک data lake را به آن اضافه کرده است.
مشاوره و تحلیل داده
آگهی‌هایی که عنوان دقیق «Vector Database Engineer» دارند، بیشتر از شرکت‌های مشاوره‌اند. یکی از آن‌ها برای یک شرکت تحلیل داده که به بیمه، سلامت، بانکداری، خرده‌فروشی و حمل‌ونقل خدمت می‌دهد، پیاده‌سازی پایگاه برداری برای مدل‌های زبانی روی Azure را می‌خواهد.
پیشنهاددهی و تعدیل محتوا
طبق ویکی‌پدیا، کاربردهای رایج Faiss سیستم‌های پیشنهاددهی، داده‌کاوی، بازیابی متن و تعدیل محتواست. همچنین گزارش شده که در Meta یک‌ونیم تریلیون بردار ۱۴۴ بُعدی را نمایه کرده است.
تصورات غلط رایج
قبل از تصمیم‌گیری، این باورهای اشتباه را بشناسید
پایگاه برداری همان Faiss است با یک API روی آن
طبق ویکی‌پدیا، Faiss عمداً به پیاده‌سازی الگوریتم محدود شده و قابلیت‌های پایگاه داده و محاسبات توزیع‌شده را کنار گذاشته است. پایگاه برداری باید sharding، سطوح consistency، دریافت دادهٔ جریانی، چند-مستأجری و کنترل دسترسی هم داشته باشد؛ ویکی‌پدیا همهٔ این‌ها را برای Milvus برشمرده است. به گفتهٔ Qdrant، پروژهٔ آن هم از همین‌جا شروع شد که FAISS نیاز قابلیت و مقیاس‌پذیری را برآورده نمی‌کرد.
این کار یعنی صدا زدن API یک پایگاه برداری
آن کار مهندس RAG یا مهندس هوش مصنوعی است. آگهی‌های این نقش زبان سیستمی و درون سیستم می‌خواهند: Pinecone پنج سال برنامه‌نویسی با Rust، Go یا C++، turbopuffer فکر کردن بر حسب memory layout و cache line، و Zilliz اشکال‌زدایی SIMD، دسترسی به حافظه و I/O.
جستجوی دقیق همیشه بهتر است و تقریبی یعنی سهل‌انگاری
مستندات Elastic می‌گوید kNN تقریبی برای بیشتر بارهای کاری پروداکشن بهترین انتخاب است، چون آنجا تأخیر کم و مقیاس از recall کامل مهم‌ترند. جستجوی دقیق برای دیتاست‌های کوچک یا زیرمجموعه‌های فیلترشده مناسب است. کار حرفه‌ای این است که فاصلهٔ این دو را اندازه بگیرید؛ Anthropic «بنچمارک در برابر جستجوی دقیق» را جزو مسئولیت‌های نقش آورده است.
فیلتر کردن نتایج جستجوی برداری کار ساده‌ای است
README افزونهٔ pgvector مثال روشنی می‌زند: با نمایهٔ تقریبی، فیلتر بعد از پیمایش نمایه اعمال می‌شود و اگر شرطی ۱۰٪ ردیف‌ها را بگیرد، با HNSW و ef_search پیش‌فرض ۴۰، به‌طور میانگین فقط ۴ ردیف برمی‌گردد. برای همین Anthropic جستجوی فیلترشده را جزو دانش لازم آورده و پژوهشگران DiskANN مقالهٔ جداگانهٔ Filtered-DiskANN را برای جستجو با فیلتر منتشر کرده‌اند.
برای این کار باید پیشینهٔ یادگیری ماشین یا دکترا داشت
Zilliz مدرک کارشناسی در رشتهٔ مرتبط «یا تجربهٔ عملی معادل» می‌خواهد و Anthropic آشنایی با مدل‌های embedding را فقط در شرایط ترجیحی آورده است. شرط‌های اصلی مهندسی سیستم و پایگاه داده‌اند. نمونهٔ جالب Yury Malkov، نویسندهٔ HNSW، است که به گفتهٔ پروفایل GitHub خودش دکترای فیزیک لیزر دارد و بعد به علوم کامپیوتر آمده است.
یک روز کاری واقعی
در هر سطح روز کاری چه شکلی است؟
جونیور (۰–۲ سال)
در آگهی‌هایی که بررسی کردیم نقش جونیور برای این کار نبود؛ کمترین حد تجربه سه سال بود. این سال‌ها معمولاً در نقش مجاوری مثل بک‌اند یا پایگاه داده می‌گذرد و کار روزانهٔ مربوط به این مسیر بیشتر یادگیری و ساختن شاهد عمومی است.
- ◆نوشتن تست یا رفع یک باگ کوچک در یک پایگاه برداری متن‌باز مثل pgvector، Qdrant یا Milvus
- ◆اندازه‌گیری recall@10 و تأخیر یک نمایهٔ HNSW با پارامترهای مختلف
- ◆خواندن مقالهٔ HNSW یا DiskANN و مقایسهٔ آن با پیاده‌سازی Faiss
- ◆پیدا کردن بخش کند یک برنامه با perf و بهینه کردن آن
- ◆نوشتن یادداشت فنی دربارهٔ آنچه اندازه گرفته‌اید
میانی (۲–۵ سال)
روی اجزای نمایه کار می‌کنید و میان پژوهش و مهندسی رفت‌وآمد دارید. این توصیف بر اساس آگهی Vector Index Research شرکت Zilliz است که سه سال تجربه می‌خواهد.
- ◆خواندن مقاله‌ای تازه دربارهٔ کوانتیزه‌سازی یا نمایهٔ گرافی و ارزیابی اینکه به کار سیستم می‌آید یا نه
- ◆ساخت نمونهٔ اولیه از یک بهینه‌سازی در مسیر پرسش یا چیدمان حافظه
- ◆اجرای بنچمارک روی دادهٔ واقعی و مقایسهٔ تأخیر، throughput، recall، حافظه و زمان ساخت نمایه
- ◆اشکال‌زدایی یک افت کارایی که به SIMD، دسترسی به حافظه یا concurrency برمی‌گردد
- ◆تبدیل نمونهٔ اولیه به کد قابل نگهداری و تست‌شده
ارشد و Staff (۵+ سال)
مالک یک بخش یا کل لایهٔ برداری هستید و دربارهٔ توازن recall، تأخیر و هزینه تصمیم می‌گیرید. این توصیف بر اساس آگهی‌های Anthropic، Pinecone و MongoDB است.
- ◆تصمیم دربارهٔ راهبرد ساخت و به‌روزرسانی نمایه یا جدا کردن compute از storage
- ◆برنامه‌ریزی ظرفیت برای یک بار کاری تازه و پیدا کردن گلوگاه: معماری، سخت‌افزار یا نیروی مهندسی
- ◆تعریف هدف recall، تأخیر و هزینهٔ هر پرسش و ساخت تشخیص خودکار افت کیفیت
- ◆هدایت بازبینی طراحی و راهنمایی مهندسان تازه‌وارد
- ◆شیفت on-call برای سیستم‌هایی که مالک آن‌ها هستید
مسئولیت‌ها و وظایف
مسئولیت‌های اصلی
وظایف روزانه و مهارت‌های مورد نیاز در این شغل
- ◈طراحی و ساخت ساختار نمایه، چیدمان ذخیره‌سازی، اجرای پرسش و لایهٔ سرویس‌دهی پایگاه برداری
- ◈مدیریت توازن recall، تأخیر و هزینه با کوانتیزه‌سازی، جستجوی فیلترشده و راهبرد ساخت و به‌روزرسانی نمایه
- ◈پژوهش، ارزیابی و پیاده‌سازی الگوریتم‌های جدید نمایه‌سازی و بازیابی برداری
- ◈طراحی بنچمارک و روش ارزیابی: مقایسه با جستجوی دقیق، هدف‌های recall و تأخیر، هزینهٔ هر پرسش و تشخیص افت کیفیت
- ◈رفع مشکلات کارایی در سطح CPU/GPU، SIMD، دسترسی به حافظه، concurrency و I/O
- ◈گسترش جستجو به hybrid: جستجوی متنی و ادغام رتبه‌بندی در کنار جستجوی برداری
- ◈آمادگی پروداکشن: برنامه‌ریزی ظرفیت، پذیرفتن بارهای کاری جدید، ابزار عملیاتی و on-call
- ◈کار با مشتری‌ها یا تیم‌های داخلی برای فهم بار کاری‌شان و برگرداندن یافته‌ها به محصول، و نوشتن مستندات روشن
- ◈هدایت بازبینی طراحی، تصمیم‌گیری معماری و راهنمایی مهندسان تازه‌وارد (در سطح Staff)
مهارت‌های مورد نیاز
مهارت‌های فنی، نرم و حوزه‌ای که یک مهندس دیتابیس‌های برداری موفق به آن‌ها نیاز دارد
سیستم و زبان برنامه‌نویسی
زبان‌هایی که Anthropic، Pinecone و Zilliz برای کد حساس به کارایی و حافظه می‌خواهند
زبان اصلی Elasticsearch و زبان ترجیحی تیم Search Systems در MongoDB
فکر کردن بر حسب memory layout، cache line و syscall (آگهی turbopuffer)
ساختارهای همزمانی و محیط‌های async و multithreaded (Elastic و Pinecone)
در شرح کار Zilliz و turbopuffer برای محاسبهٔ فاصله و ساختمان داده آمده است
eBPF/perf، strace و gdb؛ جزو شرط‌های لازم turbopuffer
ساخت نمایه یا جستجو روی GPU؛ در شرایط ترجیحی Anthropic و شرح کار Zilliz
جستجوی برداری و بازیابی
گرافی (HNSW)، مبتنی بر خوشه‌بندی (IVF) و روی دیسک (DiskANN)؛ شرط Anthropic و Elastic
scalar، product و binary quantization و rescoring برای کم کردن حافظه (Anthropic و Zilliz)
ترکیب جستجوی برداری با شرط روی metadata بدون از دست دادن نتایج
نمایهٔ معکوس و BM25؛ در شرایط ترجیحی Anthropic و تخصص‌های turbopuffer
جستجوی متنی و ادغام رتبه‌بندی در کنار جستجوی برداری (Anthropic)
شرط Anthropic؛ آگهی‌های Vector Search شرکت Elastic در تیم Search Relevance هستند
آشنایی با مدل‌های embedding و نیازهای بازیابی در آموزش و inference مدل‌های زبانی (ترجیحی در Anthropic)
پایگاه داده، سیستم توزیع‌شده و پروداکشن
LSM، WAL، MVCC، compaction و GC (آگهی turbopuffer)
replication، lease، تحمل خطا و طراحی سیستم ذخیره‌سازی یا سرویس‌دهی با الزامات سخت تأخیر
استدلال دربارهٔ consistency، durability، concurrency و حالت‌های خرابی (MongoDB)
مقایسه با جستجوی دقیق، طراحی بنچمارک روی دادهٔ واقعی و تشخیص افت کیفیت (Anthropic و Zilliz)
برنامه‌ریزی ظرفیت و هزینهٔ هر پرسش (Anthropic)
اجرای پایگاه داده روی AWS، GCP و Azure؛ امتیاز در Pinecone و turbopuffer
توضیح سادهٔ ایده‌های پیچیده (turbopuffer)، همکاری ناهمزمان (Elastic) و هماهنگ کردن تیم‌ها (Anthropic)
نقشه راه و مسیر آموزشی
نقشه راه تبدیل شدن به مهندس دیتابیس‌های برداری
این مسیر گام به گام شما را از صفر تا حرفه‌ای هدایت می‌کند.
برنامه‌نویسی سیستمی و کارایی
آگهی‌های این نقش زبان سیستمی می‌خواهند: Anthropic و Pinecone از Rust، C++ یا Go نام می‌برند، Zilliz از C++ یا Rust و Elastic و MongoDB از Java. turbopuffer می‌نویسد باید «با memory layout، cache line و syscall فکر کنید» و با perf، eBPF، strace و gdb راحت باشید. اگر از Python می‌آیید، این مرحله بیشترین زمان را می‌گیرد.
درون پایگاه داده و سیستم‌های توزیع‌شده
پایگاه برداری پیش از هر چیز پایگاه داده است. turbopuffer تخصص در یکی از این‌ها را شرط کرده: storage engine (LSM، WAL، MVCC، compaction)، سیستم توزیع‌شده (replication، lease، تست آشوب) یا درون موتور جستجو. MongoDB از مهندس ارشد می‌خواهد دربارهٔ consistency، durability، concurrency و حالت‌های خرابی در محیط توزیع‌شده استدلال کند.
بازیابی اطلاعات و جستجوی متنی
نمایهٔ معکوس، BM25 و رتبه‌بندی پایهٔ جستجوی hybrid است. Anthropic تجربه در relevance و رتبه‌بندی را شرط و تجربهٔ موتور جستجوی متنی را امتیاز می‌داند. MongoDB جستجوی برداری‌اش را با یکپارچه کردن Apache Lucene ساخته و تیم Vector Search شرکت Elastic در بهبود Lucene مشارکت می‌کند، پس آشنایی با Lucene در این بازار به کار می‌آید.
الگوریتم‌های ANN و نمایه‌های برداری
هستهٔ این نقش. Anthropic «دانش عمیق ساختارهای نمایهٔ ANN (مبتنی بر گراف، مبتنی بر خوشه‌بندی یا روی دیسک)، کوانتیزه‌سازی بردار و جستجوی فیلترشده» می‌خواهد و Elastic تجربه با HNSW یا IVF. مقاله‌های اصلی را بخوانید، الگوریتم را خودتان پیاده کنید و نتیجه را با پیاده‌سازی مرجع مقایسه کنید.
پایگاه برداری در پروداکشن
از الگوریتم به سیستم: ساخت و به‌روزرسانی نمایه، جدا کردن compute و storage، چند-مستأجری، ارزیابی و پایش. Anthropic مالکیت آمادگی پروداکشن را از همین نقش می‌خواهد: مقایسه با جستجوی دقیق، برنامه‌ریزی ظرفیت، پذیرفتن بارهای کاری جدید و ابزار عملیاتی. کد یک پایگاه برداری متن‌باز را بخوانید و ببینید این‌ها در عمل چطور حل شده‌اند.
ابزارها و استک فنی
ابزارهایی که هر مهندس AI باید بشناسد، دسته‌بندی‌شده بر اساس اولویت
پایگاه‌های برداری اختصاصی
پایگاه برداری توزیع‌شده و متن‌باز ساخت Zilliz؛ طبق ویکی‌پدیا موتور جستجوی آن بر نسخه‌های تغییریافتهٔ Faiss، DiskANN و hnswlib تکیه دارد. آگهی Vector Index شرکت Zilliz روی همین موتور کار می‌کند
پایگاه و موتور جستجوی برداری متن‌باز به زبان Rust؛ مستندات کوانتیزه‌سازی آن روش‌ها و trade-off هایشان را با جزئیات توضیح می‌دهد
پایگاه برداری متن‌باز به زبان Go که اشیا و بردارها را با هم نگه می‌دارد و جستجوی برداری را با فیلتر ساختاریافته ترکیب می‌کند
پایگاه برداری Pinecone؛ تیم Database آن سیستم‌های توزیع‌شدهٔ بلادرنگ می‌سازد و روی تأخیرهای انتهایی (tail latency)، throughput و نرخ اصابت کش کار می‌کند
جستجوی برداری در موتورهای جستجو و پایگاه‌های عمومی
موتور جستجوی Java؛ هم kNN تقریبی و هم kNN دقیق دارد و Elastic برای توسعهٔ جستجوی برداری آن در آمریکا، کانادا و اروپا آگهی داده است
موتور جستجوی متن‌باز؛ افزونهٔ k-NN آن جستجوی نزدیک‌ترین همسایه را برای داده‌های برداری فراهم می‌کند
افزونهٔ متن‌باز PostgreSQL برای جستجوی شباهت برداری، دقیق و تقریبی، با نمایه‌های HNSW و IVFFlat؛ README آن trade-off این دو نمایه و مشکل فیلتر را روشن توضیح می‌دهد
جستجوی برداری داخل MongoDB؛ طبق آگهی MongoDB، موتور mongot آن را با یکپارچه کردن Apache Lucene و عملگر $vectorSearch اجرا می‌کند
کتابخانه‌های ANN
کتابخانهٔ متن‌باز Meta برای جستجوی شباهت و خوشه‌بندی بردارها؛ C++ با رابط Python و پیاده‌سازی GPU با CUDA. طبق ویکی‌پدیا در OpenSearch و Milvus جزئی از موتور جستجوست و در بنچمارک‌ها معمولاً مبنای مقایسه است
کتابخانهٔ header-only در C++ و Python برای HNSW؛ طبق ویکی‌پدیا مرتبط با نویسندگان اصلی الگوریتم
کتابخانهٔ نمایه‌سازی برداری Microsoft برای جستجوی سریع، تازه و فیلترشده؛ مقالهٔ NeurIPS 2019 آن جستجوی میلیاردها نقطه روی یک سرور را هدف گرفته بود
روش و کتابخانهٔ Google برای جستجوی برداری در مقیاس بزرگ، با هرس فضای جستجو و کوانتیزه‌سازی؛ برای پردازنده‌های x86 با AVX بهینه شده است
زبان، کارایی و بنچمارک
Anthropic، Pinecone و Zilliz آن را در کنار C++ و Go نام برده‌اند و Qdrant، turbopuffer و مخزن فعلی DiskANN با آن نوشته شده‌اند. یکی از زبان‌های سیستمی برای این نقش ضروری است
ابزارهای تحلیل کارایی لینوکس؛ turbopuffer راحتی با eBPF/perf، strace و gdb را جزو شرط‌های لازم آورده است
بنچمارک متن‌باز کتابخانه‌های نزدیک‌ترین همسایهٔ تقریبی؛ برای دیدن منحنی recall در برابر سرعت
مسیر پیشرفت شغلی
از جونیور تا Staff Engineer — چه مهارت‌هایی نیاز دارید و چه درآمدی انتظار داشته باشید
Software / Backend / Database Engineer (نقش مجاور)
۰ تا ۳ سال
در آگهی‌هایی که پیدا کردیم نقش ورودی برای این کار نبود؛ کمترین حد تجربه سه سال بود (Zilliz). سال‌های اول را می‌شود در نقش بک‌اند یا پایگاه داده گذراند و هم‌زمان روی جستجو، نمایه یا یک پایگاه برداری متن‌باز کار کرد.
Software Engineer, Vector Search / Vector Index
۳ تا ۵ سال
پیاده‌سازی و بهینه‌سازی اجزای نمایه: ساخت نمایه، مسیر پرسش، کوانتیزه‌سازی و چیدمان حافظه؛ طراحی بنچمارک و رفع مشکلات کارایی. آگهی Zilliz با سه سال تجربه نمونهٔ این سطح است.
Senior Software Engineer (Database / Vector Search)
۵+ سال
~$230K
میانگین سالانه (آمریکا)
طراحی و ساخت قابلیت‌های پایگاه داده، بهبود tail latency، throughput و هزینه در یک سیستم توزیع‌شده و مالکیت یک بخش از موتور. آگهی Database Team شرکت Pinecone با پنج سال تجربه نمونهٔ این سطح است.
Staff / Principal Engineer
معمولاً ۱۰+ سال (آگهی MongoDB)
تعیین معماری لایهٔ برداری، روش ارزیابی (هدف recall، تأخیر و هزینهٔ هر پرسش) و جهت فنی تیم؛ هدایت طراحی و راهنمایی مهندسان دیگر. آگهی‌های Anthropic، MongoDB و Principal در Elastic در این سطح‌اند.
چالش‌ها و جنبه‌های منفی
واقعیت‌هایی که کمتر در آگهی‌های شغلی می‌بینید — قبل از ورود بدانید
توازن recall، تأخیر و هزینه
عمومیهیچ تنظیمی همه را با هم بهتر نمی‌کند. ویکی‌پدیا دربارهٔ HNSW می‌نویسد اتصال‌های بیشتر recall را بهتر و حافظه را بیشتر می‌کند، فهرست جستجوی بزرگ‌تر دقت را بالا و پرسش را کند می‌کند و فهرست ساخت بزرگ‌تر کیفیت گراف را بهتر و ساخت نمایه را کندتر می‌کند. Anthropic «هدایت» همین توازن را جزو مسئولیت‌های اصلی نقش آورده است.
جستجوی فیلترشده
عمومیوقتی کاربر جستجوی معنایی را با یک شرط ترکیب می‌کند، ممکن است بیشتر نتایج حذف شوند. README افزونهٔ pgvector نشان می‌دهد با شرطی که ۱۰٪ ردیف‌ها را بگیرد و تنظیم پیش‌فرض، به‌طور میانگین فقط ۴ ردیف برمی‌گردد. راه‌حل‌ها، مثل پیمایش تکراری نمایه یا نمایه‌های فیلترپذیر، هر کدام هزینهٔ خودشان را دارند.
حافظه و کوانتیزه‌سازی
شرکت بزرگنمایهٔ گرافی هزینهٔ حافظه دارد؛ pgvector می‌نویسد HNSW از IVFFlat حافظهٔ بیشتری مصرف می‌کند. کوانتیزه‌سازی این را کم می‌کند: طبق مستندات Qdrant، تبدیل float32 به uint8 حافظهٔ هر بردار را چهار برابر کم می‌کند. اما دقت کم می‌شود و باید با rescoring و اندازه‌گیری جبرانش کرد.
ذخیره‌سازی جدا و کش سرد
استارتاپجدا کردن compute از storage هزینه را پایین می‌آورد، ولی اولین پرسش کند می‌شود. turbopuffer برای یک میلیون سند میانهٔ ۸۷۴ میلی‌ثانیه را برای پرسش اول از object storage و ۱۴ میلی‌ثانیه را برای پرسش‌های بعدی از کش گزارش کرده است. Anthropic هم تجربهٔ طراحی‌های مبتنی بر object storage را امتیاز می‌داند.
ساخت و به‌روزرسانی نمایه
شرکت بزرگداده مدام تغییر می‌کند و نمایه باید تازه بماند، بدون اینکه جستجو بخوابد یا کیفیتش افت کند. Anthropic «راهبرد ساخت و به‌روزرسانی نمایه» را جزو مسئولیت‌ها آورده و Simhadri و همکارانش FreshDiskANN را برای جستجوی شباهت روی دادهٔ جریانی معرفی کرده‌اند.
ارزیابی و تشخیص افت کیفیت
تحقیقاتیاینکه یک تغییر recall را بدتر کرده یا نه، با نگاه پیدا نمی‌شود. Anthropic از این نقش می‌خواهد روش ارزیابی را تعیین کند: هدف recall، هدف تأخیر، هزینهٔ هر پرسش و تشخیص افت کیفیت. Zilliz هم طراحی بنچمارک روی «مقیاس واقعی داده و الگوی واقعی پرسش» را می‌خواهد، نه فقط دیتاست‌های استاندارد.
ورود به این نقش
عمومیسطح آگهی‌ها بالاست: کمترین تجربه‌ای که دیدیم سه سال بود (Zilliz) و بقیه پنج سال (Pinecone)، ده سال (MongoDB) یا سطح Staff و Principal (Anthropic و Elastic) می‌خواستند. Anthropic تجربهٔ «مستقیم» ساخت پایگاه برداری یا سیستم ANN در پروداکشن را شرط کرده است. برای همین بهتر است شاهد عمومی بسازید: مشارکت متن‌باز و پروژه‌های بنچمارک با عدد.
حقوق و بازار کار جهانی
حقوق جهانی مهندس دیتابیس‌های برداری
حقوق سالانه در کشورهای مختلف بر اساس داده‌های منتشرشده؛ منبع هر ردیف با آیکون کنار نام کشور باز می‌شود.
* ارقام سالانه‌اند. منبع هر رقم:
- Pinecone posting, Senior/Staff Software Engineer, Database Team (NYC, 5+ yrs), posted Jun 15 2026: posted base range; median = midpoint
- Elastic posting, Senior Software Developer - Vector Search (Canada; Senior title, no years stated), posted Aug 27 2026, last updated Oct 1 2026: typical starting salary range; median = midpoint
- Elastic posting, Senior Software Engineer - Vector Search (Ireland; Senior title, no years stated), posted Aug 27 2026, last updated Oct 1 2026: typical starting salary range; median = midpoint
- Elastic posting, Senior Software Engineer - Vector Search (Spain; Senior title, no years stated), posted Aug 27 2026, last updated Oct 1 2026: typical starting salary range; median = midpoint
- ITJobsWatch, 6 months to 22 Oct 2026: UK permanent ads citing Pinecone (proxy: skill, not job title); 25th–75th pct, median (35 salaries)
چگونه از صفر شروع کنیم
برنامه گام‌به‌گام برای ورود به مهندسی هوش مصنوعی
ماه ۱: نمایه‌های ANN
مقالهٔ HNSW را بخوانید و با Faiss یا hnswlib روی یک دیتاست عمومی recall و تأخیر را اندازه بگیرید.
ماه ۲: pgvector از درون
README کامل pgvector را بخوانید، HNSW و IVFFlat را مقایسه و مشکل فیلتر را بازتولید کنید.
ماه ۳: کوانتیزه‌سازی و حافظه
با Qdrant یا Faiss اثر scalar و binary quantization را بر حافظه و recall بسنجید.
ماه ۴: یک زبان سیستمی
اگر Rust یا C++ بلد نیستید، شروع کنید و یک نسخهٔ ساده از HNSW را با آن بنویسید.
ماه ۵: مشارکت متن‌باز
یک issue کوچک در Milvus، Qdrant، Weaviate یا pgvector بردارید و PR بفرستید.
ماه ۶: نمونه‌کار و درخواست
نتیجهٔ بنچمارک‌ها را در یک README یا یادداشت فنی منتشر کنید و برای نقش‌های Vector Search، Search Infrastructure و Database Engineer درخواست بدهید.
پروژه‌های پیشنهادی برای رزومه
پیاده‌سازی HNSW از صفر
پیشرفتهHNSW را با Rust یا C++ پیاده کنید و روی یک دیتاست عمومی recall@10 و تأخیر را با hnswlib یا Faiss مقایسه کنید. اثر پارامترهای تعداد اتصال و اندازهٔ فهرست جستجو را روی recall، حافظه و زمان ساخت نمایه نمودار کنید و در README توضیح دهید چرا نتیجه این شکل را دارد.
مشکل فیلتر در pgvector
متوسطREADME افزونهٔ pgvector می‌گوید با نمایهٔ تقریبی، فیلتر بعد از پیمایش نمایه اعمال می‌شود و اگر شرطی ۱۰٪ ردیف‌ها را بگیرد، با HNSW و مقدار پیش‌فرض ef_search، به‌طور میانگین فقط ۴ ردیف برمی‌گردد. همین را با داده و فیلترهای مختلف بازتولید کنید، سپس iterative index scan و دیگر راه‌ها را امتحان و نتیجه را مستند کنید.
مطالعهٔ کوانتیزه‌سازی
متوسطیک مجموعه بردار را با scalar و binary quantization (در Qdrant یا Faiss) فشرده کنید و حافظه، سرعت و recall را با و بدون rescoring بسنجید. هدف این است که بتوانید با عدد بگویید هر روش چقدر حافظه صرفه‌جویی می‌کند و چقدر دقت از دست می‌دهد.
جستجوی hybrid با ارزیابی
متوسطجستجوی BM25 (با Lucene، Elasticsearch یا OpenSearch) را با جستجوی برداری ترکیب کنید و نتایج را با rank fusion ادغام کنید. یک مجموعهٔ پرسش با پاسخ درست بسازید و recall@k و nDCG هر روش را جدا گزارش کنید.
مشارکت در یک پایگاه برداری متن‌باز
پیشرفتهیک issue واقعی در Milvus، Qdrant، Weaviate، pgvector یا Faiss پیدا کنید و رفعش کنید؛ ترجیحاً موضوعی دربارهٔ کارایی یا درستی. Anthropic تجربهٔ ساخت سیستم ANN در پروداکشن و turbopuffer مشارکت در جامعهٔ پایگاه داده یا بازیابی اطلاعات را ارزشمند می‌دانند و یک PR پذیرفته‌شده نزدیک‌ترین شاهد عمومی برای چنین تجربه‌ای است.
مثال‌های واقعی و Case Studies
داستان‌های واقعی از مهندسانی که در این حوزه تأثیرگذار بوده‌اند
به گفتهٔ پروفایل GitHub خودش، دکترای فیزیک لیزر دارد و بعد به علوم کامپیوتر آمده است. در همان پروفایل، OpenAI به‌عنوان محل کار و منطقهٔ خلیج سان‌فرانسیسکو به‌عنوان محل زندگی‌اش آمده است.
پروفایل GitHub او را نویسندهٔ HNSW معرفی می‌کند، الگوریتمی برای جستجوی نزدیک‌ترین همسایهٔ تقریبی.
نویسندهٔ یکی از الگوریتم‌های اصلی این حوزه از رشتهٔ دیگری آمده است. برای ورود به این کار، فهم عمیق یک مسئله و آزمودن دقیق راه‌حل از عنوان مدرک مهم‌تر به نظر می‌رسد.
طبق سایت شخصی‌اش، Partner Researcher در Microsoft Azure است. دکترای علوم کامپیوتر را از دانشگاه Carnegie Mellon گرفته (۲۰۰۷ تا ۲۰۱۳) و پایان‌نامه‌اش دربارهٔ الگوریتم‌های موازی با تضمین‌های اثبات‌پذیر برای پردازنده‌های چندهسته‌ای بوده است. بعد پژوهشگر پسادکتری در Lawrence Berkeley National Lab بوده و در Microsoft Research India روی عملگرها و معماری‌های تازهٔ ML برای دستگاه‌های IoT و edge کوچک (EdgeML) کار کرده است.
به نوشتهٔ خودش، در ۲۰۱۸ پروژهٔ DiskANN را برای جستجوی نزدیک‌ترین همسایهٔ تقریبی شروع کردند تا فاصلهٔ بزرگ پژوهش و عمل را پر کنند و این پروژه در Microsoft و دیگر شرکت‌ها گسترده به کار رفته است. فهرست مقاله‌هایش شامل DiskANN (NeurIPS 2019)، FreshDiskANN، Filtered-DiskANN (WWW 2023) و گزارش نتایج رقابت NeurIPS 2021 برای جستجوی ANN در مقیاس میلیارد و رقابت Big ANN در NeurIPS 2023 است.
مسیر او از الگوریتم‌های موازی و سیستم به جستجوی برداری رسیده است. به نظر می‌رسد پایهٔ سیستم و الگوریتم در این حوزه از تخصص ML ارزشمندتر است و مسئله‌هایی مثل دادهٔ جریانی و فیلتر هر کدام به یک پروژهٔ جدا تبدیل شده‌اند.
طبق صفحهٔ «درباره‌ما»ی Qdrant، هم‌بنیان‌گذار و CTO این شرکت است. در ۲۰۲۱ با André Zayarni روی پروژه‌ای کار می‌کرد که می‌خواست با جستجوی شباهت برداری یک موتور تطبیق برای داده‌های بدون ساختار بسازد.
به روایت Qdrant، وقتی روشن شد کتابخانه‌هایی مثل FAISS نیاز قابلیت و مقیاس‌پذیری آن پروژه را برآورده نمی‌کنند، تصمیم گرفت یک موتور جستجوی برداری آمادهٔ پروداکشن را از صفر بسازد. نسخهٔ اول روی GitHub منتشر شد و توجه توسعه‌دهندگان را جلب کرد و بعد شرکت Qdrant تأسیس شد. Qdrant به زبان Rust ساخته شده است.
این داستان فرق کتابخانهٔ الگوریتم و پایگاه داده را خوب نشان می‌دهد: آنچه کم بود الگوریتم نبود، قابلیت‌ها و مقیاس‌پذیری یک سیستم کامل بود. همچنین نشان می‌دهد منتشر کردن کد روی GitHub می‌تواند خودش راه ورود باشد.
نمونه آگهی استخدام واقعی + تحلیل
یک آگهی واقعی از شرکت فعال در حال استخدام، با تحلیل هر بخش
Staff+ Software Engineer, VectorDB
تحلیل نیازمندی‌ها
Direct experience building a vector database or approximate nearest-neighbor search system that ran in production at scale
شرط اول تجربهٔ «مستقیم» ساختن است، نه استفاده کردن. کسی که فقط با API یک پایگاه برداری کار کرده، این شرط را ندارد. باید روی خودِ موتور یا سیستم جستجو کار کرده باشید و آن سیستم کاربر واقعی در مقیاس داشته باشد.
ضروریDeep knowledge of ANN index structures (graph-based, clustering-based or disk-resident approaches), vector quantization and filtered search
این سه خانوادهٔ نمایه تقریباً یعنی HNSW، IVF و DiskANN. کوانتیزه‌سازی برای کم کردن حافظه است و جستجوی فیلترشده یکی از سخت‌ترین مسئله‌های عملی این حوزه. در مصاحبه انتظار دارند trade-off هر کدام را با عدد توضیح دهید.
ضروریExperience with search relevance and ranking
پیدا کردن نزدیک‌ترین بردار کافی نیست؛ نتیجه باید به کار کاربر بیاید. تجربه با رتبه‌بندی و سنجش relevance، مثلاً از کار روی یک موتور جستجو، اینجا به کار می‌آید.
ضروریStrong systems programming skills in a language such as Rust, C++ or Go, including performance-critical and memory-intensive code
Python برای این نقش کافی نیست. باید کدی نوشته باشید که سرعت و مصرف حافظه‌اش مهم بوده و آن را اندازه گرفته و بهینه کرده باشید.
ضروریExperience designing and operating large-scale distributed storage or serving systems with strict latency and reliability requirements
«اداره کردن» به همان اندازهٔ «طراحی» مهم است: سیستمی که اگر کند یا خراب شود، کسی شب بیدار می‌شود. این نقش on-call هم دارد.
ضروریA track record of independently scoping and delivering ambiguous, multi-quarter technical projects
این شرط سطح Staff را نشان می‌دهد: کسی که خودش مسئلهٔ مبهم را تعریف می‌کند، برنامهٔ چندفصلی می‌ریزد و تا آخر می‌برد، نه کسی که تیکت انجام می‌دهد.
ضروریExperience with object-storage-backed or disaggregated compute and storage database designs
یعنی داده روی object storage مثل S3 بماند و محاسبه جدا مقیاس بگیرد. این طراحی هزینه را پایین می‌آورد ولی مسئلهٔ کش و تأخیر پرسش اول را می‌آورد. شرط ترجیحی است، ولی جهت معماری تیم را نشان می‌دهد.
مهمExperience building or operating full-text search engines (inverted indexes, BM25) or hybrid retrieval systems
یکی از مسئولیت‌های نقش گسترش جستجو به hybrid است، پس پیشینهٔ جستجوی متنی امتیاز مستقیم دارد. اگر از Elasticsearch، OpenSearch یا Lucene می‌آیید، اینجا نقطهٔ قوت شماست.
مهمExperience using GPUs or other accelerators for index build or search
ساخت نمایه و جستجو روی GPU هنوز تخصص کمیابی است. شرط ترجیحی است و نبودنش مانع نیست، ولی نشان می‌دهد تیم به این سمت فکر می‌کند.
مفیدFamiliarity with embedding models and the retrieval demands of LLM training and inference
دانش ML در این نقش جانبی است و فقط در شرایط ترجیحی آمده. کافی است بدانید embedding از کجا می‌آید و آموزش و inference مدل زبانی چه نوع بار جستجویی ایجاد می‌کنند.
مفیدتحلیل مسئولیت‌ها
Own the core of Anthropic's vector database layer: index structures, storage layout, query execution and the serving layer
این جمله تقریباً تعریف کامل این شغل است: چهار لایهٔ یک پایگاه برداری، از ساختار نمایه تا سرویس‌دهی، زیر دست شماست.
Own production readiness - benchmarking against exact search, capacity planning, onboarding new workloads, and the operational tooling to run it at scale
مقایسه با جستجوی دقیق یعنی اندازه گرفتن اینکه جستجوی تقریبی چقدر از جواب درست جا می‌ماند. پذیرفتن بار کاری جدید یعنی تیم‌های دیگر به سیستم شما وصل می‌شوند و باید ظرفیتش را از قبل دیده باشید.
Drive the recall, latency and cost trade-offs - quantization, filtered search, index build and refresh strategy, and how compute and storage are separated and scaled
قلب کار همین تصمیم‌هاست. هر کدام از این اهرم‌ها یکی از سه معیار را بهتر و دیگری را بدتر می‌کند و کار شما انتخاب نقطهٔ درست برای هر بار کاری است.
Scale throughput by an order of magnitude as research and training demand grows, and work out whether the bottleneck is architecture, hardware or engineering bandwidth
ده برابر کردن throughput فقط مسئلهٔ کد نیست؛ گاهی جواب سخت‌افزار بیشتر است و گاهی تغییر معماری. باید بتوانید گلوگاه را با داده نشان دهید.
Extend the retrieval stack toward hybrid retrieval - lexical search and fused ranking alongside vector search
جستجوی برداری به‌تنهایی کافی نیست؛ جستجوی کلیدواژه‌ای و ادغام رتبه‌بندی هم باید به همان سیستم اضافه شود.
Set the evaluation methodology for the system - recall targets, latency objectives, cost per query, and the regression detection that keeps them honest
تعریف «خوب» با شماست: چه recall ای قابل قبول است، تأخیر تا کجا و هزینهٔ هر پرسش چقدر. بعد باید سیستمی بسازید که اگر تغییری این‌ها را بدتر کرد، خودکار هشدار دهد.
Set technical direction for a growing team - lead design reviews, make architectural decisions others build on, and mentor the engineers joining the effort
تیم کوچک است و تصمیم‌های اصلی هنوز باز است. نقش Staff+ یعنی بخش زیادی از اثر شما از طریق تصمیم‌ها و راهنمایی دیگران است، نه فقط کد خودتان.
Share the on-call for the systems you own
مالک سیستم بودن یعنی وقتی خراب شود شما پاسخ می‌دهید. تجربهٔ on-call واقعی در این نقش انتظار است، نه امتیاز.
نتیجه‌گیری کلی
این آگهی تقریباً تعریف کامل نقش مهندس دیتابیس برداری است: مالکیت نمایه، ذخیره‌سازی، اجرای پرسش و سرویس‌دهی، و تصمیم دربارهٔ توازن recall، تأخیر و هزینه. اما سطح آن Staff+ است و تجربهٔ مستقیم ساخت سیستم ANN در پروداکشن می‌خواهد. حقوق سالانه ۳۲۰ تا ۴۸۵ هزار دلار اعلام شده است. Anthropic می‌نویسد ویزا حمایت می‌کند، اما نه برای هر نقش و هر داوطلب. برای مقایسه، آگهی‌های دیگر این حوزه سطح ورود پایین‌تری دارند: Zilliz برای Vector Index Research سه سال تجربه می‌خواهد و ۱۷۵ تا ۲۵۰ هزار دلار اعلام کرده، Pinecone برای تیم Database پنج سال تجربه و ۱۹۰ تا ۲۷۰ هزار دلار، و Elastic برای Senior Software Engineer - Vector Search در آمریکا ۱۳۳٬۱۰۰ تا ۲۱۰٬۶۰۰ دلار (در شهرهای گران‌تر ۱۵۹٬۹۰۰ تا ۲۵۲٬۹۰۰ دلار).
آینده و روندها
پیش‌بینی ۵–۱۰ ساله و مهارت‌هایی که باید یاد بگیرید
BLS آمریکا پیش‌بینی می‌کند اشتغال Software Developers از ۲۰۲۵ تا ۲۰۳۵، ۱۰٪ رشد کند (از ۱٬۷۱۷٬۸۰۰ به ۱٬۸۹۲٬۶۰۰ نفر)، بسیار سریع‌تر از میانگین همهٔ مشاغل. این نزدیک‌ترین گروه رسمی است، چون آگهی‌های این کار عنوان Software Engineer دارند؛ گروه رسمی جداگانه‌ای برای مهندس دیتابیس برداری وجود ندارد. در بریتانیا، ITJobsWatch در شش ماه منتهی به ۲۲ اکتبر ۲۰۲۶، ۴۳ آگهی دائم با مهارت Pinecone شمرده است (همین بازه در ۲۰۲۵: ۶) و ۳۸ آگهی با مهارت pgvector (۲۰۲۵: ۲). این اعداد کوچک‌اند و مهارت را می‌شمارند، نه عنوان شغلی را.
منبع: BLS Occupational Outlook Handbook, projections 2025–35
مهارت‌های نوظهور که باید یاد بگیرید
پیش‌بینی‌های آینده
در گزارش Future of Jobs 2025 مجمع جهانی اقتصاد (WEF)، کارفرمایان شرکت‌کننده در نظرسنجی «متخصصان کلان‌داده» را سریع‌الرشدترین، «متخصصان AI و یادگیری ماشین» را سومین و «توسعه‌دهندگان نرم‌افزار و اپلیکیشن» را چهارمین شغل از نظر رشد درصدی تا ۲۰۳۰ دانسته‌اند.
BLS آمریکا پیش‌بینی می‌کند اشتغال Software Developers از ۲۰۲۵ تا ۲۰۳۵، ۱۰٪ و اشتغال Database Architects، ۹٪ رشد کند. گروه رسمی جداگانه‌ای برای مهندس دیتابیس برداری وجود ندارد.
از منابع چند نکته پیداست. اول، سطح ورود بالاست: کمترین تجربه در آگهی‌هایی که دیدیم سه سال بود و بیشترشان سطح Senior، Staff یا Principal بودند. آگهی‌هایی هم که دقیقاً عنوان «Vector Database Engineer» دارند بیشتر از شرکت‌های مشاوره‌اند و در عمل مهندسی داده‌اند (Azure Data Factory، PySpark و ۶ تا ۱۲ ماه تجربه با ChromaDB، Pinecone یا FAISS). دوم، تعداد کارفرمایان تخصصی کم است و استخدامشان پیوسته نیست: در ۲۲ اکتبر ۲۰۲۶ تابلوی استخدام Qdrant هیچ نقش مهندسی برای هستهٔ موتور نداشت و Weaviate فقط دو آگهی غیرفنی داشت. سوم، جستجوی برداری حالا در پایگاه‌ها و موتورهای عمومی هم هست (MongoDB، Elasticsearch، OpenSearch، PostgreSQL با pgvector، Redis). این دامنهٔ کارفرمایان را بزرگ‌تر می‌کند، ولی یعنی مهارت قابل انتقال (نمایهٔ ANN، درون پایگاه داده، کارایی) از بلد بودن API یک محصول ارزشمندتر است. چهارم، عنوان شغلی ثابت نیست: کسی که فقط عنوان دقیق را جستجو کند، بیشتر فرصت‌ها را نمی‌بیند؛ عبارت‌هایی مثل Vector Search، VectorDB، Search Infrastructure و Database Engineer را هم جستجو کنید.
منابع
اطلاعات این صفحه در تاریخ ۳۰ مهر ۱۴۰۵ از این ۳۸ منبع بررسی شده است.
- Staff+ Software Engineer, VectorDB — Anthropic (job posting)
- Senior Software Engineer, Vector Index Research — Zilliz (job posting)
- Principal Software Engineer - Vector Search - Elasticsearch, US — Elastic (job posting)
- Senior Software Engineer - Vector Search - Elasticsearch, US — Elastic (job posting)
- Senior Software Developer - Vector Search - Elasticsearch, Canada — Elastic (archived posting)
- Senior Software Engineer - Vector Search - Elasticsearch, Ireland — Elastic (archived posting)
- Senior Software Engineer - Vector Search - Elasticsearch, Spain — Elastic (archived posting)
- Senior/Staff Software Engineer, Database Team — Pinecone (job posting)
- database engineer — turbopuffer (job posting)
- Staff Engineer, Search Systems — MongoDB (job posting)
- Vector Database Engineer — Inizio Partners (job posting)
- Software Engineer, Search Infrastructure — OpenAI (job posting)
- Senior RAG Engineer — Newcode.ai (job posting)
- Qdrant Jobs (Ashby board)
- Weaviate Jobs (Ashby board)
- ITJobsWatch — Pinecone (UK job trends and salaries)
- ITJobsWatch — pgvector (UK job trends and salaries)
- BLS Occupational Outlook Handbook — Software Developers, Quality Assurance Analysts, and Testers
- BLS Occupational Outlook Handbook — Database Administrators and Architects
- World Economic Forum — The Future of Jobs Report 2025 (PDF)
- Vector database — Wikipedia
- Hierarchical navigable small world — Wikipedia
- FAISS — Wikipedia
- Milvus (vector database) — Wikipedia
- Malkov & Yashunin — Efficient and robust approximate nearest neighbor search using HNSW graphs (arXiv, 2016)
- Douze et al. — The Faiss library (arXiv, 2024)
- DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node (NeurIPS 2019)
- pgvector — Open-source vector similarity search for Postgres (GitHub)
- Qdrant documentation — Quantization
- turbopuffer docs — Architecture
- kNN search in Elasticsearch — Elastic Docs
- LanceDB — Multimodal Lakehouse for AI
- OpenSearch Documentation — Vector search
- Redis Docs — Vector search concepts
- MongoDB Vector Search Overview — MongoDB Docs
- Yury Malkov — GitHub profile
- Harsha Vardhan Simhadri — personal site
- Qdrant — About us