StellarBase
Dokumentace StellarBase platforma AI agenti
StellarBase platforma

AI agenti

Specializovaný AI specialista, kterého konfigurujete. System prompt agenta je tam, kde žije vaše doménová expertíza. Jeho nástroje, knowledge scope a output schema ho dělají předvídatelným. Každá odpověď je s citací.

Co je agent

Agent je konfigurace, ne pevný model. Definuje ho pět částí:

ČástCo určuje
Jméno + roleJak ho uživatelé volají; jak se prezentuje
System promptChování, omezení, váš playbook
Knowledge scopeKteré kolekce může číst
Tool allowlistKteré akce může provádět
Output schemaZda odpovědi musí mít pevnou strukturu

System prompt je aktivum

Většina vaší doménové expertízy — playbook vaší kanceláře, protokoly vaší nemocnice, heuristiky vašeho seniorního inženýra — se zakóduje do system promptu. Je to nejcennější věc, kterou na platformě vytvoříte.

Dobré prompty sdílejí strukturu:

  • Definice role — „You are a [specific role].”
  • Cíl — jak vypadá úspěch jedné úlohy
  • Vstupy — co agent dostane
  • Požadované výstupy — přesná pole, formát, požadavky na citace
  • Pravidla / heuristiky — pravidla z vašeho playbooku, pojmenovaná explicitně
  • Hraniční případy — co dělat, když je vstup nejednoznačný, chybí, konfliktuje
  • Styl — formální / neformální, jazyk, stručnost

Odolejte pokušení napsat jednoho obřího agenta, který dělá všechno. Specialisté přebijí generalisty. Tři zaměření agenti (NDA Reviewer, MSA Reviewer, Employment Reviewer) přebijí jednoho „Contract Revieweru”, který se snaží být všemi třemi.

Knowledge scope

Omezte každého agenta jen na kolekce, které opravdu potřebuje. Výzkumný agent nepotřebuje přístup k HR záznamům. Scoping je důležitý pro:

  • Kvalitu — agenti fungují líp na zaměřených korpusech
  • Soukromí — i autorizovaní uživatelé mohou chtít striktní oddělení dat
  • Náklady — menší scope znamená menší retrieval payloady
  • Rychlost — méně k prohledání

Scopes lze definovat na úrovni Base, kolekce nebo dokumentových tagů.

Nástroje

Nástroje jsou funkce, které agent může volat. Platforma přichází s built-iny pokrývajícími základy — vyhledávání nad knowledge base, vyhledávání uvnitř konkrétního dokumentu, stažení plného obsahu dokumentu, OCR nad přiloženými soubory, rozpoznávání entit a dotazy nad grafem a vystavení strukturovaného výstupu dle schématu.

Nad rámec built-inů registrujte vlastní nástroje — REST endpointy, vlastní Python skripty, vlastní ML modely, kalendářové API, cokoli adresovatelného. Viz Zero-Trust pro to, jak tool allowlists fungují.

Output schema (volitelné, ale doporučené)

Pro agenty, jejichž výstup teče do downstream systémů (CSV exporty, inserty do databáze, kroky workflow), definujte output schema. Odpověď agenta mu musí odpovídat. Příklady:

  • Řádek risk registru: id, typ, protistrana, jurisdikce, risk_level, flag_text, citace
  • Možnost léčby: regimen, evidence_grade, kontraindikace, citation_url
  • Řádek lit-review: paper_id, relevance_score, shrnutí, metody, omezení

Vynucování schématu používá nativní structured-output features moderních LLM. Agent se až N-krát pokusí zopakovat, pokud jeho výstup neodpovídá; pokud pořád neodpovídá, workflow označí řádek na human review.

Multi-agent workflow

Agenti mohou volat jiné agenty. Agent „Tumor Board Coordinator” může postupně volat „Case Summarizer”, „Guideline Agent” a „Literature Agent”, pak syntetizovat jejich výstupy do finálního packu.

Tahle kompozice je preferovaná před jedním mega-agentem. Každý komponentní agent je testovatelný v izolaci; orchestrace je vlastní starost.

Verzování

🛠 Na roadmapě. Verzování agentů — rollback a porovnání verzí vedle sebe — je na roadmapě; bez pevného data.

Každá změna promptu nebo konfigurace agenta je verzovaná. Okamžité rollback, pokud nová verze regreduje. Porovnejte dvě verze vedle sebe na held-out testovací sadě.

Testování

Postavte testovací sadu reprezentativních vstupů (5–50 případů). Spouštějte agenta proti sadě po každé změně promptu. Sledujte kvalitu jednoduchým rubricem:

  • Vyprodukoval očekávanou strukturu výstupu?
  • Citoval správně?
  • Dodržel pravidla playbooku?
  • Označil hraniční případy přiměřeně?

Testovací sady brání tomu, aby ladění promptu regresovalo dříve fungující případy.

Náklady a latence

Náklady agenta dominují LLM tokeny. Tipy:

  • Těsný knowledge scope sníží retrieval payload, což sníží velikost kontextu
  • Používejte menší modely (GPT-OSS 120B místo Qwen 3.5 397B), kde to kvalita dovolí
  • Cachujte deterministické dílčí výsledky
  • Použijte smart routing pro výběr nejlevnějšího modelu, který splňuje vaši kvalitativní laťku

Časté chyby

  • Vágní prompty — „prokontroluj tohle a řekni, jestli je to dobré” → agent neví, co dobré znamená
  • Chybějící hraniční případy — agent sebevědomě produkuje nesmysly pro vstupy, které jste neočekávali
  • Žádné output schema — agenti časem driftují ve formátu a rozbíjí downstream parsery
  • Příliš mnoho nástrojů — agenti volí špatné nástroje, když je jich k dispozici hodně; allowlist těsně
  • Žádná testovací sada — každá úprava promptu je riskantní

Související

  • Workflows — spouštění agentů na plán
  • Chat — volání agentů konverzačně
  • LLMs — výběr správného modelu pro agenta
  • Zero-Trust — bezpečnost nástrojů