Toto je starší verze dokumentu!
Open WebUI (self-hosting UI pro LLM)
Úvodní kontext
Open WebUI používám jako self-hostované webové rozhraní pro práci s LLM, protože mi dává jednu konzistentní „chat“ vrstvu nad více poskytovateli modelů a zároveň prostor pro rozšiřování (RAG, Functions/Pipelines, filtry). Když mi v poznámkách chybí konkrétní instalační kroky, beru jako zdroj pravdy oficiální dokumentaci a tady popisuji postup jen obecně.
Co je v Open WebUI nejdůležitější
RAG (Retrieval-Augmented Generation)
RAG beru jako způsob, jak přidat k odpovědím modelu kontext z mých dat (dokumenty, poznámky, interní wiki) bez toho, abych je musel „učit“ do modelu. Prakticky to řeším jako samostatnou „feature“ v Open WebUI, která se dá nastudovat a nakonfigurovat podle oficiálního návodu:
Integrace poskytovatelů (providers)
Open WebUI mi dává smysl tehdy, když chci kombinovat více backendů/modelů (např. různé API klíče, různé cenové/performance profily, nebo specifické modality jako obrázky) pod jedním UI. Z mých poznámek tady explicitně řeším:
- Google Gemini
- Claude (Anthropic)
- OpenRouter
Pluginy vs. Functions vs. Filtry vs. Pipelines (praktické vysvětlení)
V komunitě a v projektu se často míchají pojmy. Já si je v praxi rozlišuji takto:
„Pluginy“ (komunitní rozšíření / balíčky)
Pluginem typicky myslím hotové komunitní řešení, které si vezmu a zapnu, protože řeší konkrétní potřebu bez zásahu do jádra. Příklad z mých poznámek je „zapnutí reasoning modelu skrze zaškrtávací políčko“, které je publikované jako komunitní příspěvek:
Kdy po tom sahám: když chci funkci rychle a nechci psát vlastní kód.
Functions (logika, kterou přidávám do Open WebUI)
Functions beru jako mechanismus, jak do Open WebUI doplnit vlastní logiku: předzpracování promptu, obohacení kontextu, transformace výstupu, nebo kontrolu parametrů. V poznámkách mám konkrétní ukázku v repozitáři „developer toolkit“, která je implementovaná jako filter function:
Kdy po tom sahám: když potřebuji přesně řídit chování (např. „reasoning on/off“) a hotový plugin mi nestačí.
Filtry (specializovaný typ function)
Filtry si představuji jako „hooky“ v toku dat: něco upravím před odesláním do modelu, nebo po návratu odpovědi. V praxi mi to sedí na případy typu:
- přepínání „reasoning“ parametrů podle UI přepínače
- sanitizace promptu
- doplnění/omezení systémových instrukcí
Pipelines (napojení providerů, routing, složitější tok)
Pipelines používám jako mental model pro věci, které jsou víc než jen jednoduchý filtr: typicky integrace poskytovatele, mapování parametrů, práce s více endpointy (např. text + obraz), nebo složitější routing podle modelu. V poznámkách je pipeline jasně vidět u Google Gemini, kde se řeší široké napojení API:
Kdy po tom sahám: když integruji nového providera, potřebuji víc kontrolovat parametry a datové typy (text, obrázky), nebo když chci jednotný interface nad více modely.
Reasoning: přepínání přes UI vs. vlastní filtr
Když potřebuji rychle zpřístupnit „reasoning“ jako přepínač pro uživatele, mám v poznámkách dvě cesty:
- Hotové komunitní řešení s UI přepínačem:
- Vlastní implementace jako filter function (pro jemnější kontrolu a auditovatelnost v kódu):
Praktický rozdíl pro mě: komunitní „plugin“ řeší UX rychle, vlastní filtr mi dává kontrolu nad tím, jak přesně se přepínač mapuje na parametry provideru a jaké defaulty vynucuji.
Google Gemini (včetně obrázkových modelů)
U Gemini mě zajímá, že existuje pipeline, která údajně napojuje rozsáhle Google API včetně obrázkových modelů („Nano Banana“ podle mých poznámek):
A zároveň existuje komunitní popis přímo v Open WebUI community:
Co si z toho beru prakticky:
- Pipeline si projdu jako referenci pro to, jak se mapují parametry a jak je řešené volání API.
- Komunitní příspěvek beru jako „operational“ návod (co nastavit v Open WebUI).
Konkrétní instalační/krokové instrukce v poznámkách nemám, takže postup držím obecně: otevřu oficiální dokumentaci Open WebUI k integracím a k Functions/Pipelines, zvolím přístup (hotová integrace vs. vlastní pipeline) a ověřím funkčnost na minimálním testu (jeden chat, jeden model, základní prompt).
Claude (Anthropic)
Claude řeším jako hotovou integraci pro claude.ai z komunitního příspěvku:
Poznámky neobsahují konkrétní parametry ani konkrétní kroky konfigurace. Držím se tedy principu:
- nastavit integraci podle oficiální dokumentace Open WebUI a podle uvedeného community postu
- ověřit, že se správně propisují klíče, modely a limity na úrovni backendu
OpenRouter
OpenRouter používám jako agregátor modelů, protože mi umožní přepínat modely přes jednu integraci. V poznámkách mám komunitní integraci:
A doplněk, který má „zobrazit reasoning tokeny v OpenRouteru“:
Prakticky si to vykládám tak, že:
- základní integraci řeším přes community post
- pokud chci detailní telemetrii/viditelnost nad reasoning tokeny, kouknu do uvedeného repozitáře a nasadím ho jako doplněk podle jeho README (kroky v poznámkách nemám)
Praktické příklady (co přesně si z poznámek beru)
1) RAG jako první „produkční“ feature
Když potřebuji, aby UI nebylo jen chat, začínám RAGem. Jako jediný mám v poznámkách přímý oficiální návod:
Můj postup je: nejdřív RAG rozchodím na jedné malé sadě dokumentů, až potom řeším škálování a automatizaci ingestu.
2) Reasoning přepínač (UX vs. kontrola)
Když chci rychle přidat přepínač, držím se community postu:
Když potřebuji dohledatelné chování v kódu, beru filtr jako vzor:
3) Provider jako pipeline (Gemini)
Když integruji providera, pipeline mi slouží jako „zdroj pravdy“ pro mapování API. Z mých poznámek:
Závěr / výstupy
Open WebUI mi dává jednotné UI nad více LLM backendy a rozšiřitelnost přes RAG a Functions/Pipelines. V praxi si vybírám mezi hotovým komunitním řešením (rychlost) a vlastním filtrem/pipeline (kontrola a auditovatelnost).
Doporučený postup
- Ověřím základní běh Open WebUI podle oficiální dokumentace (bez vlastních úprav).
- Zprovozním RAG podle RAG (Open WebUI docs) na malé sadě dat.
- Přidám integraci providera podle community postu (Gemini/Anthropic/OpenRouter) a ověřím jeden model end-to-end.
- Rozhodnu se, zda mi stačí hotový „plugin“, nebo potřebuji vlastní Function/Filter (např. reasoning toggle).
- Teprve potom řeším pokročilé doplňky (např. reasoning tokeny pro OpenRouter) a automatizaci.
Časté chyby / poznámky
- Pletu si „plugin“ a „pipeline“: plugin řeší hotovou funkci/UX, pipeline řeší integraci/tok volání (provider, routing, modality).
- Nasazuji doplňky bez minimálního testu: nejdřív jeden model + jeden prompt, až potom další vrstvy (RAG, filtry, token telemetry).
- Spoléhám na poznámky místo dokumentace: u instalace a přesných kroků se držím oficiální dokumentace a README repozitářů, protože v poznámkách chybí detailní postupy.
Petr Nosek