Multimodal Embedding & Reranker Models with Sentence Transformers

Sentence Transformers is a Python library for using and training embedding and reranker models for applications like retrieval augmented generation, semantic search, and more. With the v5.4 update, you can now encode and compare texts, images, audio, and videos using the same familiar API. In this blogpost, I'll show you how to use these new multimodal capabilities for both embedding and reranking.

Multimodal embedding models map inputs from different modalities into a shared embedding space, while multimodal reranker models score the relevance of mixed-modality pairs. This opens up use cases like visual document retrieval, cross-modal search, and multimodal RAG pipelines.

Table of Contents

• What are Multimodal Models?
• Installation
• Multimodal Embedding Models
• Loading a Model
• Encoding Images
• Cross-Modal Similarity
• Encoding Queries and Documents
• Multimodal Reranker Models
• Ranking Mixed-Modality Documents
• Predicting Pair Scores
• Retrieve and Rerank
• Input Formats and Configuration
• Supported Input Types
• Checking Modality Support
• Processor and Model kwargs
• Supported Models
• Additional Resources

What are Multimodal Models?

Traditional embedding models convert text into fixed-size vectors. Multimodal embedding models extend this by mapping inputs from different modalities (text, images, audio, or video) into a shared embedding space. This means you can compare a text query against image documents (or vice versa) using the same similarity functions you're already familiar with.

Similarly, traditional reranker (Cross Encoder) models compute relevance scores between pairs of texts. Multimodal rerankers can score pairs where one or both elements are images, combined text-image documents, or other modalities.

For example, you can compare a text query against image documents, find video clips matching a description, or build RAG pipelines that work across modalities.

Installation

Multimodal models require some extra dependencies. Install the extras for the modalities you need (see Installation for more details):

# For image support
pip install -U "sentence-transformers[image]"

# For audio support
pip install -U "sentence-transformers"

# For video support
pip install -U "sentence-transformers"

# Mix and match as needed
pip install -U "sentence-transformers[image,video,train]"

VLM-based models like Qwen3-VL-2B require a GPU with at least ~8 GB of VRAM. For the 8B variants, expect ~20 GB. If you don't have a local GPU, consider using a cloud GPU service or Google Colab. On CPU, these models will be extremely slow; text-only or CLIP models are better suited for CPU inference.

Multimodal Embedding Models

Loading a Model

Loading a multimodal embedding model works exactly like loading a text-only model:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

The revision argument is required for now because the integration pull requests for these models are still pending. Once they're merged, you'll be able to load them without specifying a revision.

The model automatically detects which modalities it supports, so there's nothing extra to configure. See Processor and Model kwargs if you want to control things like image resolution or model precision.

Encoding Images

With a multimodal model loaded, model.encode() accepts images alongside text. Images can be provided as URLs, local file paths, or PIL Image objects (see Supported Input Types for all accepted formats):

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

# Encode images from URLs
img_embeddings = model.encode([
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg",
])
print(img_embeddings.shape)
# (2, 2048)

Cross-Modal Similarity

You can compute similarities between text embeddings and image embeddings, since the model maps both into the same space:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

# Encode images
img_embeddings = model.encode([
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg",
])

# Encode text queries (one matching + one hard negative per image)
text_embeddings = model.encode([
 "A green car parked in front of a yellow building",
 "A red car driving on a highway",
 "A bee on a pink flower",
 "A wasp on a wooden table",
])

# Compute cross-modal similarities
similarities = model.similarity(text_embeddings, img_embeddings)
print(similarities)
# tensor([[0.5115, 0.1078],
# [0.1999, 0.1108],
# [0.1255, 0.6749],
# [0.1283, 0.2704]])

As expected, "A green car parked in front of a yellow building" is most similar to the car image (0.51), and "A bee on a pink flower" is most similar to the bee image (0.67). The hard negatives ("A red car driving on a highway", "A wasp on a wooden table") correctly receive lower scores.

You might notice that even the best matching scores (0.51, 0.67) aren't very close to 1.0. This is due to the modality gap: embeddings from different modalities tend to cluster in separate regions of the space. Cross-modal similarities are typically lower than within-modal ones (e.g., text-to-text), but the relative ordering is preserved, so retrieval still works well.

Encoding Queries and Documents

For retrieval tasks, encode_query() and encode_document() are the recommended methods. Many retrieval models prepend different instruction prompts depending on whether the input is a query or a document, similar to how chat models might apply different system prompts depending on the goal. Model authors can specify their prompts in the model config, and encode_query() / encode_document() automatically load and apply the correct one:

• encode_query() uses the model's "query" prompt (if available) and sets task="query".
• encode_document() uses the first available prompt from "document", "passage", or "corpus", and sets task="document".

Under the hood, both are thin wrappers around encode(), they just handle prompt selection for you. Here's what cross-modal retrieval looks like:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

# Encode text queries with the query prompt
query_embeddings = model.encode_query([
 "Find me a photo of a vehicle parked near a building",
 "Show me an image of a pollinating insect",
])

# Encode document screenshots with the document prompt
doc_embeddings = model.encode_document([
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg",
])

# Compute similarities
similarities = model.similarity(query_embeddings, doc_embeddings)
print(similarities)
# tensor([[0.3907, 0.1490],
# [0.1235, 0.4872]])

