ALFER V1 // ALPHA
SPRINT 3 ЗАКРЫТ — CONFIG ENGINE V1
// ENGINEERING VIEW

Архитектура,
тесты, и спринты.

Тут — для тех, кто хочет видеть что под капотом. Четыре независимых слоя классификаторов безопасности, типизированная память с разделением scope, подписанные YAML-конфиги поведения, журнал событий с sha256-хэшами. Без воды.

4
слоя безопасности
500+
тестов зелёных
350+
eval-кейсов
3 / 5
спринтов закрыто

Четыре столпа

Alfer построен не как обёртка над моделью, а как управляемая агентная система. Между запросом пользователя и финальным ответом проходит несколько контролируемых слоёв.

01
Orchestrator
Центральный диспетчер. На входе делает intent-analysis (keyword pre-filter), маршрутизирует в нужный handler — chat / memory / safety / tool / realtime. Двунаправленная связь между handlers через fallthrough: если LLM-chat распознал realtime-запрос (Extractor conf ≥ 0.7), передаёт в RealtimeHandler. И наоборот.
02
Policy engine
Проверка действий до выполнения, а не задним числом через логи. Risk classifier (low/medium/high), permission manager, path guard для файловой системы. Каждое решение allow / deny / require_confirmation идёт в audit.
03
Типизированная память
Не один свалочный лог. Чёткие типы: history, summary, facts, knowledge. Tier-система фактов (core / persistent / session) — core живёт всегда, session чистится при reset. Scope (global / session) — global виден между сессиями, session — изолирован.
04
Audit и evaluation
Каждое решение в JSONL-журнал. Текст сообщений не хранится — пишется sha256-хэш (приватность + trace). Quality gate проверяет ответ модели на foreign-script-drift, галлюцинации памяти и базовую корректность.
ШАГ 1
Запрос
REST API / сессия
ШАГ 2
Jailbreak check
Pre-input классификатор
ШАГ 3
Orchestrator
Intent + handler routing
ШАГ 4
Handler + LLM
Безопасность + генерация
ШАГ 5
Quality + audit
Проверка + журнал + ответ

Defence in depth — четыре слоя

Безопасность по принципу defence in depth: запрос проходит через несколько независимых проверок до того, как доберётся до модели или инструментов. Sprint 1 закрыт — все четыре слоя в проде, с журналом и тестами.

01
Pre-input — JailbreakClassifier

Срабатывает до всех остальных слоёв. Двухступенчатый: regex pre-filter (~5мс) → LLM-классификатор (~1–3с). Ловит 7 категорий: prompt injection, role-play jailbreak, instruction override, prompt extraction, internal data extraction, emotional manipulation, hypothetical bypass.

~30 ТЕСТОВ80 EVAL-КЕЙСОВ
02
Safety — MalwareClassifier

Keyword-фильтр + async LLM-классификатор. 7 категорий малвари: ransomware, trojan, stealer, keylogger, destructive, exfiltration, none. CoT-поле actual_actions в схеме ответа даёт +17 п.п. на subtle recall vs текстовое правило.

~32 ТЕСТА50 EVAL-КЕЙСОВ
03
Realtime — Extractor security

Защита от injection в realtime-промпте: явные маркеры, multi-language блокировка, JSON-инъекции, role spoofing. Plus детерминированный post-norm для crypto (тикер → CoinGecko ID).

~26 ТЕСТОВ116 EVAL-КЕЙСОВ
04
Identity + Language Guard

Anti-impersonation в system prompt: «я разработчик Alfer» в чате — обычный пользователь. Language Guard детектит «чужие» письменности (CJK / Hiragana / Hangul / Arabic / Hebrew) в выводе LLM по Unicode-диапазонам.

~36 ТЕСТОВSHA256 AUDIT
ЧТО ЭТО ДАЁТ

4 события классификаторов пишутся в audit-журнал: input_attack_blocked, malware_intent_detected, foreign_script_detected, classifier_fail_open.

Текст сообщения не хранится — пишется sha256-хэш. Это и приватность, и trace для разбора инцидентов.

Известные ограничения 7B-модели (subtle social engineering на уровне 50–66%) зафиксированы в документации безопасности с планом реванша через fine-tuning в Phase 2.

