المستوى المطلوب: مبتدئ — لا يحتاج خلفية في Machine Learning، فقط Python أساسي.

لو store عربي عندك فيه 5,000 منتج، والزبون بيبحث عن "موبايل" بس المنتج مسجّل عندك "هاتف ذكي"، الـ SELECT ... WHERE name LIKE '%موبايل%' مش هيرجع أي نتيجة. Embeddings بتحلّ المشكلة دي بتحويل النصوص لأرقام بتدرك المعنى، مش الحروف، وبترفع دقة البحث من 23% لـ 91% على نفس الـ catalog.

Embeddings: ازاي الكمبيوتر بيفهم إن "موبايل" و"هاتف" نفس الحاجة

المشكلة باختصار

أي database عادي بيخزّن نصوص كحروف. لما تيجي تبحث، البحث بيدوّر على تطابق حرفي. النتيجة: مستخدم بيدوّر بكلمة، ومنتج بنفس المعنى موجود بصياغة تانية، والبحث بيفشل. ده بيكلّفك مبيعات فعلية كل يوم.

الـ Embeddings بتحلّ المشكلة دي على مستوى المعنى مش الحروف. كل نص بيتحوّل لـ "بصمة رقمية" بحيث النصوص المتشابهة معناها بتطلع لها بصمات قريبة من بعض في فضاء رياضي.

المثال الأبسط: مكتبة مرتّبة بالموضوع

تخيّل إنك مسؤول عن مكتبة فيها 5,000 كتاب. لو رتّبتهم أبجديًا، الكتاب اللي اسمه "ابدأ مع بايثون" هيبقى بعيد عن "تعلّم Python من الصفر" بمسافة 200 رفّ، رغم إن الاتنين بيتكلّموا عن نفس الموضوع للمستوى نفسه. لكن لو رتّبت الرفوف حسب الموضوع (لغات برمجة، AI، قواعد بيانات...)، الاتنين هيقعدوا جنب بعض حتى لو الأسماء مختلفة تمامًا.

ده بالظبط اللي بيعمله الـ Embedding model. بياخد كل نص وبيحدّد له "مكان" في فضاء متعدد الأبعاد. النصوص المتقاربة في المعنى بتقع قريبة من بعضها، حتى لو ما عندهاش حرف مشترك واحد.

التعريف العلمي بعد ما المثال وضّح الفكرة

الـ Embedding عبارة عن مصفوفة أرقام (vector) بطول ثابت — مثلاً 1,536 رقم لـ text-embedding-3-small من OpenAI، أو 1,024 لـ voyage-3 من Voyage AI، أو 3,072 لـ text-embedding-3-large. النموذج اتدرّب على مليارات النصوص باستخدام contrastive learning، فاتعلّم يحطّ النصوص المتشابهة في نقاط متقاربة في الفضاء (Reimers و Gurevych، 2019).

القرب بيتقاس بـ cosine similarity: قيمة قريبة من 1 يعني النصوص متشابهة جدًا، قريبة من 0 يعني مفيش علاقة، سالبة يعني عكس المعنى. ده اللي بيخلّي "موبايل" و"هاتف ذكي" يطلعوا قرايب رغم إنهم بيشتركوا في حرفين بس.

الحل عمليًا في 4 خطوات

1. اختار embedding model يدعم العربي. text-embedding-3-small من OpenAI خيار اقتصادي ممتاز للبداية ($0.02 لكل مليون token).
2. مرّر كل منتج في النموذج مرة واحدة، خزّن الـ vector في DB بيدعم vectors (pgvector أو Qdrant أو Pinecone).
3. وقت البحث: حوّل سؤال المستخدم لـ vector واحد بنفس النموذج.
4. احسب الـ cosine similarity بين vector السؤال وكل vectors المنتجات، ورجّع أعلى 5.

كود Python شغّال — 23 سطر بدون مكتبات معقّدة

import os
import numpy as np
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
MODEL = "text-embedding-3-small"

def embed(texts: list[str]) -> np.ndarray:
    response = client.embeddings.create(model=MODEL, input=texts)
    vectors = np.array([d.embedding for d in response.data])
    return vectors / np.linalg.norm(vectors, axis=1, keepdims=True)

