Aplikace funguje, databáze odpovídá a jednotlivé funkce se zdají být v pořádku. Jak ale přibývají uživatelé a data, některé stránky se začnou načítat čím dál pomaleji. Příčinou přitom nemusí být slabý server ani špatně navržená databáze. Někdy stačí, že aplikace provádí příliš mnoho zbytečných databázových dotazů.

Tento problém se označuje jako N+1 Query Problem a objevuje se také při vývoji aplikací v Djangu. Dobrou zprávou je, že ho lze v mnoha případech vyřešit poměrně jednoduchou optimalizací.

Představte si, že váš tým strávil týdny vývojem nové aplikace. Design vypadá skvěle, všechna tlačítka fungují a vývojáři jsou s výsledkem spokojení. Pak aplikaci dostane do rukou první uživatel. Neví, kde si vytvořit účet, přehlédne důležitou funkci a nakonec aplikaci zavře.

Problém nemusí být v technickém řešení. Možná aplikace jednoduše není tak intuitivní, jak jste předpokládali.

Právě proto má UX testování smysl. Pomáhá odhalit problémy s používáním produktu ještě předtím, než se z nich stanou nákladné opravy nebo důvod, proč uživatelé přejdou ke konkurenci.

Dobrou zprávou je, že na začátku nepotřebujete drahou výzkumnou agenturu ani specializovanou testovací laboratoř. Potřebujete vědět, co chcete zjistit, najít několik vhodných lidí a pozorovat, jak s vaším produktem pracují.

Představte si, že se zákazník zeptá chatbota vaší firmy: „Do kdy můžu vrátit objednávku?“ Chatbot zná obecná pravidla pro vracení zboží, ale nezná konkrétní podmínky vašeho e-shopu. Může proto nabídnout odpověď, která zní přesvědčivě, ale ve skutečnosti není správná.

Právě tady přichází na řadu RAG (Retrieval-Augmented Generation). Jde o přístup, který umožňuje AI vyhledávat relevantní informace ve vašich vlastních datech a na jejich základě formulovat odpovědi. Místo spoléhání se pouze na znalosti, které model získal během trénování, tak může pracovat například s firemní dokumentací, interními pravidly nebo produktovými informacemi.

Představte si, že sedíte v metru, otevřete svou oblíbenou aplikaci a zjistíte, že nemáte připojení k internetu. Chcete si poznamenat úkol, upravit nákupní seznam nebo si přečíst uložený článek. Aplikace se ale nekonečně načítá nebo zobrazuje chybovou hlášku.

Představte si, že máte firemní databázi s tisíci dokumentů. Uživatel do vyhledávání zadá:

„Jak můžu změnit heslo?“

Klasické vyhledávání bude hledat dokumenty, ve kterých se nacházejí slova jako změnit nebo heslo.

Co když se ale relevantní dokument jmenuje „Obnovení přihlašovacích údajů“?

Pro člověka je význam jasný. Klasické keyword search ale nemusí pochopit, že jde o stejné téma.

Právě tady přichází na řadu vector search. Místo hledání pouze stejných slov porovnává význam obsahu reprezentovaný číselnými vektory.

Push notifikace vypadají jednoduše. Někdo napíše zprávu, klikne na Send a za chvíli se na telefonu uživatele objeví banner.

Mezi těmito dvěma okamžiky se ale odehraje překvapivě hodně věcí.

Zpráva musí projít přes backend, správnou push službu, operační systém a nakonec se dostat až k aplikaci v zařízení. A pokud se něco pokazí, problém nemusí být přímo v samotné zprávě.

Pojďme se proto podívat, co se s push notifikací děje od jejího odeslání až po zobrazení na telefonu uživatele.

AI agent může na první pohled fungovat perfektně. Dostane úkol, použije správné nástroje a vrátí výsledek, který vypadá správně.

Ale co když měl jednoduše štěstí?

Co když použil špatný nástroj, provedl deset zbytečných API volání nebo se při podobném zadání rozhodne úplně jinak?

Proto se při hodnocení AI agentů stále méně ptáme „Funguje?“ a stále více „Jak dobře, konzistentně a bezpečně funguje?“

Evaluating AI agents znamená systematicky testovat nejen finální výsledek, ale také proces, který k němu vedl. Moderní přístupy k evaluaci sledují například rozhodování agenta, tool calls, náklady, bezpečnost nebo jeho chování ve chvíli, kdy se něco pokazí.

Vývoj aplikace může na začátku působit docela jednoduše. Pak ale přijdou první otázky: Co přesně se má vyvíjet? Jak má vypadat finální design? Které funkce jsou opravdu potřeba? Co se stane, když se změní požadavky? A proč všechno trvá déle, než se původně plánovalo?

Ne vždy je problém na straně vývojářského týmu. Někdy je problém v tom, jak je celý projekt řízený.

Dobrý projektový management přitom neznamená organizovat co nejvíce schůzek nebo zapisovat každý úkol do tabulky. Jde o to zajistit, aby všichni zúčastnění měli před očima stejný produkt, priority byly jasné a projekt se neustále posouval dopředu.

Aplikace může být pomalá, i když má dobře navrženou databázi a výkonný server. Někdy problém nespočívá v tom, že databáze nedokáže dotaz zpracovat, ale v tom, že aplikace opakovaně načítá stejná data.

A právě tady přichází na řadu caching neboli kešování.

Caching umožňuje ukládat často používaná data do rychlejší vrstvy, takže je není nutné pokaždé znovu načítat nebo počítat. Jedním z nejčastěji používaných nástrojů pro tento účel je Redis.

Když jde o růst mobilní aplikace, často mluvíme o sales funnelech. Uživatel aplikaci objeví, zaregistruje se, začne ji používat a nakonec provede požadovanou akci – například nakoupí nebo si předplatí službu.

V posledních letech se však stále více pozornosti věnuje také jinému modelu: growth loops.

Zatímco funnel popisuje cestu uživatele od prvního kontaktu až ke konverzi, growth loop se snaží vytvořit cyklus, ve kterém jedna uživatelská akce pomáhá generovat další uživatele nebo další hodnotu.

Jaký je mezi nimi rozdíl a kdy se který přístup vyplatí?