_CORE
<200ms
P95 latence RAG odpovědi
94.2%
Faithfulness score (RAGAS)
<15min
Model rollback čas
99.7%
Uptime inference služby
Náš stack

Vrstvy AI/ML stacku

Každá vrstva má jasnou odpovědnost, kontrakt a monitoring. Od foundation modelů po produkční inference — nic není black box.

Foundation modely

Azure OpenAI (GPT-4o, GPT-4.1), Anthropic Claude, open-weights modely (Llama 3.3, Mistral Large, Qwen 2.5). Výběr podle latence, ceny a compliance požadavků klienta.

GPT-4o Claude 3.5 Llama 3.3 Mistral Large

Orchestrace & Frameworky

LangChain a LangGraph pro multi-step agenty, Semantic Kernel pro .NET ekosystém, LlamaIndex pro knowledge retrieval. Volba závisí na stack klienta a typu úlohy.

LangChain LangGraph Semantic Kernel LlamaIndex

Vector Store & Embeddings

pgvector pro menší objemy (skvělá integrace s existujícím PostgreSQL), Qdrant nebo Weaviate pro scale. Embedding modely: text-embedding-3-large, Nomic Embed, BGE-M3.

pgvector Qdrant Weaviate text-embedding-3

Guardrails & Safety

NVIDIA NeMo Guardrails, custom validátory, content filtering, PII detection. Každý LLM call prochází input/output validací — žádný prompt injection, žádný data leak.

NeMo Guardrails PII Detection Content Filter

Evaluace & Testing

RAGAS framework pro RAG metriky (faithfulness, answer relevancy, context precision). Custom eval sady per doména. Automatizované regression testy na každém modelu a promptu.

RAGAS DeepEval Custom Eval Sets

Observability & LLMOps

MLflow 3 pro experiment tracking a model registry. LangSmith pro tracing LLM callů. Prometheus + Grafana pro runtime metriky. Každý call logován s cost, latency, token count.

MLflow 3 LangSmith Prometheus Grafana
Architektura

RAG Pipeline

Retrieval-Augmented Generation není jen „vector search + LLM". Je to end-to-end systém s vlastním životním cyklem, evaluací a rollback strategií.

Dokumenty PDF, Confluence, SQL
Chunking Semantic splitter
Embedding text-embedding-3
Vector Store pgvector / Qdrant
Retrieval Hybrid search
Reranking Cross-encoder
LLM GPT-4o / Claude
Guardrails Validace output

Ingestion pipeline

Ingestion je nejčastěji podceněná část RAG systému. V praxi tvoří 60–70 % celkového úsilí. Naše pipeline zpracovává dokumenty z heterogenních zdrojů — interní Confluence wiki, PDF manuály, SQL databáze, SharePoint — a transformuje je do indexovatelných chunků.

Semantic chunking vs. fixed-size

Fixed-size chunking (např. 512 tokenů s 50-token overlap) je jednoduchý, ale ztrácí kontext na hranicích. Používáme semantic chunking — algoritmus detekuje přirozené hranice v textu na základě embedding similarity sousedních vět. Výsledek: chunky, které odpovídají logickým celkům, ne arbitrárním řezům.

Pro strukturované dokumenty (tabulky, formuláře, technické specifikace) kombinujeme layout-aware parsing přes unstructured.io s custom post-processorem, který zachovává hierarchii nadpisů jako metadata.

Lessons learned: Metadata enrichment je kritický. Každý chunk nese: zdrojový dokument, stránku, sekci, datum poslední aktualizace a access level. Bez toho nelze implementovat row-level security v RAG.

Hybrid retrieval

Čistě vektorové hledání má problém s exaktními termíny — čísla smluv, kódy produktů, regulatorní references. Proto standardně nasazujeme hybrid search: kombinace dense vector similarity (cosine) a sparse keyword search (BM25).

Váhy mezi vektorovým a keyword score ladíme per doména. Pro právní dokumenty typicky 40:60 (BM25 dominant), pro knowledge base 70:30 (vector dominant). Reciprocal rank fusion (RRF) kombinuje rankingy obou metod.