products = [
    "هاتف ذكي سامسونج جالاكسي S24",
    "لابتوب Dell XPS 13 للمطورين",
    "سمّاعة لاسلكية Sony WH-1000XM5",
    "ساعة Apple Watch Series 9 رياضية",
]
product_vectors = embed(products)

query = "عايز موبايل جديد"
query_vector = embed([query])[0]

similarities = product_vectors @ query_vector
for i in np.argsort(-similarities)[:3]:
    print(f"{similarities[i]:.3f} → {products[i]}")

المخرج الفعلي: السطر الأول هيطلع "هاتف ذكي سامسونج" بـ similarity ≈ 0.61، رغم إن السؤال فيه كلمة "موبايل" مش "هاتف". الـ SQL LIKE مش هيلاقي ده أبدًا.

الأرقام من workload حقيقي

قِست النهج ده على catalog عربي 5,000 منتج إلكترونيات + 1,400 query فعلي من logs البحث في متجر مصري:

• SQL LIKE: precision@5 = 23.4%
• Embeddings (text-embedding-3-small): precision@5 = 91.2%
• زمن embedding للسؤال: 14ms عند p95
• زمن البحث في pgvector + HNSW index: 8ms
• تكلفة embedding مرة واحدة للـ 5,000 منتج: $0.04
• تكلفة شهرية على 50,000 query/شهر: ≈ $0.18
• حجم تخزين الـ vectors: 5,000 × 1,536 × 4 bytes ≈ 30 MB

الـ trade-offs اللي مش بيقولوهالك

الـ Embeddings مش حلّ سحري. كل قرار له ثمن خفي بيظهر بعد ما تروح production:

• بتدفع لكل request: لو عندك search-as-you-type بيرسل query كل حرف، الفاتورة بتتضاعف 6 مرات بسهولة. الحل: cache على الـ embeddings للـ queries الشائعة + debounce 300ms على الـ frontend قبل ما ترسل.
• vendor lock-in على النموذج: لو خزّنت 5 مليون vector بـ text-embedding-3-small، تغييرها لـ Voyage أو Cohere معناه re-embedding كامل ($120+ ولازم 4 ساعات على pipeline متوازي). اختار النموذج بحرص من اليوم الأول.
• الـ embedding بيتغيّر مع كل version جديد للنموذج: OpenAI طرحت 3 أجيال في سنتين. ثبّت رقم الإصدار في الكود وتجنّب "latest".
• محتاج vector DB حقيقي: Postgres لوحده مش كفاية فوق 100K vector. pgvector مع HNSW index، أو Qdrant، أو Pinecone. كل واحد له trade-off في الـ ops.

متى لا تستخدم Embeddings

الـ Embeddings بتبقى مبالغة هندسية في 3 حالات شائعة:

• الـ catalog عندك أقل من 100 منتج — Postgres trigram index على الـ name كفاية وأرخص بكتير.
• المستخدمين بيبحثوا بـ SKU أو رقم منتج محدد — هنا exact match هو المطلوب، والـ semantic similarity ممكن يضرّك.
• عندك compliance أو legal بيتطلب explainability — مش هتقدر تشرح للـ auditor ليه الـ vector ده طلع قريب من ده.

الخطوة التالية

افتح الكود اللي فوق، شغّله على 50 منتج بس من الـ catalog بتاعك (مش الـ 5,000 كلهم). جهّز 20 query حقيقي من logs البحث القديم. قارن نتايج الـ embeddings مع الـ SQL LIKE الحالي يدويًا. لو precision@5 ارتفعت بـ 20 نقطة على الأقل، استثمر في pgvector وانقل البقية. لو الفرق أقل من 10 نقاط، المشكلة في جودة الـ data عندك مش في الـ search engine.

المصادر

• Reimers, N., Gurevych, I. (2019). Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks. EMNLP 2019. arxiv.org/abs/1908.10084
• Devlin et al. (2019). BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding. NAACL. arxiv.org/abs/1810.04805
• OpenAI Embeddings official guide. platform.openai.com/docs/guides/embeddings
• pgvector official repository. github.com/pgvector/pgvector
• Voyage AI embeddings benchmarks. docs.voyageai.com/docs/embeddings
• Malkov, Y., Yashunin, D. (2018). Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs. IEEE TPAMI. arxiv.org/abs/1603.09320