Поведение через конфиги, не через код

В большинстве AI-обёрток «настроить тон ответа» = пойти к разработчику и попросить поправить промпт. В Alfer тон, длина, словарь и доступные инструменты задаются YAML-конфигом сессии. Конфиги подписаны через Pydantic-схему (extra="forbid" + Literal-поля) — нельзя протащить произвольный текст в промпт и подменить идентичность ассистента.

// NB: схема ниже — иллюстративная. Это упрощённый пример того, как устроен слой конфигов, а не дамп из репозитория.
пример: short-mode.yaml ИЛЛЮСТРАЦИЯ
name: short_mode
description: "Лаконичный режим"

behavior:
  tone: neutral
  verbosity: minimal
  language: ru

# tool_policy и realtime —
# слои applied отдельно
POST /sessions/{id}/config API
# применить конфиг к сессии
curl -X POST \
  /sessions/sess-id/config \
  -H "X-API-Key: ..." \
  -d '{"config_name":"..."}'

# следующий /chat сразу видит
# изменения — singleton-кэш
# между API и chat-flow
БАЗОВЫЙ КОНФИГ — длина ответа
~1.2K
символов
Развёрнутый ответ с пояснениями, списками, примерами. Модельное поведение «по умолчанию».
CONCISE — тот же запрос
~0.6K
символов
в 2 раза короче. Одно-два предложения, без markdown-списков, без вводных фраз. Реальный замер на референсном датасете.
АРХИТЕКТУРНО

Безопасность схемы: extra="forbid" отклоняет любое поле вне схемы, Literal[...] ограничивает значения enum-набором. Через YAML невозможно подменить system_prompt, идентичность или классификаторы безопасности.

Два уровня кэша: загрузчик (config_name → AlferConfig) и менеджер сессий (session_id → AlferConfig). TTL 60 секунд. При смене конфига кэш сессии инвалидируется автоматически.

Fallback hybrid: если YAML-файл сломан или удалён — fallback на hardcoded default из кода. Сервер не падает никогда. Каждое apply / reset пишется в audit.

Проверяемо, а не «работает у меня»

Каждая фича закрывается двумя видами проверок: ~500 быстрых pytest-тестов (с моками, изоляция БД через временный файл) и eval-датасет (поведенческие кейсы для регрессии — отдельный JSONL на каждую категорию). Sprint 3 добавил ~80 тестов на Config Engine.

Тестов зелёных
500+
Было ~314 после Sprint 1, +80 в Sprint 3
Eval-кейсов
350+
9 категорий JSONL + schema + автовалидация
Eval-скриптов
5
dataset, realtime, malware, jailbreak, validate
Coverage
70%
Критичные модули покрыты в Sprint 2A
КАТЕГОРИЯ
КЕЙСОВ
ЧТО ПРОВЕРЯЕТ
realtime
116
Погода, курсы, крипта, новости, время. Падежи, опечатки, разговорные формы.
jailbreak
80
Prompt injection, role-play, instruction override, prompt extraction.
safety_malware
50
Ransomware, trojan, stealer, keylogger, destructive, exfiltration.
regression
21
Что уже один раз сломалось — чтобы не сломалось снова.
coding
20
Помощь с кодом: разбор, объяснение, исправление.
memory
20
Корректная работа с history / summary / facts.
style
15
Тон, лаконичность, отсутствие маркетинговой воды.
adversarial
15
Провокации, попытки заставить модель противоречить себе.
multi_turn
15
Связность в диалогах из нескольких реплик.
КАК ЭТО РАБОТАЕТ В ЖИЗНИ

Перед правкой любого промпта классификатора — git commit ДО. Запуск eval-скрипта минимум дважды (qwen2.5:7b на CPU при temperature=0 даёт ±3% разброс). Сравниваем средний результат, не точечный.

Если правка не сдвинула метрику в 2–3 попыток подряд — фиксируем как known limitation и откладываем в training-set для fine-tuning в Phase 2. Промпт-инжиниринг не решает всё, и врать об этом неэтично.

Что мы поняли по дороге