Reranking pipeline

Po initial retrieval (top-k = 20–50) aplikujeme cross-encoder reranker (Cohere Rerank nebo open-source bge-reranker-v2-m3) pro přesnější řazení. Cross-encoder vidí query i dokument současně — dramatically lepší relevance než bi-encoder, ale příliš pomalý pro initial search.

  • Bez rerankeru: Context precision typicky 0.72–0.78
  • S rerankerem: Context precision 0.88–0.93 (+15–20 % improvement)
  • Trade-off: +30–50 ms latence per request (přijatelné pro většinu use cases)

Generativní vrstva

LLM dostává kontext a query. Ale prompt engineering v produkci je jiná disciplína než playground experimenty. Naše prompty mají:

  • System prompt s domain constraints — jasné instrukce co model smí a nesmí, v jakém formátu odpovídat
  • Few-shot examples — per-tenant příklady očekávaných odpovědí, uložené v konfiguraci, ne v kódu
  • Citation enforcement — model musí citovat zdroje (chunk ID), jinak odpověď failuje validaci
  • Structured output — JSON mode nebo function calling pro parsovatelné odpovědi

Anti-pattern: „Nalejeme všechny chunky do kontextu a doufáme." Lost-in-the-middle problém je reálný — modely mají tendenci ignorovat kontext uprostřed dlouhého promptu. Řešení: reranking + max 5–8 chunků, seřazených od nejrelevantnějšího.

Evaluace: měříme kvalitu, ne jen vibes

„Vypadá to dobře" není metrika. Používáme RAGAS framework s automatizovanými eval sady per deployment:

  • Faithfulness — odpovídá LLM na základě retrievnutého kontextu, nebo halucinuje? Cíl: > 0.90
  • Answer Relevancy — je odpověď relevantní k otázce? Cíl: > 0.85
  • Context Precision — jsou retrievnuté dokumenty relevantní? Cíl: > 0.85
  • Context Recall — pokrývá retrieval všechny potřebné informace? Cíl: > 0.80

Evaluační dataset budujeme iterativně: product owner dodá 50–100 otázek s gold-standard odpověďmi. Automatizovaný eval běží v CI/CD — každý merge request na prompt nebo retrieval konfiguraci musí projít regression testy.

Specializace modelů

Fine-tuning workflow

Fine-tuning je odpověď na otázku: „RAG nestačí, potřebujeme model, který rozumí naší doméně." Ale fine-tuning v produkci není trainer.train() na notebooku. Je to řízený proces s jasným decision framework.

Kdy fine-tunovat (a kdy ne)

  • Fine-tune ANO: Domain-specific jazyk (právní terminologie, interní žargon), konzistentní formátování výstupů, latence je kritická (menší fine-tuned model > větší general-purpose model)
  • Fine-tune NE: Knowledge injection (na to je RAG), když nemáte dostatek kvalitních trénovacích dat (< 500 příkladů), když se znalosti rychle mění

Náš workflow: od dat k produkci

Používáme PyTorch jako foundation s Hugging Face Transformers a PEFT (Parameter-Efficient Fine-Tuning). Pro většinu produkčních use cases: QLoRA — fine-tuning s 4-bit quantization, který snižuje VRAM requirements o 70 % bez signifikantního quality dropu.

  • 1. Data curation — Sběr, deduplikace, quality filtering. Minimum 500 příkladů, ideálně 2000+. Formát: instruction-response páry validované domain experty.
  • 2. Baseline evaluation — Eval na test setu s base modelem. Toto je váš benchmark — pokud fine-tuned model není lepší, nepublikujete ho.
  • 3. Training — QLoRA fine-tuning, typicky 2–5 epoch. Hyperparameter search přes Optuna. Tracking v MLflow.
  • 4. Evaluation — Automatizované metriky (BLEU, ROUGE, domain-specific eval), human evaluation na 100 vzorcích.
  • 5. Merge & Quantize — LoRA adaptor merge do base modelu, GGUF/AWQ quantization pro deployment.
  • 6. Canary deploy — 5 % traffic na nový model, monitoring latence, error rate, user feedback. Gradual rollout 5 → 25 → 50 → 100 %.

