Деterминизм на исключениях

Архитектурный паттерн от Kognitos. Применимо ко всей нашей системе агентов.

Идея

LLM используется только для двух вещей:

1. Интерпретация input'а — понять задачу в plain English, распознать сущности, классифицировать
2. Обработка исключений — когда нет правила, спросить человека, превратить ответ в правило

Исполнение всегда детерминированное — code-based rules, не LLM.

Цикл обучения

unknown case → LLM спрашивает человека → ответ становится правилом → следующий раз детерминированно

Каждое исключение делает систему умнее. На масштабе 95% кейсов уже превращены в правила — система становится почти детерминированной.

Маркетинг Kognitos vs реальность

"Hallucination-free" — упрощение. На исключениях LLM всё ещё может ошибиться. Но happy path точно предсказуем — это и есть честный дифференциатор для регулируемых отраслей (банки, страховые, фарма).

Почему это важно для нас

В банке (Альфа) и в KSA/Катар enterprise сегменте — галлюцинации = убийца. Архитектурное разделение "LLM интерпретирует, код исполняет" снимает 80% возражений по compliance.

Конкретно для наших модулей:

• Jira Quality Auditor: проверки "эпик с одной задачей", "прощёлкан по статусам за день" — детерминистические правила. LLM нужен только для semantic-проверок типа "оцени релевантность acceptance criteria к описанию задачи"
• Backlog Dynamics: статистика по aging/churn — pure code. LLM нужен только для интерпретации "что это значит для команды"
• Cross-source aggregator: entity-linking (ticket ID в тексте) — детерминированно. Semantic-matching ("эта почтовая дискуссия связана с этим эпиком") — LLM

Реализация в LangGraph

В графе разделять детерминистические узлы (pure functions) и LLM-узлы. LLM-узлы должны иметь:

• Строгий Pydantic schema на output (см. ../architecture/gemini-six-modules)
• max_loops лимит чтобы не было tool storms
• Логирование решений (для Langfuse trace)

Связано

• living-sops — как Kognitos реализует цикл обучения
• ../market/competitors/kognitos
• ../architecture/gemini-six-modules