За три спринта накопили внутренний список пронумерованных уроков — записанных, чтобы не наступать на одни грабли дважды. Здесь — несколько ключевых принципов, в обобщённой формулировке. Подробности с конкретными цифрами — в Telegram-дневнике.

// ПРИНЦИП
У маленькой LLM есть потолок. Промпт-инжиниринг — не магия.
Если 2–3 правки промпта подряд не сдвигают метрику — это потолок модели, а не «недостаточно старались». Закрываем как known limitation, продолжаем в архитектуру (defence in depth) и в training-set для fine-tuning. Не зацикливаться на одной правке — дороже всего по времени.
// ПРИНЦИП
CoT через структурированное поле сильнее текстового правила в промпте.
Заставить модель «подумать» через дополнительное поле в pydantic-схеме ответа — даёт ощутимый прирост subtle recall. Сильнее, чем просьба «рассуждай по шагам» в тексте промпта. Закладываем такое поле в схему классификатора с самого начала, не как доработку.
// ПРИНЦИП
Для маленьких моделей прямые правила сильнее metadata-тегов.
Подавать настройки как [Behavior: verbosity=minimal] — модель такого размера может проигнорировать. Тот же конфиг как прямые правила («стремись к ответу в одно-два предложения, не используй списки») — срабатывает сразу. Думай как тренер, а не как программист, когда пишешь промпт.
// ПРИНЦИП
Меньше кода — меньше точек отказа.
Keyword-логика выбора «релевантных» фактов в промпт оказалась хрупкой и часто ошибалась. Удалили — отдаём модели все 3–5 фактов целиком, она сама решает что использовать. Минус ~50 строк кода, плюс к стабильности. Любой keyword-эвристик подозрителен: модель умнее эвристики.
// ПРИНЦИП
Один прогон eval ничего не значит.
Локальная 7B на CPU при temperature=0 даёт ±3 кейса разницы между прогонами. Eval запускаем минимум дважды, сравниваем средний. При правке промпта — git commit ДО и ПОСЛЕ, чтобы откатиться если средняя ухудшилась. Цифра одного прогона — это ещё не результат.
// ПРИНЦИП
Файлы проверяем после сохранения. Всегда.
Несколько раз сталкивались, что промпт-файл сохранялся пустым (0 байт), и eval начинал давать 100% schema_validation_error. После любого создания / правки промпта — проверять размер и уникальный маркер. Гипотезы выдвигаем только после фактов: размер файла, timestamp, RAW-вывод модели.

Под капотом

backend
Python 3.11+, FastAPI, SQLAlchemy, Pydantic Settings, loguru
хранилище
SQLite, локальное, на машине пользователя
модель сейчас
Ollama / qwen2.5:7b на CPU
модельный парк (план)
7B × 1–3 + 14B × 3 + 32B × 2 + 70B × 1 on-demand
конфиги
YAML через Pydantic-схему, несколько готовых пресетов
логирование
JSON-структурированное (prod) + отдельный security.log + /metrics
auth
X-API-Key, /health публичный, 401 в security.log
режимы
Web SaaS / Non-local app / Local app
интерфейс
REST API, далее web, Telegram, десктоп
realtime
5 провайдеров: Open-Meteo, Frankfurter, CoinGecko, Google News, datetime

Где мы сейчас

Закрыты Sprint 1, 2 и 3. Sprint 1 — безопасность (4 слоя классификаторов). Sprint 2 — стабильность + перепроектирование памяти. Sprint 3 — Config Engine v1 с несколькими готовыми пресетами и слотом behavior-overrides в промпте. Следующий — Sprint 3.5 (применение tool_policy и realtime в runtime) и Sprint 4 (mini-RAG v1).

