Stavba AI search tech stacku od nuly – jaké komponenty skutečně potřebujete?

Tento stack jsem stavěla několikrát. Tady je rámec, který používám:

Základní architektura (RAG vzor):

Dotaz uživatele
    ↓
Embedding dotazu (embedding model)
    ↓
Vektorové vyhledávání (vektorová DB)
    ↓
Návrh kandidátů
    ↓
Přerovnání (cross-encoder)
    ↓
Sestavení kontextu
    ↓
Generace LLM
    ↓
Odpověď

Doporučení komponent pro vaše měřítko (500K dokumentů):

Kontrola reality rozpočtu:

Při 500K dokumentech počítejte s:

• Vektorová DB: 100–500 $/měsíc managed
• Náklady na embeddingy: jednorázově ~50–100 $ na embedding korpusu
• Náklady na LLM: dle používání, plánujte 500–2000 $/měsíc

Pro 2 inženýry se managed služby 100% vyplatí.

AI vyhledávání provozujeme v produkci už 18 měsíců. Co bych udělal jinak:

Chyby, které jsme udělali:

1. Začali jsme s vlastně hostovanou vektorovou DB – Tři měsíce ztraceny na infrastruktuře. Měli jsme jít do managed hned od začátku.

2. Levný embedding model – Ušetřili jsme 20 $/měsíc, ale výrazně ztratili na kvalitě vyhledávání. Kvalitní embeddingy za to stojí.

3. Zpočátku žádný hybridní search – Čistě vektorové hledání minulo přesné dotazy. Hybrid (vektor + BM25) to vyřešil.

4. Podcenili jsme monitoring – Těžko se ladí, když nevidíte metriky kvality vyhledávání.

Co provozujeme teď:

• Pinecone (vektor) + Elasticsearch (BM25) hybrid
• OpenAI embeddingy (ada-002, přechod na 3)
• Cohere přerovnávač
• Claude pro generování
• Vlastní dashboard monitorující retrieval metriky

Rozklad latence:

• Embedding: 30 ms
• Hybridní search: 40 ms
• Přerovnání: 60 ms
• LLM: 800 ms (streamování zlepšuje UX)

Celková vnímaná latence je v pořádku, protože LLM výstup streamujeme.

Přidávám pohled na datový pipeline, na který se často zapomíná:

Zpracování dokumentů je VELMI důležité:

Než se cokoliv dostane do vaší vektorové DB, potřebujete:

1. Strategii chunkování – Jak dělíte dokumenty?
2. Extrakci metadat – Jaké atributy ukládáte?
3. Čistící pipeline – Odstranit balast, normalizovat text
4. Update mechanismus – Jak procházejí nové/změněné dokumenty?

Rady k chunkování:

Past:

Lidé stráví týdny výběrem vektorové DB a dny chunkováním. Mělo by to být naopak. Špatné chunkování = špatné vyhledávání bez ohledu na kvalitu vektorové DB.

Porovnání vektorových databází podle vašich požadavků:

Pro 500K dokumentů + 2 inženýry + pod 200 ms:

Pinecone:

• Výhody: Plně spravovaná, skvělá dokumentace, předvídatelné ceny
• Nevýhody: Závislost na dodavateli, omezené možnosti úprav
• Hodí se: Perfektní pro vaše omezení

Qdrant:

• Výhody: Výborný výkon, dobrá podpora hybridu, cloud i vlastní hosting
• Nevýhody: Novější managed nabídka
• Hodí se: Dobrá volba zvlášť pokud možná potřebujete hybridní hledání

Weaviate:

• Výhody: Skvělý hybrid, vestavěná vektorizace
• Nevýhody: Složitější nastavení
• Hodí se: Spíš pro větší týmy

Milvus:

• Výhody: Nejškálovatelnější, plně open source
• Nevýhody: Vyžaduje infrastrukturní znalosti
• Hodí se: Pro vaše měřítko zbytečné, přeskočte

