Embedding'u sisu.md 10.0 KB
1. Embedding'u mudeli nõuded
Sinu RAG pipeline'i eesmärk on teadusartikleid (PDF) indekseerida ja semantiliselt otsida. Seega nõuded:[milvus]
A. Täpsus (MTEB või sarnane skoor)
Mis see on: MTEB (Massive Text Embedding Benchmark) on standardne benchmark 56 erinevat teksti‑ülesannet hõlmavalt (retrieval, clustering, classification jne). Mudel, mis skoorib MTEB‑l kõrgemalt, tõenäoliselt leiab semantiliselt sarnasemad dokumendid.[modal][youtube]
Praktikas: bge-small-en-v1.5 (384‑dim) on MTEB‑l ~62–64 punkti (keskmine kõigi ülesannete üle), mis on väga hea väikese mudeli kohta.[huggingface]
Miks oluline: kõrgem MTEB = paremad otsingutulemused = täpsemad chunkid LLM‑ile kontekstiks = paremad vastused.[galileo]
B. Domeen (valdkonnasobivus)
Teadusartiklid: üldotstarbelised mudelid (bge, e5, OpenAI) töötavad teadusartiklitega hästi, sest MTEB sisaldab arvukalt akadeemilist sisu.[luminary]
Kui vajad spetsiifilisust (nt ainult meditsiin): BioBERT, SciBERT.[milvus]
Sinu juhtum (liikluskäitumine, õnnetused, teede ohutus): üldised mudelid suudavad seda väga hästi, sest "accidents", "risk", "behavior" on igapäevane keel (mitte väga kitsa domeeni slang).[milvus]
C. Latentsus (kiirus)
Mis see on: aeg, mis kulub ühe embedding'u genereerimiseks (millisekundi vs sekundit).[pinecone]
Sinu põhjendus:
PDF→chunk ekstraktimine on offline protsess (kord päevas / nädalas), seega ei vaja millisekundilist kiirust.[particula]
Päringute embedding (kasutaja küsimus) peab olema kiire (<100 ms), et süsteem tundub vastutav.[systemoverflow]
bge-small-en-v1.5: ~20–50 ms ühe päringu jaoks CPU peal, <10 ms GPU peal – praktikas piisav.[huggingface]
D. Mälukasutus / ressursid
Miks oluline:[systemoverflow]
Mudeli suurus mälus (MB): väiksem mudel → kiirem loading ja jooksutamine väiksemal riistvaral.
Vektori suurus baasis: iga chunk = üks vektor × dimensioonid × andmetüüp (nt 384 × float32 = 1536 byte = ~1.5 KB).[particula]
Sinu ~50–200 artikli juhul: ca 1000–5000 chunki × 1.5 KB = 7–15 MB. Ei ole probleem.[particula]
Kui sul oleks miljon chunki: 384‑dim = ~1.4 GB, 768‑dim = ~2.8 GB, 1536‑dim = ~5.6 GB.[systemoverflow]
Sinu juhtum: väike korpus (mõned GB PDF‑e) → mälu pole kitsaskoht, seega võid valida täpsuse, mitte mälu järgi.[particula]
2. Dimensiooni kompromissid: 384 vs 768 vs 1024
| Dimensioon | Täpsus (MTEB) | Mälukasutus (1M chunki) | Päringukiirus | Soovitus |
|---|---|---|---|---|
| 384 (bge-small-en-v1.5) | ~62–64 | ~1.4 GB | Kiire (~20–50 ms CPU) | Väikese/keskmise korpuse jaoks parim valik [huggingface] |
| 768 (bge-base-en-v1.5, BERT-base) | ~64–66 | ~2.8 GB | Mõõdukas (~40–80 ms) | Suurem korpus + vajad +2–3% täpsust [systemoverflow] |
| 1024 (bge-large, E5‑large) | ~66–68 | ~3.7 GB | Aeglasem (~60–120 ms) | Suur korpus (miljonid dokumendid) või väga kitsad domeeni nüansid [milvus] |
| 1536+ (OpenAI text-embedding-3-large, 3072) | ~68–70 | 5.6–11 GB | Aeglane | Maksimum täpsus, kallis storage, ebaperformantne IVFFlat‑iga pgvectoris [systemoverflow] |
Peamine järeldus: liikumine 384→768 annab ~2–4 punkti MTEB‑l, aga maksab 2× mälu ja 1.5–2× aeglusust. Liikumine 768→1024 annab vähem kui 2 punkti juurde, maksab veelgi rohkem.[systemoverflow]
3. Konkreetne soovitus sinu projektile
Olukord
Korpus: ~20–200 teadusartiklit (PDF), ingliskeelsed liiklusohutuse/transpordi valdkonnas.
Kasutus: lokaalne RAG, päringud eesti ja inglise keeles, vastused genereerib lokaalne LLM (unsloth 120B).
Riistvara: lokaalne süsteem (ohmu), postgres + pgvector, ei ole "million‑scale" probleem.
Soovitus: bge-small-en-v1.5 (384‑dim)
Põhjused:[zilliz]
Täpsus: MTEB skoor ~62–64 on piisav väikese/keskmise korpuse jaoks.[modal]
Kiirus: CPU peal ~20–50 ms päring (ohmu on AMD Zen + ROCm, seega GPU peal veelgi kiirem).[huggingface]
Mälukasutus: ~1.4 GB 1M chunki kohta (sinu 1000–5000 chunki = paar MB).[particula]
pgvector IVFFlat: 384‑dim sobib ideaalselt (max 2000 lubatud, aga mida väiksem, seda kiiremini indeks töötab).[sarahglasmacher]
Laialt kasutatud: hea dokumentatsioon, tööriistade tugi (sentence‑transformers, Weaviate, LangChain).[docs.lancedb]
Alternatiiv: kui hiljem korpus kasvab 10 000+ artiklini või märkad, et täpsus ei ole piisav → bge-base-en-v1.5 (768‑dim). Aga testimata pole mõtet üle optimeerida.[greennode]
4. Tegevusplaan (samm‑sammult)
| Samm | Tegevus | Tulemus |
|---|---|---|
| 1. Paigalda ja testi bge-small-en-v1.5 | pip install sentence-transformers, src/embed_utils.py (juba tehtud), testi get_embedding() |
Toimiv 384‑dim embedding [huggingface] |
| 2. Täida chunks.embedding | python src/embed_chunks.py (juba kirjutatud) |
Kõik chunkid saavad 384‑dim vektori [tigerdata] |
| 3. Testi semantilist otsingut | Loo src/query_semantic.py, tee päring "young driver accident risk" |
Top‑5 asjakohasemat chunki tuleb [sarahglasmacher] |
| 4. Lisa LLM vastus | Top chunkid → prompt → unsloth 120B (llama.cpp) → vastus | Töötav lokaalne RAG [neon] |
| 5. Hinda täpsust | Tee 10–20 testi‑küsimust, kontrolli kas vastused on head | Kui hästi → valmis; kui mitte → kaaluge bge-base (768‑dim) [galileo] |
| 6. (Valikuline) Optimiseeri kiiruse jaoks | Kui kiirus on probleem, kasuta quantization (int8) või HNSW indeks pgvectoris | Kuni 2× kiirem otsing [systemoverflow] |
5. Kokkuvõte
| Kriteerium | Sinu nõue | bge-small-en-v1.5 sobivus |
|---|---|---|
| Täpsus (MTEB) | Hea semantiline otsing | 62–64 (piisav) ✅ [huggingface] |
| Latentsus | Päring <100 ms | 20–50 ms CPU ✅ [huggingface] |
| Mälukasutus | ~1000–5000 chunki | ~7–15 MB (väga väike) ✅ [particula] |
| Dimensioon pgvector | <2000 IVFFlat jaoks | 384 (ideaalne) ✅ [sarahglasmacher] |
| Domeen | Teadusartiklid (liiklus) | Üldine mudel sobib ✅ [milvus] |
| Kohalikult jooksev | Ei taha API kulusid | Jah (CPU/GPU) ✅ [huggingface] |
Järeldus: jätka bge-small-en-v1.5 (384‑dim)‑iga. Kui kõik on töökorras ja testid näitavad, et semantiline otsing töötab, saame järgmise sammuna teha query_semantic.py + unsloth 120B integratsioon ja sul on täielik lokaalne RAG süsteem valmis.[huggingface]
Kas jätkame query_semantic.py loomisega?