Reálná čísla: Fine-tuned Llama 3.1 8B na bankovní doménu dosahuje 89 % accuracy na domain-specific eval setu vs. 67 % pro base model. Latence: 45 ms P95 na A100 (vs. 180 ms pro GPT-4o přes API). Cost per 1M tokenů: $0.12 vs. $2.50.

Provoz AI v produkci

MLOps & LLMOps

Model v produkci je jako dítě v autě — nemůžete ho tam nechat a odejít. MLOps je disciplína, ne nástroj.

Experiment Tracking

MLflow 3 s GenAI rozšířeními (od června 2025). Každý experiment: parametry, metriky, artefakty, prompt verze. Porovnání modelů na dashboardu, ne v hlavě.

  • Prompt versioning s diff view
  • Automatic cost tracking per experiment
  • Dataset versioning (DVC)

Model Registry

Centrální registr modelů s verzováním, staging/production stages, lineage a approval workflow. Žádný model se nedostane do produkce bez review.

  • Model card pro každou verzi (metrics, data, limitations)
  • Automated regression test gate
  • Approval workflow (ML engineer → product owner)

A/B Testing & Canary

Traffic splitting na úrovni inference gateway. A/B testy s automatickým vyhodnocením po statisticky signifikantním vzorku. Canary deploy s automatic rollback.

  • Bayesian significance testing
  • Automatic rollback při error rate > 2×baseline
  • User feedback integration (thumbs up/down)

Runtime Monitoring

Každý LLM call je traced: input tokens, output tokens, latence, cost, model verze, guardrail hits. Data drift detection na embedding distribucích.

  • Real-time cost dashboards per tenant
  • Hallucination rate tracking
  • Embedding drift alerts (Jensen-Shannon divergence)
Foundation

PyTorch & Transformers v praxi

PyTorch 2.x s torch.compile() je náš default pro custom model development. Proč ne TensorFlow? Ekosystém — Hugging Face, většina výzkumných paperů, rychlost iterace. V produkci ale záleží na inference runtime:

Inference stack

  • vLLM — pro LLM serving. PagedAttention, continuous batching. Throughput 2–4× vyšší než naivní HuggingFace inference. Náš default pro self-hosted LLM.
  • NVIDIA TensorRT-LLM — když potřebujeme maximální výkon na NVIDIA GPU. Kernel fusion, INT8/FP8 quantization. Pro high-throughput produkci.
  • ONNX Runtime — pro menší modely (klasifikátory, NER, embedding modely). Cross-platform, optimalizace per hardware.
  • Triton Inference Server — model serving s batching, model ensemble, A/B testing. Kubernetes-native s auto-scaling na GPU metrikách.

Custom modely, které stavíme

Ne vše řeší LLM. Pro specifické úlohy trénujeme custom modely:

  • Document classification — BERT-based klasifikátory pro routing dokumentů (pojistné události, reklamace, faktury). Latence < 10 ms, accuracy > 96 %.
  • Named Entity Recognition — Custom NER modely pro extrakci entit z českých a slovenských textů. SpaCy + fine-tuned transformer backbone.
  • Anomaly detection — Autoencoder sítě pro detekci anomálií v transakčních datech. Real-time inference na streaming datech přes Kafka.
  • Computer Vision — YOLO v8/v11 pro inspection úlohy, OCR pipeline (PaddleOCR + custom post-processing) pro extrakci dat z dokumentů.

Hardware: Pro training využíváme Azure NC-series (A100 80GB). Pro inference: A10G pro LLM, T4 pro menší modely. Auto-scaling na basis GPU utilization — idle nodes se vypínají po 15 minutách.

Další deep dive

Prozkoumat další stacky

Další krok

Stavíte AI systém?

Pojďme si promluvit o vašem use case. Pomůžeme vám vybrat správný stack, navrhnout architekturu a dotáhnout to do produkce.

Kontaktujte nás