08 - Embeddings¶

Az embeddingek numerikus vektorokként reprezentálják a tartalmat, így a szemantikailag hasonló elemek matematikailag összehasonlíthatók.

Alapját adják a semantic searchnek, clusteringnek, recommendationnek, deduplicationnek és a RAG retrievalnek.

Alap mentális modell¶

Egy embedding model az inputot vektorrá alakítja:

"How do I reset my password?"
        |
        v
embedding model
        |
        v
[0.12, -0.31, 0.88, ...]

Egy hasonló jelentésű másik mondatnak a vector space közeli régiójába kell kerülnie:

"I forgot my password and need a new one"

A konkrét számok ember számára nem jelentenek sokat. A relatív pozíciójuk a fontos.

Miért hasznosak az embeddingek?¶

A keyword search egyező kifejezéseket keres. Az embedding search a jelentést próbálja megragadni.

Példa:

Query:
"car will not start"

Document:
"vehicle ignition troubleshooting"

A két szövegben alig lehet közös szó, mégis egy jó embedding model közel helyezheti őket egymáshoz.

Similarity¶

Egy similarity function vektorokat hasonlít össze. Gyakori megoldás a cosine similarity, dot product és Euclidean distance.

A vector dimensionöket általában nem kézzel manipuláljuk. A fontos application-level koncepció:

query embedding
       |
compare against stored embeddings
       |
rank nearest items

Semantic search pipeline¶

Egy egyszerűsített keresőrendszer:

Documents
   |
chunk / prepare
   |
embedding model
   |
store vectors + metadata

User query
   |
embedding model
   |
vector similarity search
   |
Top matching documents

Ez a RAG egyik alapvető building blockja.

Az embedding nem summary¶

Az embedding nem olvasható, tömörített szöveg, amelyből később visszafejthető az eredeti dokumentum.

Inkább összehasonlításhoz hasznos koordinátaként gondolj rá, nem compressed document storage-ként.

Az eredeti contentet vagy annak referenciáját továbbra is tárolni kell.

Az embeddingek model-specifikusak¶

Különböző embedding modellek vektorait általában nem érdemes ugyanabban az indexben keverni.

Embedding model váltásakor a dokumentumokat jellemzően újra kell embedelni.

Így az embedding-model választás a data architecture része lesz.

Dimensions¶

Az embedding vektorok több száz vagy több ezer numerikus dimenziót tartalmazhatnak.

A több dimension nem jelent automatikusan jobb retrievalt. A quality a modelltől, domaintől, adattól és evaluationtől függ.

A chunking számít¶

Tegyük fel, hogy egy teljes 100 oldalas kézikönyvet egyetlen vektorként embedelünk. Egy kis bekezdésre vonatkozó query gyengén match-elhet, mert a vector az egész dokumentumot reprezentálja.

Ezért a contentet gyakran kisebb egységekre bontjuk:

Manual
  |
  +--> chunk 1 -> vector
  +--> chunk 2 -> vector
  +--> chunk 3 -> vector

A chunking strategy erősen befolyásolja a retrieval qualityt, és RAG-nál részletesebben visszatérünk rá.

A metadata továbbra is fontos¶

Sok alkalmazásnál a vector similarity önmagában nem elég.

Példa document record:

{
  "id": "doc-123",
  "team": "payments",
  "version": "7.2",
  "language": "en",
  "embedding": [0.12, -0.31, 0.88]
}

A search kombinálhatja a semantic similarityt filterekkel:

semantic match
AND team = payments
AND version = 7.2

Ez gyakran biztonságosabb és pontosabb a pure vector searchnél.

Similarity nem egyenlő truth-val¶

A legközelebbi vector csak a keresett halmaz leginkább hasonló eleme. Nem garantálja, hogy a dokumentum:

megválaszolja a kérdést,
helyes,
aktuális,
engedélyezett az adott user számára.

A retrieval resultokat továbbra is application-level filteringgel és evaluationnel kell kezelni.

Példa: internal documentation search¶

Tegyük fel, hogy egy developer ezt kérdezi:

"Why is our build failing after the Java upgrade?"

Az alkalmazás embedelheti a queryt, majd chunkokat kereshet például:

Java migration guide,
build troubleshooting notes,
Maven/Tycho documentation,
previous incident summaries.

A retrieved text ezután átadható egy LLM-nek szintézisre.

query
  |
embedding
  |
semantic retrieval
  |
relevant text
  |
LLM
  |
answer

További use case-ek¶

Clustering¶

Szemantikailag kapcsolódó dokumentumok vagy support ticketek csoportosítása előre definiált label nélkül.

Recommendations¶

A user korábbi interakcióihoz hasonló product, article, job vagy content keresése.

Deduplication¶

Közel duplikált content felismerése eltérő megfogalmazás esetén is.

Classification support¶

Egy input embedding összehasonlítása ismert category example-ökkel vagy centroidokkal.

Vector database-ek¶

Egy vector database vagy vector-capable search engine embeddingeket tárol és hatékony nearest-neighbor searchöt végez.

A fontos foundation koncepció nem az, melyik terméket használjuk, hanem a responsibility split:

embedding model -> vectors létrehozása
vector store     -> vectors indexelése és keresése
application      -> filtering, validation, original content retrieval
LLM              -> opcionálisan reasoning a retrieved content felett

Hybrid search¶

A semantic search és a keyword search különböző problémákat old meg.

Egy erős retrieval system kombinálhatja:

keyword/BM25 score
        +
vector similarity
        +
metadata filters
        +
reranking

Ezt hybrid retrievalnek nevezzük, és RAG-nál fontos lesz.

Evaluation¶

Ne feltételezd, hogy a semantic search jó csak azért, mert néhány demo query látványosan működik.

Készíts kis retrieval evaluation setet:

query -> expected relevant documents

Majd mérd, hogy a helyes dokumentumok valóban a lista elején jelennek-e meg.

Developer takeaway¶

Az embeddingek a semantic similarityt software által kereshető és rangsorolható formává alakítják.

Erősek, de nem helyettesítik a source documenteket, permissionöket, metadatát, keyword searchöt vagy evaluationt. Egy retrieval signalnak tekintsd őket egy nagyobb rendszeren belül.