These methods accept the same input types as encode() (images, URLs, multimodal dicts, etc.) and pass through the same parameters. For models without specialized query/document prompts, they behave identically to encode().

Multimodal Reranker Models

Multimodal reranker (CrossEncoder) models score the relevance between pairs of inputs, where each element can be text, an image, audio, video, or a combination. They tend to outperform embedding models in terms of quality, but are slower since they process each pair individually. The currently available pretrained multimodal rerankers focus on text and image inputs, but the architecture supports any modality that the underlying model can handle.

Ranking Mixed-Modality Documents

The rank() method scores and ranks a list of documents against a query, supporting mixed modalities:

from sentence_transformers import CrossEncoder

model = CrossEncoder("Qwen/Qwen3-VL-Reranker-2B", revision="refs/pr/11")

query = "A green car parked in front of a yellow building"
documents = [
 # Image documents (URL or local file path)
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg",
 # Text document
 "A vintage Volkswagen Beetle painted in bright green sits in a driveway.",
 # Combined text + image document
 {
 "text": "A car in a European city",
 "image": "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 },
]

rankings = model.rank(query, documents)
for rank in rankings:
 print(f"{rank['score']:.4f}\t(document {rank['corpus_id']})")
"""
0.9375 (document 0)
0.5000 (document 3)
-1.2500 (document 2)
-2.4375 (document 1)
"""

The reranker correctly identifies the car image (document 0) as the most relevant result, followed by the combined text+image document about a car in a European city (document 3). The bee image (document 1) scores lowest.

Keep in mind that the modality gap can influence absolute scores: text-image pair scores may occupy a different range than text-text or image-image pair scores.

You can also check which modalities a reranker supports using modalities and supports(), just like with embedding models:

print(model.modalities)
# ['text', 'image', 'video', 'message']

print(model.supports("image"))
# True

# Check if the model supports a specific pair of modalities
print(model.supports(("image", "text")))
# True

Predicting Pair Scores

You can also use predict() to get raw relevance scores for specific pairs of inputs:

from sentence_transformers import CrossEncoder

model = CrossEncoder("jinaai/jina-reranker-m0", trust_remote_code=True)

scores = model.predict([
 ("A green car", "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg"),
 ("A bee on a flower", "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg"),
 ("A green car", "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg"),
])
print(scores)
# [0.9389156 0.96922314 0.46063158]

Retrieve and Rerank

A common pattern is to use an embedding model for fast initial retrieval, then refine the top results with a reranker:

from sentence_transformers import SentenceTransformer, CrossEncoder

# Step 1: Retrieve with an embedding model
embedder = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

query = "revenue growth chart"
query_embedding = embedder.encode_query(query)

# Pre-compute corpus embeddings (do this once, then store them)
document_screenshots = [
 "path/to/doc1.png",
 "path/to/doc2.png",
 # ... potentially millions of document screenshots
]
corpus_embeddings = embedder.encode_document(document_screenshots, show_progress_bar=True)

# Simple cosine similarity retrieval, viable as long as embeddings fit in memory
similarities = embedder.similarity(query_embedding, corpus_embeddings)
top_k_indices = similarities.argsort(descending=True)[0][:10]

# Step 2: Rerank the top-k results with a reranker model
reranker = CrossEncoder("nvidia/llama-nemotron-rerank-vl-1b-v2", trust_remote_code=True)

top_k_documents = [document_screenshots[i] for i in top_k_indices]
rankings = reranker.rank(query, top_k_documents)
for rank in rankings:
 print(f"{rank['score']:.4f}\t{top_k_documents[rank['corpus_id']]}")

Since the corpus embeddings are pre-computed, the initial retrieval is fast even over millions of documents. The reranker then provides more accurate scoring over the smaller candidate set.

Input Formats and Configuration

Supported Input Types

Multimodal models accept a variety of input formats. Here's a summary of what you can pass to model.encode():

Checking Modality Support

You can check which modalities a model supports using the modalities property and supports() method:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

# List all supported modalities
print(model.modalities)
# ['text', 'image', 'video', 'message']

# Check for a specific modality
print(model.supports("image"))
# True
print(model.supports("audio"))
# False

The "message" modality indicates that the model accepts chat-style message inputs with interleaved content. In practice, you rarely need to use this directly. When you pass strings, URLs, or multimodal dicts, the model converts them to the appropriate message format internally. Sentence Transformers supports two message formats:

1. Structured (most VLMs, e.g. Qwen3-VL): Content is a list of typed dicts, e.g. [{"type": "text", "text": "..."}, {"type": "image", "image": ...}]
2. Flat (e.g. Deepseek-V3): Content is a direct value, e.g. "some text"

The format is auto-detected from the model's chat template.

Since all inputs get converted into the same message format internally, you can mix input types in a single encode() call:

embeddings = model.encode([
 # A text input
 "A green car parked in front of a yellow building",
 # An image input (URL)
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 # A combined text + image input
 {
 "text": "A car in a European city",
 "image": "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 },
])

Processor and Model kwargs

You may want to control image resolution bounds or model precision. Use processor_kwargs and model_kwargs when loading the model:

model = SentenceTransformer(
 "Qwen/Qwen3-VL-Embedding-2B",
 model_kwargs={"attn_implementation": "flash_attention_2", "torch_dtype": "bfloat16"},
 processor_kwargs={"min_pixels": 28 * 28, "max_pixels": 600 * 600},
 revision="refs/pr/23",
)

processor_kwargs controls how inputs are preprocessed (e.g., image resolution bounds). Higher max_pixels means higher quality but more memory and compute. These are

The post Multimodal Embedding & Reranker Models with Sentence Transformers first appeared on Hard Wired.

Glosář AI a LLM termínů

Úvod

Svět a příslib umělé inteligence, zejména velkých jazykových modelů (LLM), přináší nadšení a možnosti. Přináší také novou terminologii, které je třeba porozumět.

Tento glosář se zaměřuje na AI, RAG a velké jazykové modely, aby vám pomohl rychle zvládnout koncepty strojového učení.

Agentic RAG

Agentic RAG je přístup k vytváření AI asistentů a agentů pomocí LLM, který zahrnuje komplexní uvažování, vícekrokové plánování, volání funkcí a používání nástrojů.

Hlavní výhoda Agentic RAG spočívá ve schopnosti volat nástroje pro vyhledávání informací a provádění úkolů.

Například pokud požádáte AI asistenta postaveného na Agentic RAG o porovnání příjmů Apple a Microsoft v roce 2022, může analyzovat dotaz a dvakrát zavolat nástroj pro finanční výkazy – jednou pro Apple a jednou pro Microsoft. Poté sloučí výsledky obou volání a vytvoří požadovanou odpověď.

Attention (Pozornost)

Mechanismy pozornosti ve velkých jazykových modelech (LLM) jsou základní komponenty, které těmto modelům umožňují efektivněji zpracovávat a rozumět textu. Byly představeny Vaswani et al. v článku "Attention is All You Need".

Klíčovou inovací je self-attention (sebe-pozornost), kde model vypočítává skóre pozornosti mezi každým párem tokenů ve vstupní sekvenci. Tato skóre určují, kolik pozornosti věnovat každému tokenu při generování výstupu.

Mechanismy pozornosti byly klíčové pro pokrok v NLP a pohánějí aplikace jako strojový překlad a chatboty.

ChatGPT

ChatGPT je konverzační chatbot vyvinutý společností OpenAI. Je založen na architektuře GPT (Generative Pre-trained Transformer), což je typ modelu hlubokého učení navržený k porozumění a generování textu podobného lidskému.

Základní technologií ChatGPT je neuronová síť typu transformer, která se vyznačuje mechanismem self-attention.

Jednou z výrazných vlastností ChatGPT je schopnost vést otevřené konverzace s uživateli. Na rozdíl od mnoha jiných chatbotů, které fungují na základě předdefinovaných pravidel, ChatGPT dynamicky generuje odpovědi na základě vstupu.

Je důležité poznamenat, že ChatGPT není neomylný – spoléhá na trénovací data a může někdy produkovat nepřesné odpovědi (tzv. halucinace).

Chunking (Dělení na části)

Chunking je proces používaný ke zvýšení efektivity a přesnosti vyhledávání informací v NLP úlohách. V RAG je vstupní text rozdělen na menší, zvládnutelné jednotky nazývané "chunky". Tyto chunky mohou být věty, odstavce nebo jiné specifické rozdělení většího textu.

Účel chunkingu:

• Efektivita: Práce s menšími chunky zrychluje proces vyhledávání a vyžaduje méně výpočetního výkonu.
• Přesnost: Chunky poskytují cílenější informace, snižují šum a zlepšují relevanci získaných dat.
• Škálovatelnost: Chunking umožňuje systému efektivněji zpracovávat větší dokumenty.

V RAG je po chunkování každý chunk indexován a uložen v retrieval systému (jako text i jako embedding vektor).

Embeddings (Vektorové reprezentace)

V kontextu LLM jsou vektorové embeddingy typem reprezentace, která zachycuje sémantický význam nebo kontext slov či vět v kompaktní formě. Jsou to v podstatě vektory reálných čísel, kde každá dimenze může reprezentovat jinou vlastnost zachycující něco o významu daného konceptu.

Vektorové embeddingy jsou také známé jako "husté reprezentace" (dense representations), na rozdíl od tradičnějších "řídkých reprezentací" (sparse representations).

Typy embeddingů:

• Word embeddings: mapují každé slovo na vektorový embedding
• Sentence embeddings: mapují celou větu, odstavec nebo jakýkoli textový chunk do vektorového embeddingu

Vektorové embeddingy slouží jako vstup pro různé NLP úlohy jako klasifikace textu, analýza sentimentu nebo strojový překlad.

Explainability (Vysvětlitelnost)

Ve světě RAG vysvětlitelnost znamená, že systém může ukázat přesně, jak dospěl ke své odpovědi, včetně odkazů na původní zdroje.

Namísto toho, abyste přemýšleli, odkud informace pochází, systém může poskytnout jasné reference nebo citace, podobně jako poznámky pod čarou, takže si můžete detaily ověřit sami.

Tento transparentní přístup buduje důvěru a pomáhá porozumět uvažování za odpovědí.

Few Shot Learning

V kontextu LLM se koncept few shot learning vztahuje na schopnost poskytnout LLM příklady úkolu, který chcete provést, a tím zlepšit jeho výkon.

Zero shot příklad:
"Přelož následující z angličtiny do francouzštiny: How are you today?"

Few shot příklad:
"Přelož následující z angličtiny do francouzštiny:

1. Hello → Bonjour
2. Goodbye → Au revoir
   Přelož: How are you today?"

V druhém případě poskytujeme dva příklady dobrého překladu, čímž pomáháme modelu lépe splnit požadovaný úkol.

Fine-tuning (Doladění)

Fine-tuning je způsob provádění transfer learningu. Při fine-tuningu vezmete předtrénovaný model a pokračujete v jeho trénování na specifickém (obvykle menším) datasetu.

Běžné techniky fine-tuningu:

• Pokračování v tréninku celé neuronové sítě na specifickém datasetu
• Zmrazení některých vrstev a trénování ostatních
• Přidání nové vrstvy pro nový typ úkolu a trénování pouze této vrstvy

Fine-tuning je mnohem méně komplikovaný a výrazně levnější úkol než plné trénování LLM.

Nedávno byly navrženy techniky jako LORA (low-rank-adaptation), které fine-tuning ještě zrychlují a zlevňují při zachování podobného výkonu.

GPTs (Vlastní GPT)

V listopadu 2023 OpenAI představila možnost uživatelů nebo vývojářů vytvářet vlastní verze ChatGPT. Tato schopnost je zaměřena na relativně malé přizpůsobení, umožňující konfigurovat vlastní GPT s určitým tónem hlasu, hledáním na webu a až 20 PDF dokumenty.

GPT jsou nejlepší pro malá přizpůsobení GPT a nejsou ideálním řešením pro enterprise případy s tisíci nebo miliony dokumentů, kde škálovatelná RAG řešení zůstávají doporučeným přístupem.

LLM Hallucinations (Halucinace LLM)

Když LLM generuje text, který je nesmyslný nebo nevěrný poskytnutému zdrojovému obsahu, často říkáme, že tento obsah je halucinace LLM (také nazývaná fabrication).

Halucinace LLM nastávají ze dvou hlavních důvodů:

1. Ptáte se na otázku, na kterou odpověď není LLM "známa" (tj. není dostupná v jeho trénovacích datech). V tomto případě LLM může odpovědět špatnou odpovědí.

2. Odpověď na vaši otázku je LLM "známa", ale obsahuje fiktivní obsah nebo obsah, který je subjektivní jako názory a přesvědčení.

HHEM

HHEM (Hughes Hallucination Evaluation Model) je open source klasifikační model dostupný na HuggingFace, který lze použít k detekci halucinací.

Je zvláště užitečný v kontextu budování RAG aplikací, kde je sada faktů sumarizována LLM, ale model lze použít i v jiných kontextech.

HHEM se také používá k hodnocení LLM podle jejich celkové pravděpodobnosti halucinovat tímto způsobem.

Hybrid Search (Hybridní vyhledávání)

Sémantické vyhledávání poskytuje fantastický přístup k získávání relevantních výsledků, ale není dokonalé. Existují případy, zejména u jednoslovných dotazů hledajících informace o konkrétním produktu, kde tradiční vyhledávání na základě klíčových slov funguje lépe.

Hybridní vyhledávání se pokouší kombinovat sémantické vyhledávání s tradičním vyhledáváním na základě klíčových slov, využívající přesnost keyword vyhledávání s kontextovým porozuměním sémantického vyhledávání.

Kombinací obou metod nabízí hybridní vyhledávání nuancovanější a efektivnější přístup k vyhledávání informací.

LLM Inference (Inference LLM)

Inference je operace, při které generujete text s generativním LLM. Vstupem je sekvence tokenů a výstupem je další předpovězený token. Pokud chcete generovat celou sekvenci, generujete jeden token po druhém.

Inference s LLM je stochastická operace a nemusí pokaždé generovat stejný výsledek.

Parametry ovládající inferenci:

• Temperature: Ovládá, jak randomizovaná je odpověď. Při temp=0 je odpověď deterministická (LLM vždy volí token s nejvyšší pravděpodobností), zatímco vyšší hodnoty vedou k více randomizovaným výsledkům.

• Top_p a top_k: Dva mechanismy pro výběr dalšího tokenu.

  • Top_k je celočíselná hodnota určující délku top tokenů k zvážení
  • Top_p pracuje podobně, ale vybírá top N tokenů tak, aby jejich kumulativní pravděpodobnost byla rovna nebo vyšší než hodnota top_p (0…1)

Large Language Model (LLM) - Velký jazykový model

Velký jazykový model (LLM) je neuronová síť trénovaná k porozumění jazyku a může být použita pro různé úkoly jako sumarizace, překlad, predikce a generování textu. LLM je trénován na masivních textových datasetech jako Common Crawl, WebText2, Books1, Books2 a Wikipedia.

Běžný typ LLM, nazývaný také auto-regresivní (AR) LLM, je ten, kde je model trénován k předpovídání dalšího tokenu podmíněného všemi předchozími tokeny. GPT-3 a GPT-4 patří do této kategorie.

Tyto modely se také nazývají generativní LLM.

MAMBA

Mamba je nová architektura pro modelování sekvencí, která nabízí slibnou alternativu k modelům Transformer. Využívá selektivní stavové prostory k dosažení modelování sekvencí v lineárním čase, což poskytuje významné zlepšení efektivity a škálovatelnosti ve srovnání s kvadratickou složitostí Transformerů.

Klíčová inovace Mamby spočívá v její schopnosti selektivně uchovávat nebo zapomínat informace prostřednictvím selekčního mechanismu, což jí umožňuje efektivně zpracovávat dlouhodobé závislosti.

Architektura Mamba demonstruje působivý výkon napříč různými úkoly včetně jazykového modelování, analýzy sekvencí DNA a generování audia. Nabízí 5x vyšší propustnost generování ve srovnání s Transformery podobné velikosti.

Max Marginal Relevance Ranking (MMR)

V kontextu RAG se MMR vztahuje na techniku, při které jsou relevantní fakta poskytnutá krokem vyhledávání přeuspořádána tak, aby vytvořila rozmanitější sadu faktů. Původně navržená v roce 1998, je tato technika kritická například tam, kde je mnoho odpovídajících textových chunků z více dokumentů ve skutečnosti velmi podobných nebo dokonce identických.

MMR je často implementován jako krok přeuspořádání po vyhledávání. Algoritmus má složitost O(N²), ale může být implementován efektivně pro nízkou latenci.

Open Source LLM

Termín "open source", často používaný pro zdrojový kód veřejně dostupný pod různými licencemi jako Apache 2.0 nebo MIT, byl nedávno použit v kontextu LLM pro označení modelů, jejichž váhy jsou veřejně dostupné.

Nejpozoruhodnější open source modely:

• LLAMA3 od Meta (verze 8B a 70B)
• Mistral
• Google Gemma
• Microsoft Phi4

Většina open source LLM je vydána za podmínek umožňujících komerční použití, ale některé mají dodatečná omezení.

Prompt Engineering

Proces vytváření, zdokonalování a optimalizace vstupních promptů zadávaných LLM za účelem dosažení požadovaných výstupů. Prompt engineering hraje klíčovou roli při určování výkonu a chování modelů jako GPT.

Specifické techniky prompt engineeringu:

• Přeformulování: Někdy může přeformulování promptu vést k lepším výsledkům.
• Specifikace formátu: Pro úkoly, kde záleží na formátu odpovědi, můžete jej specifikovat v promptu (např. "Poskytněte odpověď v odrážkách").
• Úvodní informace: Zahrnutí dodatečného kontextu může pomoci zúžit požadovanou odpověď.

Prompt engineering je důležitý i v kontextu RAG pro získání nejlepších výsledků.

RAG Evaluation (Evaluace RAG)

Při implementaci RAG ve vaší organizaci je důležité nasadit robustní rámec pro evaluaci RAG. To vám umožní měřit kvalitu odpovědí a určit "jak přesná a užitečná je odpověď na jakoukoli uživatelskou otázku".

Dva hlavní typy metrik:

1. Metriky vyhledávání (Retrieval metrics): Tyto metriky říkají, zda jsou fakta získaná ze zdrojových dat relevantní k otázce a mohou být úspěšně použita jako podkladová data pro odpověď.

2. Metriky generování (Generation metrics): Tyto metriky hodnotí samotnou odpověď podmíněnou fakty – je odpověď správně ukotvena ve faktech?

RAG evaluace může být velmi akční a pomoci vám nejen vidět problémy, ale také je opravit.

RAG Sprawl

RAG Sprawl označuje nekontrolované šíření implementací Retrieval-Augmented Generation (RAG) napříč vaší organizací – rostoucí problém způsobující bolesti hlavy CIO a IT oddělením při vyčerpávání zdrojů, ohrožování bezpečnosti a vytváření nekonzistentních uživatelských zkušeností.

S RAG Sprawl se organizace rychle ocitne ve správě více redundantních systémů, které v podstatě vykonávají stejnou základní funkci: vyhledávání relevantních informací a jejich použití k ukotvení odpovědí LLM.

Reranking (Přeuspořádání)

V RAG hraje reranker klíčovou roli při zvyšování relevance získaných dokumentů ve dvoustupňovém modelu vyhledávání.

Zpočátku zahrnuje proces vyhledávání široké hledání pro shromáždění velké sady potenciálně relevantních dokumentových chunků pomocí rychlé a efektivní metody jako vektorové embeddingy nebo hybridní vyhledávání. Počáteční sada dokumentů však může obsahovat mnoho irelevantních nebo okrajově relevantních položek.

Zde přichází reranker jako druhý stupeň procesu vyhledávání. Aplikuje sofistikovanější algoritmus pro přehodnocení a přeuspořádání původně získaných dokumentů.

Kategorie rerankerů:

• Relevance reranker
• MMR reranker
• UDF reranker

Retrieval Augmented Generation (RAG)

Retrieval Augmented Generation (RAG) je přístup, který poskytuje LLM dodatečné, kontextové informace k ukotvení jeho odpovědí a zamezení halucinacím.

Ingest flow (tok příjmu dat):
Data jsou rozdělena na věty nebo jiné chunky. Každý chunk je poté zakódován do vektorového embeddingu (pomocí Embeddings modelu) a uložen ve vektorovém úložišti.

Query flow (tok dotazu):
Když je vydán dotaz, je nejprve zakódován do vlastního vektorového embeddingu a ty jsou porovnány s daty ve vektorovém úložišti. Nejrelevantnější věty nebo fakta jsou získány. Tato fakta jsou poté poskytnuta sumarizačnímu LLM, aby mohl odpovědět na dotaz s tímto kontextem na mysli a poskytnout přesnou odpověď založenou na datech.

Semantic Search a Neural Search (Sémantické a neurální vyhledávání)

Sémantické vyhledávání je metoda používaná ve vyhledávacích algoritmech, která bere v úvahu záměr hledajícího a kontextový význam termínů v dokumentech. Namísto pouhého hledání klíčových slov se sémantický vyhledávač snaží porozumět základním konceptům, kontextu a významu pro přesnější výsledky.

Například při hledání "apple" by tradiční vyhledávání na základě klíčových slov jednoduše vrátilo výsledky obsahující slovo "apple" bez kontextu rozlišujícího mezi Apple Inc. a jablkem jako ovocem.

Sémantické vyhledávání je často založeno na modelu hlubokého učení a nazývá se "neurální vyhledávání". Při neurálním vyhledávání je text převeden na formu nazývanou "vektorové embeddingy" reprezentující jeho sémantický význam.

Tokenization (Tokenizace)

V kontextu LLM je tokenizace proces, při kterém je textový řetězec rozdělen na menší jednotky nazývané tokeny. Tokeny mohou být jednotlivé znaky, jednotlivá slova nebo dokonce subslova, a výběr strategie tokenizace závisí na případu použití.

U tradičního NLP byla tokenizace na úrovni slov. Například věta "How am I doing today?" by byla přeložena do 5 slov: ["how", "am", "I", "doing", "today?"]

Nejběžnější strategie tokenizace pro LLM:

• BPE (Byte Pair Encoding): Tato metoda tokenizace rozděluje text na subslova. Velmi běžně používaná v rodině modelů GPT.
• Wordpiece: Vyvinutý společností Google a používaný v původní implementaci BERT.
• Unigram: Používaný v algoritmu SentencePiece od Google.

Transformers

Transformery jsou typ architektury neuronové sítě široce používané v zpracování přirozeného jazyka a jazykovém modelování. Transformery aplikují mechanismus pozornosti (attention), který umožňuje modelu současně zvažovat důležitost všech slov ve větě. To vede k modelům, které lépe zachycují kontext a dlouhodobé závislosti v jazyce.

Architektura transformeru se skládá z enkodéru a dekodéru. Enkodér čte vstupní sekvenci a vytváří její reprezentaci. Dekodér pak používá tuto reprezentaci ke generování výstupní sekvence.

Typy implementací:

• Pouze enkodér (např. BERT)
• Pouze dekodér (např. GPT-3, Anthropic)
• Enkodér i dekodér (např. T5)

Modely jako BERT, GPT-3 a T5 jsou všechny založeny na architektuře transformer.

Transfer Learning (Přenosové učení)

V tradičním strojovém učení je cílem natrénovat model k provedení určitého úkolu jako klasifikace nebo regrese.

S transfer learningem vezmete předtrénovaný model a použijete ho (adaptujete) na nový úkol. Protože předtrénování modelu je poměrně nákladné, myšlenka transfer learningu je následující: můžeme znovu použít část znalostí naučených během procesu předtrénování a aplikovat ji na nový úkol, který z těchto znalostí těží?

Transfer learning není nová myšlenka, jen se stal běžnějším s moderními neuronovými sítěmi, které jsou velké a nákladné na předtrénování.

Vector Store / Vector Database (Vektorové úložiště / databáze)

Vektorové úložiště je typ databáze, která ukládá vysokodimenzionální vektorová data a poskytuje dotazovací schopnosti na těchto vektorech jako similarity search, kde cílem je najít nejpodobnější dokumenty nebo položky k danému dotazu.

Nejběžnější typy vektorových úložišť: FAISS, Annoy, NMSLib

Vektorová databáze je specializovanější typ vektorového úložiště optimalizovaný pro efektivní správu velkých datasetů vektorů. Vektorové databáze typicky nabízejí pokročilé funkce jako podpora více typů vektorů, efektivní indexování a vysoká škálovatelnost.

Dostupné vektorové databáze: Qdrant, Weaviate, Pinecone, Milvus, Chroma

Při budování GenAI aplikací od nuly vývojáři často kombinují různé komponenty jako LangChain nebo LlamaIndex, poskytovatele embeddingů jako OpenAI nebo Cohere, sumarizační nebo Chat LLM jako OpenAI, a vektorovou databázi.

The post Glosář AI a LLM termínů first appeared on Hard Wired.

Context Engineering: Nová disciplína, která mění pravidla AI

Jak jsem se naučil, že úspěch AI aplikací nezávisí na dokonalém promptu, ale na tom, co model "vidí" kolem něj

Před třemi lety jsem trávil hodiny ladění promptů. Psal jsem stránkové instrukce, experimentoval s různými formulacemi, testoval desítky variant. A přesto můj AI asistent zapomínal klíčové informace z předchozích konverzací, můj kódovací pomocník ztrácel přehled o architektuře projektu a RAG systém nedokázal propojit souvislosti napříč dokumenty.

Pak jsem pochopil zásadní věc: problém nebyl v tom, jak jsem se modelu ptal, ale v tom, co všechno model věděl v okamžiku, kdy odpovídal. Objevil jsem context engineering – disciplínu, která překračuje hranice prompt engineeringu a mění celou hru.

Proč prompt engineering přestal stačit

Když poprvé otevřete ChatGPT, připadá vám to jednoduché: napíšete otázku, dostanete odpověď. Jenže reality produkčních AI aplikací je jiná. Představte si, že stavíte AI asistenta pro zákaznický servis. Potřebuje:

• Znát historii všech předchozích interakcí s klientem
• Mít přístup k aktuálním informacím o produktech
• Rozumět firemním procesům a pravidlům
• Pamatovat si kontext celé konverzace
• Umět zavolat externí API pro ověření dat

Žádný prompt, ať je sebevíc dokonalý, to sám nezvládne. Potřebujete systém, který modelu poskytne správný kontext ve správný čas. To je podstata context engineeringu.

Co je context engineering v praxi

Context engineering je disciplína navrhování a budování systémů, které orchestrují všechny informace, nástroje a paměť potřebné k tomu, aby AI dokázala řešit složité, real-world úkoly.

Nejde jen o prompt. Jde o celý informační ekosystém kolem modelu.

Reálný příklad z mé praxe

Nedávno jsem stavěl AI asistenta pro právní kancelář. Klasický přístup by byl:

Jsi právní expert. Odpovídej na otázky klientů o smluvním právu.

Context engineering přístup vypadal takto:

1. Systémový kontext:

Role: Senior právní poradce specializující se na obchodní právo
Firma: [název], 15 let praxe, focus na SaaS a tech startupy  
Regulatory environment: České právo, EU regulace

2. Dynamický retrieval:

# Při každé otázce systém:
query = user_question
relevant_cases = vector_search(query, case_database)
current_legislation = api_call("legal_updates", query)
client_history = get_client_context(client_id)
firm_templates = search_templates(query)

3. Paměťový systém:

# Kontext se skládal z:
- Dlouhodobé paměti klienta (preference, předchozí případy)
- Krátkodobé paměti konverzace (co už probrali dnes)
- Faktual knowledge base (zákony, judikáty)
- Tool access (kalkulačky poplatků, termíny soudů)
- Meta-context (urgence, složitost případu)

Výsledek? Místo obecných právních rad model poskytoval konkrétní doporučení založená na historii klienta, aktuální legislativě a firemních postupech.

Anatomie profesionálního context systému

1. Multi-layer memory architecture

Immediate context - co model "vidí" právě teď:

• Aktuální prompt a konverzace
• Výsledky z právě provedených nástrojů
• Dočasný stav úkolu

Session memory - co si pamatuje během práce:

• Historie kroků a rozhodnutí
• Předchozí výsledky a chyby
• Evoluce strategie řešení

Long-term memory - trvalé znalosti:

• User profily a preference
• Learnt patterns a insights
• Firemní knowledge base

2. Intelligent retrieval orchestration

Nejsložitější část. Systém musí v real-time rozhodnout:

• Které dokumenty jsou relevantní
• Jaké externí API zavolat
• Kolik kontextu použít (token limits)
• V jakém pořadí informace poskytovat

Můj workflow:

def build_context(user_query, session_state):
    # 1. Analýza query
    intent = classify_intent(user_query)
    entities = extract_entities(user_query)

    # 2. Multi-source retrieval
    docs = semantic_search(user_query, weight=0.4)
    tools = suggest_tools(intent, weight=0.3) 
    memory = get_relevant_memory(session_state, weight=0.3)

    # 3. Context assembly
    context = assemble_context(
        system_prompt=get_system_prompt(intent),
        retrieved_docs=docs[:5],  # Top 5 to stay within limits
        available_tools=tools,
        conversation_memory=memory,
        user_profile=get_user_context()
    )

    return context

3. Dynamic context optimization

Context není statický. Mění se podle:

Task complexity - složité úkoly potřebují víc kontextu
User expertise - expert vs. beginner potřebuje jiné informace
Performance feedback - učení se z úspěchů a chyb
Resource constraints - tokens, latency, costs

Praktické techniky z praxe

Context Layering

Místo jednoho obřího promptu stavím kontext po vrstvách:

# Layer 1: Core identity
system_role = """
Senior business analyst s 10+ lety zkušeností
Specializace: SaaS metriky, customer analytics
Styl: Data-driven, konkrétní doporučení
"""

# Layer 2: Current task context  
task_context = f"""
Aktuální projekt: {project_name}
Deadline: {deadline}
Stakeholders: {stakeholder_list}
Previous insights: {session_memory}
"""

# Layer 3: Dynamic information
dynamic_context = f"""
Relevantní data: {retrieved_data}
Dostupné nástroje: {available_tools}
Aktuální metrics: {live_metrics}
"""

Context Chaining

Pro komplexní úkoly rozdělím práci do kroků, kde výstup jednoho kroku se stává kontextem pro další:

# Krok 1: Analýza problému
problem_analysis = llm_call(
    context=base_context + user_problem,
    task="Analyzuj problém a identifikuj klíčové otázky"
)

# Krok 2: Sběr dat s kontextem z kroku 1
data_context = base_context + problem_analysis
retrieved_data = gather_data(problem_analysis.key_questions)

# Krok 3: Řešení s full kontextem
solution = llm_call(
    context=data_context + retrieved_data,
    task="Navrhni řešení založené na analýze a datech"
)

Adaptive Context Compression

Když se blížím k token limitu, používám kompresní strategie:

def compress_context(context_items, max_tokens):
    if calculate_tokens(context_items) <= max_tokens:
        return context_items

    # Prioritizace podle důležitosti
    prioritized = rank_by_relevance(context_items)

    # Postupná komprese
    compressed = []
    token_budget = max_tokens

    for item in prioritized:
        if item.type == "critical":
            compressed.append(item)  # Vždy zahrnout
        elif item.type == "supporting":
            if token_budget > estimate_tokens(item):
                compressed.append(summarize(item))  # Komprese

    return compressed

Časté problémy a jejich řešení

Context Poisoning

Problém: Chyba se dostane do kontextu a pak se propaguje dál.

Řešení z praxe:

def validate_context(context_item):
    # Fact-checking pro kritické informace
    if context_item.type == "factual":
        confidence = fact_check(context_item.content)
        if confidence < 0.8:
            context_item.add_disclaimer("Unverified information")

    # Timestamp check pro časově citlivé info
    if context_item.age > MAX_STALENESS:
        refresh_data(context_item)

    return context_item

Context Overload

Problém: Příliš mnoho informací rozptyluje model.

Mé řešení:

• Používám "attention hints" - explicitně říkám, na co se zaměřit
• Strukturuji kontext hierarchicky (nejdůležitější nahoře)
• Implementuji "context budgeting" - každý typ info má limit

context_budget = {
    "system_instructions": 500,   # tokens
    "user_input": 1000,
    "retrieved_docs": 2000,
    "tool_outputs": 1500,
    "memory": 1000
}

Tool Confusion

Problém: Model si vybírá špatné nástroje.

Moje strategie:

def smart_tool_selection(user_intent, available_tools):
    # Jen relevantní nástroje pro daný typ úkolu
    if user_intent == "data_analysis":
        return [tools.python_executor, tools.data_visualizer]
    elif user_intent == "web_research":
        return [tools.web_search, tools.summarizer]

    # Nikdy nedávat všechny nástroje najednou
    return filter_tools_by_relevance(available_tools, max_count=5)

Frameworky a nástroje

LangChain/LangGraph

Skvělé pro orchestraci workflows, ale pozor na over-engineering:

from langgraph import StateGraph

# Definuji workflow s explicitním context flow
workflow = StateGraph()
workflow.add_node("analyze", analyze_with_context)
workflow.add_node("retrieve", smart_retrieval) 
workflow.add_node("synthesize", synthesize_response)

# Context se propaguje mezi kroky
workflow.add_edge("analyze", "retrieve")
workflow.add_edge("retrieve", "synthesize")

LlamaIndex

Exceluje v knowledge management:

from llama_index import VectorStoreIndex, ContextBuilder

# Automatické budování kontextu
context_builder = ContextBuilder()
context_builder.add_memory_layer(user_profile)
context_builder.add_retrieval_layer(document_index)
context_builder.add_tool_layer(available_functions)

Anthropic MCP

Nejnovější standard pro propojení AI s externí systémy:

# MCP server pro firemní data
mcp_server = MCPServer()
mcp_server.register_resource("customer_db", CustomerDatabase())
mcp_server.register_tool("send_email", EmailTool())

# AI má strukturovaný přístup k firemním systémům

Budoucnost context engineeringu

Vidím tři hlavní trendy:

1. Automated Context Assembly
AI začíná samo rozpoznávat, jaký kontext potřebuje. Experiments s "self-reflective agents" ukazují zajímavé výsledky.

2. Multi-Modal Context Integration
Kombinace textu, obrázků, audio, video do jednotného kontextu. Pracuji na projektu, kde AI analyzuje video cally a extrahuje kontext pro další rozhodnutí.

3. Collaborative Context Networks
Více AI agentů sdílí kontext a buduje kolektivní "paměť" týmu.

Co si odnést domů

Context engineering není jen technická disciplína – je to nový způsob myšlení o AI aplikacích. Moje klíčová doporučení:

1. Začněte s auditem kontextu
Podívejte se na vaše současné AI aplikace. Co všechno model "nevidí", ale měl by?

2. Investujte do memory systémů
Dlouhodobá paměť je game-changer. AI, které si pamatuje vaše preference a zkušenosti, je kvalitativně jiné.

3. Experimentujte s context compression
Naučte se čistit a komprimovat kontext. Méně může být více.

4. Měřte context effectiveness
Trackujte, které části kontextu model skutečně používá. Optimalizujte na základě dat.

5. Myslĕte systémově
Context engineering je systémová disciplína. Nejde o izolované prompty, ale o architekturu informačních toků.

A především: context engineering je budoucnost AI aplikací. Kdo ho zvládne dřív, získá obrovskou výhodu.

Po několika letech experimentování s LLM si myslím, že context engineering je nejdůležitější skill pro AI builders. Není to jen o tom dát modelu správné informace – je to o pochopení toho, jak AI "myslí" a jak navrhnout systémy, které s tímto myšlením spolupracují. Je to fascinující kombinace software architecture, cognitive science a trochy magie.

The post Context Engineering: Nová disciplína, která mění pravidla AI first appeared on Hard Wired.