Moje doporučení:

Začněte s Pinecone. Je nudná (v tom dobrém smyslu). Na alternativy bude čas, až poznáte své skutečné potřeby.

Nezapomeňte na MLOps a observabilitu:

Co je potřeba sledovat:

1. Retrieval metriky

   • Precision@K (jsou top K výsledků relevantní?)
   • Recall (nacházíme všechny relevantní dokumenty?)
   • Distribuce latence

2. Metriky generování

   • Relevance odpovědi (odpovídá dotazu?)
   • Ukotvenost (je odpověď podložená kontextem?)
   • Míra halucinací

3. Systémové metriky

   • Latence dotazu p50/p95/p99
   • Chybovost
   • Cena za dotaz

Nástroje:

• Weights & Biases pro sledování experimentů
• Datadog/Grafana pro monitoring systému
• LangSmith pro observabilitu LLM
• Vlastní dashboard pro byznys metriky

Co nikdo neříká:

Strávíte víc času monitoringem a laděním než samotným stavěním systému. Plánujte s tím od začátku.

Realita startupu:

Pokud to stavíte pro byznys (ne výzkum), zvažte:

Stavět nebo koupit:

• Stavba RAG od nuly: 2–3 měsíce vývoje
• Použití existující RAG platformy: Dny do produkce

Platformy, které to balíčkují:

• LlamaIndex + managed vektorová DB
• Vectara (plný RAG-as-a-service)
• Cohere RAG endpointy

Kdy stavět vlastní:

• Potřebujete extrémní přizpůsobení
• Požadavky na citlivost dat
• Ekonomika ve velkém měřítku
• Klíčová konkurenční výhoda

Kdy použít platformu:

• Rychlost uvedení na trh je klíčová
• Malý tým
• RAG není váš produkt, jen ho umožňuje

Pro většinu firem vítězí přístup platformy, dokud nenarazíte na limity škálování.

Bezpečnostní hlediska, která nikdo nezmínil:

Důležité otázky:

1. Jaká data posíláte externím embedding API?
2. Jaká data jdou k poskytovatelům LLM?
3. Kde je vaše vektorová DB hostovaná?

Možnosti pro citlivá data:

• Vlastní hosting embedding modelů (Sentence Transformers)
• Vlastní hosting vektorové DB (Qdrant, Milvus)
• On-premise LLM (Llama, Mixtral)
• Managed služby nasazené ve VPC

Compliance checklist:

• Splněné požadavky na umístění dat
• Šifrování při uložení i přenosu
• Přístupová práva a auditní logování
• Politiky uchování dat
• Postupy pro nakládání s osobními údaji (PII)

Nepředpokládejte, že managed služby splňují vaše compliance požadavky. Ověřte si to výslovně.

Tato diskuze byla neuvěřitelně přínosná. Tady je můj aktualizovaný plán:

Rozhodnutí o architektuře:

Půjdeme cestou managed služeb kvůli rychlosti a velikosti týmu:

• Pinecone pro vektorové úložiště
• OpenAI text-embedding-3 pro embeddingy
• Cohere přerovnávač
• Claude pro generování
• LangChain pro orchestraci

Klíčová zjištění:

1. Strategie chunkování je stejně důležitá jako volba vektorové DB – Investuji do toho čas
2. Přerovnání má vysoký přínos – Přidávám od začátku
3. Hybridní search pro pokrytí – Implementuji vektor + BM25
4. Monitoring od začátku – Observabilitu stavím hned, ne až dodatečně
5. Bezpečnostní kontrola včas – Compliance ověřím před produkcí

Časový harmonogram:

• Týden 1–2: Datový pipeline a chunkování
• Týden 3–4: Základní RAG implementace
• Týden 5: Monitoring a optimalizace
• Týden 6: Bezpečnostní kontrola a příprava na produkci

Díky všem za detailní postřehy. Tato komunita je zlato.