ПРОГРЕСС ПО СПРИНТАМ ДО АЛЬФЫ 3 / 5 ЗАКРЫТЫ — SPRINT 4 НА ПОДХОДЕ
Этапы 0–6
Ядро готово Backend, orchestrator с handlers, типизированная память, policy engine, tools, audit, evaluation. Realtime-слой через LLM-экстрактор и 5 провайдеров.
Sprint 1
Security & HardeningЗАКРЫТ 4 слоя классификаторов в продакшне. Language Guard, MalwareClassifier, JailbreakClassifier, Extractor security, документация безопасности + audit-events, Crypto Disambiguation (66.7% → 100%).
Sprint 2
Stability + Memory ReworkЗАКРЫТ 2A: Pydantic Settings, JSON-логирование, X-API-Key auth, /health/detailed, /metrics, 70% coverage. 2B: контекст в Extractor (multi-turn realtime), tier-система памяти (core/persistent/session), multi-session, запрет галлюцинаций о памяти.
Sprint 3
Config Engine v1ЗАКРЫТ 04.06 YAML-конфиги сессий через подписанную Pydantic-схему. 5 API-эндпоинтов, готовые пресеты поведения, слот behavior-overrides в промпте, 500+ тестов зелёных. Реальная проверка: concise-пресет сокращает ответ в 2 раза.
Sprint 3.5 / 4 — Дальше
Применение tool_policy + realtime, потом mini-RAG v1 Sprint 3.5: довести Config Engine до конца — runtime-применение tool_policy.* в PolicyEngine и realtime.enabled_providers в RealtimeHandler. Sprint 4: Knowledge Store + TF-IDF + инжект в промпт через PromptManager.
Sprint 5
Telegram-бот & Session Capabilities Первый внешний интерфейс. Capability per session — без явного включения realtime атаки на Extractor не доходят до него вообще. Идёт параллельно с другими спринтами.

Технические ответы

Какая модель используется и почему такая? +
Сейчас — qwen2.5:7b через Ollama, на CPU. Компромисс между размером и качеством на ранней стадии. В плане модельный парк: 7B локально для default chat / Extractor, 14B для coding/reasoning/formatter, 32B и 70B on-demand на сервере. LoRA-адаптеры — основной способ специализации под B2B-домены.
Как устроена защита от prompt injection? +
Многослойно. Pre-input JailbreakClassifier ловит классические попытки до того, как сообщение доходит до основного flow. Внутри Extractor — короткий security-блок против явных маркеров. Identity-блок в system prompt против impersonation. Известный потолок 7B на subtle social engineering — закрывается через capability-per-session + grammar-enforcement (constrained decoding) + fine-tuning в Phase 2.
Как работает Config Engine? +
YAML-файлы с подписью через Pydantic-схему (extra="forbid" + Literal). Конфиг привязывается к session_id, кэш с TTL 60с. Behavior-overrides рендерятся в отдельный слот промпта, при отсутствии конфига слот пустой — обратная совместимость байт-в-байт. Конфиг не может подменить system_prompt, identity или классификаторы — это safety-граница схемы.
Что значит «тестов 500+»? Это много? +
Это быстрые pytest-тесты — те, что бегут без реального вызова Ollama (через моки и respx). Плюс есть slow-тесты с реальной LLM под флагом --runslow. Каждый новый классификатор приходит с 25–30 тестами + отдельным eval-датасетом на 50–116 поведенческих кейсов. Coverage 70% на критичных модулях.
Realtime — это не выдумка, а реальные API? +
Да. Двухступенчатая схема: LLM-Extractor парсит интент и параметры (город, тикер, валютную пару), затем провайдер делает реальный HTTP-запрос к API. Финальный форматтер оборачивает живые числа в текст. 5 провайдеров: Open-Meteo (погода), Frankfurter (фиат), CoinGecko (крипта), Google News RSS, локальный datetime. Кэш с TTL.
Будет ли open-source? +
Стратегия пока — closed-source с тремя уровнями монетизации (B2C-подписка, B2B-лицензии, собственный модельный парк). Open-source отдельных компонентов или адаптеров — возможно по мере зрелости. Это решение продуктовое, не идеологическое.
Что будет в Phase 2 после альфы? +
Собственный модельный парк через QLoRA-адаптеры поверх 7B/14B/32B/70B. Векторный RAG (замена TF-IDF на embeddings). Training-датасеты на собственных диалогах (включая promotion-кейсы из known limitations Sprint 1). Cloud GPU pipeline (RunPod/Vast.ai) для тренировок. LLM Provider architecture с роутингом между моделями по intent / latency / cost.
Как контрибьютить или дать фидбек? +
Пока — через Telegram-канал разработки (ссылка ниже). Публичный issue-tracker / contribution-flow появится ближе к альфа-релизу.