Модель данных

Инструмент — вызываемая функция, подаётся модели как tool-schema (не промпт). Каталог открытый — реестр типов (пресеты платформы + свой класс организации, зеркало коннекторов): список — живой реестр, эта таблица хранит состояние по name (нет строки = тип выключен, дефолты), строка заводится лениво. v1 засевает два read-only пресета — web_search и fetch_url, оба выключены. Допуск — две независимые поверхности: chat_enabled (виден чату) и agents_allowed (разрешён к выбору агентам); инструмент активен, пока подан хоть одной. Сам выбор агента — связь agent_tools в Agent Engine; рантайм фильтрует её по текущему agents_allowed, снятие → агент на ядре KS (мягкая деградация). Несекретная настройка (провайдер web_search, опции) — в config, правит админ на экране, не конфиг-файлом; секрет — в credential_enc, не в config: как ключи ai_providers и SMTP, наружу лишь флаг is_set. status / last_check_at держат итог проверки работоспособности — тем же приёмом, что ai_providers.

ORM-модели — в пакете ai_foundation/models.py (конвенция кода — пакет на модуль), не в admin: назначенные модели читают AI Harvester (embed), Knowledge Store (реэмбеддинг), Query Engine (RAG) и Agent Engine — четыре потребителя, не только Admin. Admin предоставляет CRUD и экраны; зависимости идут к core — без циклов.

Платформа везёт собственный локальный embeddings-рантайм — отдельный сервис docker-compose (OpenAI-совместимый, model-agnostic), поднимается на make up рядом с backend; контейнер лёгкий, ML-зависимости в API-образ не тянет. Веса при установке не качаются: рантайм тянет их лениво — по назначению модели (и сразу прогревает её, не ожидая первого запроса), в кеш-том. До выбора эмбеддер не занимает ни диска, ни памяти, и потому не лимитирует деплой. Миграция засевает is_system-провайдера Platform (неудаляем, base_url на внутренний сервис, без ключа) и каталог встроенных моделей — выбираемых (is_enabled=true), но не загруженных. Набор задаёт seed, не экраны (первая итерация — bge-m3 и Qwen3-Embedding-0.6B, обе 1024-мерные); макеты ссылаются на них лишь примером. Назначения по умолчанию нет: строки model_assignments.harvester_embedding на старте не существует, и Harvester без назначения приём не стартует — Admin обязан назначить embedding-модель (встроенную или свою) до первого приёма. Причина жёсткая: выбор фиксирует размерность N колонки chunks.embedding, а поздняя смена — массовый переэмбеддинг (при иной N — миграция схемы). Дефолт намеренно пуст: ни модель, ни её вес не навязываются инсталляцией. Как этот сервис держит потоки нагрузки и масштабируется (v1 → v2) — embeddings-рантайм.

Параметры, заданные самой моделью — размерность вектора (embedding_dim), потолок окна (max_input_tokens), обязательный префикс (instruction_prefix) — живут в meta модели, не в конфиге потребителя (no hardcoding): чанкер Harvester читает потолок оттуда, KS берёт embedding_dim назначенной embedding-модели и провизионит halfvec(N). Встроенные модели засеваются со своими интринсиками — bge-m3: { embedding_dim: 1024, max_input_tokens: 8192 }, Qwen3-Embedding-0.6B: { 1024, 32768 }. Размерность облачной модели (embedding_dim) discovery не возвращает, поэтому админ задаёт её при добавлении модели; модель без заданной размерности — или с размерностью, не совпадающей с выделенным halfvec(N), — отклоняется при назначении (409), ещё до старта переэмбеддинга.

model_usage копит requests / tokens / cost по (модель · функция · день), не event-log на каждый запрос. Порог бюджета — настройка инстанса (ai_monthly_budget + ai_budget_alert_enabled) и живёт не здесь, а в platform_settings, рядом с maintenance_mode: админ вводит сумму руками и включает тумблером (CHECK не даёт включить оповещение без суммы) на экране Расходы AI, в общем доме лимитов. При достижении порога поднимается уведомление типа Budget — канал держит модуль уведомлений. Панорама расхода за неделю / месяц / год на том же экране — производная SUM по периоду, без отдельной таблицы-счётчика. Как устроен учёт целиком — бизнес-логика расходов.