Первичная настройка Unica после первого развёртывания

Версия: 1.69

Этот документ нужен администратору, который впервые принимает уже развёрнутый инстанс Unica и должен довести его до рабочего состояния без обращения к другим инструкциям.

Документ построен как пошаговая инструкция первичного запуска:

1. сначала пройти минимальный обязательный маршрут запуска;
2. затем проверить расширенные и опциональные настройки;
3. в конце выполнить единый smoke-check.

Что вы получите по итогам

После прохождения инструкции у вас должно быть:

• хотя бы одно рабочее пространство с владельцем и активным тарифом;
• хотя бы один активный LLM-провайдер и хотя бы одна активная LLM-модель;
• настроенный провайдер эмбеддингов и сохранённая глобальная политика индексации;
• активный файловый провайдер;
• хотя бы один включённый ASR-провайдер Unica и хотя бы одна успешная ASR-операция;
• рабочий биллинг, если инсталляция должна учитывать кредиты, лимиты и списания.

Что не входит в минимальный маршрут

Эти разделы важны, но не блокируют базовый запуск, если не входят в поставку:

• Настройки агента;
• Workflow-сценарии;
• SMTP;
• OAuth-провайдеры входа.

Минимальный маршрут запуска

Если вам нужно быстро понять порядок действий, используйте этот маршрут:

Что подготовить заранее

Перед входом в UI соберите исходные данные:

1. Стартовая точка: экран первичного запуска

Где смотреть

• прямой маршрут Первичный запуск (/settings/administration/setup)
• Настройки -> Администрирование -> Обзор (/settings/administration/overview)

Что сделать

1. Откройте /settings/administration/setup сразу после первого входа.
2. Зафиксируйте статусы четырёх встроенных блоков:
   • Доступ и роли
   • LLM и модели
   • Базы знаний
   • Транскрибация
3. Дальше возвращайтесь на эту страницу после завершения каждого обязательного шага.

Как понимать статусы

Важно

• Раздел Первичный запуск скрыт в текущем боковом меню, поэтому его удобнее открывать по прямому URL.
• Экран первичного запуска не проверяет биллинг, SMTP и OAuth.
• Эти разделы нужно настраивать отдельно, даже если четыре встроенных блока уже горят зелёным.

2. Доступ и рабочие пространства

Цель шага

Получить хотя бы один рабочий workspace, хотя бы одного пользователя и рабочий локальный вход администратора.

Где настраивать

• Настройки -> Администрирование -> Рабочие пространства (/settings/administration/access/workspaces)
• Настройки -> Администрирование -> Пользователи (/settings/administration/access/users)
• Настройки -> Администрирование -> Аутентификация (/settings/administration/access/auth)

Что нужно на входе

• имя первого workspace;
• владелец workspace;
• список первых пользователей;
• активный тариф, который должен быть назначен workspace.

Что сделать

1. Создайте первое рабочее пространство.
2. Назначьте владельца.
3. Назначьте workspace активный тариф.
4. Добавьте или активируйте пользователей, которые будут работать в системе.
5. Проверьте локальный вход администратора.

Особые случаи

• В DEPLOYMENT_MODE=onprem workspace создаётся прямо из UI.
• Если workspace уже создан в рамках поставки или инстанс работает в cloud, проверьте существующий workspace вместо создания нового.
• OAuth на этом шаге не нужен: локальный admin-вход должен работать в любом случае.

Готово, если

• существует хотя бы один workspace;
• существует хотя бы один пользователь;
• у workspace есть владелец;
• у workspace назначен активный тариф;
• блок Доступ и роли на /settings/administration/setup находится в статусе ready.

Если блок не стал ready

• проверьте, что workspace действительно сохранён и отображается в списке;
• проверьте, что в системе есть хотя бы один пользователь, а не только пустой workspace;
• не считайте шаг завершённым только по факту входа администратора: встроенный блок проверяет именно наличие workspace и пользователя.

3. LLM-провайдер и AI-модели

Цель шага

Подключить рабочий LLM-провайдер и убедиться, что для него заведены активные LLM-модели в едином реестре.

Где настраивать

• Настройки -> Администрирование -> Провайдеры LLM (/settings/administration/llm/providers)
• Настройки -> Администрирование -> AI-модели (/settings/administration/platform/models)

Что нужно на входе

• тип LLM-провайдера;
• endpoint/base URL;
• токен или API-ключ;
• список рабочих моделей;
• точные providerModelKey этих моделей.

Что сделать

1. Создайте LLM-провайдер и сохраните его.
2. Убедитесь, что провайдер доступен в системе и не находится в ошибочном состоянии.
3. Откройте AI-модели.
4. Для каждой рабочей модели создайте или проверьте запись со следующими параметрами:
   • Тип модели: LLM
   • Provider: нужный LLM-провайдер
   • providerModelKey: точный ключ модели у провайдера
   • Consumption unit: За 1000 токенов
   • creditsPerUnit: стоимость за 1000 токенов, если модель должна участвовать в биллинге
   • isActive: включено
5. Если модель не должна тарифицироваться, creditsPerUnit можно оставить 0.

Готово, если

• в системе есть хотя бы один активный LLM-провайдер;
• в AI-модели есть хотя бы одна активная модель типа LLM;
• рабочие модели привязаны к правильному провайдеру и имеют корректный providerModelKey;
• блок LLM и модели на /settings/administration/setup находится в статусе ready.

Если блок не стал ready

• проверьте не только провайдер, но и реестр AI-модели;
• убедитесь, что модель имеет тип LLM, а не другой тип;
• убедитесь, что isActive включён;
• если провайдер сохранён, но модели не заведены, встроенный блок останется неготовым.

4. Эмбеддинги и индексация

Цель шага

Подключить провайдер эмбеддингов, выбрать рабочую модель эмбеддингов и сохранить валидную глобальную политику индексации.

Где настраивать

• Настройки -> Администрирование -> Провайдеры эмбеддингов (/settings/administration/knowledge/embeddings)
• Настройки -> Администрирование -> Индексация и поиск (/settings/administration/knowledge/indexing)
• Настройки -> Администрирование -> Векторное хранилище (/settings/administration/knowledge/vector-storage)
• Настройки -> Администрирование -> AI-модели (/settings/administration/platform/models)

Что нужно на входе

• endpoint/base URL и ключ доступа для провайдера эмбеддингов;
• точные providerModelKey моделей эмбеддингов;
• выбранная рабочая модель эмбеддингов;
• желаемые параметры chunking и retrieval, если они уже согласованы.

Что сделать

1. Создайте провайдер эмбеддингов и сохраните его.
2. Перейдите в AI-модели и проверьте, что нужные модели эмбеддингов присутствуют и активны.
3. Для рабочей модели проверьте:
   • Тип модели: EMBEDDINGS
   • Provider: нужный провайдер эмбеддингов
   • providerModelKey: точный ключ модели
   • Consumption unit: За 1000 токенов
   • creditsPerUnit: цена эмбеддингов, если для них включён биллинг
   • isActive: включено
4. Откройте Индексация и поиск.
5. Выберите провайдер эмбеддингов и модель эмбеддингов.
6. Сохраните глобальную политику индексации и параметры chunking/retrieval.
7. Используйте Векторное хранилище только для проверки коллекций и состояния индекса.

Готово, если

• провайдер эмбеддингов настроен;
• в реестре есть активная модель типа EMBEDDINGS;
• глобальная политика индексации сохранена и ссылается на существующие провайдер и модель;
• блок Базы знаний на /settings/administration/setup находится в статусе ready.

Если блок не стал ready

• проверьте, что политика ссылается именно на существующие провайдер и модель;
• не полагайтесь только на автоматическую синхронизацию моделей: проверьте AI-модели вручную;
• если провайдер есть, но политика не сохранена или ссылается на невалидную модель, шаг останется неготовым.

5. Речь, ASR и файловое хранилище

Цель шага

Подключить файловый провайдер, настроить ASR-провайдер Unica и получить первую успешную транскрибацию.

Где настраивать

• Настройки -> Администрирование -> Файловые хранилища (/settings/administration/speech/file-storage)
• Настройки -> Администрирование -> ASR-провайдеры (/settings/administration/speech/asr-providers)
• Настройки -> Администрирование -> Рабочие пространства (/settings/administration/access/workspaces)
• Настройки -> Администрирование -> AI-модели (/settings/administration/platform/models) если ASR должен участвовать в биллинге

Что нужно на входе

• параметры S3/MinIO или совместимого файлового провайдера;
• baseUrl и workspaceId ASR-сервиса;
• тип ASR-провайдера;
• тестовый аудиофайл;
• решение, должна ли ASR-модель участвовать в кредитном биллинге.

Что сделать

1. В Файловые хранилища создайте провайдер с корректным baseUrl, типом аутентификации и активным статусом.
2. Вернитесь в Рабочие пространства и назначьте этому workspace File Storage Provider по умолчанию.
3. В ASR-провайдеры создайте провайдер и заполните:
   • displayName
   • asrProviderType
   • baseUrl
   • workspaceId
   • fileStorageProviderId
   • polling interval и timeout, если поставщик требует свои значения
   • isEnabled
   • default ASR, если это основной провайдер транскрибации
4. Если ASR должен участвовать в биллинге, проверьте в AI-модели активную модель типа ASR:
   • Consumption unit: За минуту
   • creditsPerUnit: стоимость минуты
5. Выполните хотя бы одну реальную транскрибацию тестового аудиофайла.

Готово, если

• хотя бы один провайдер речи включён;
• хотя бы один файловый провайдер активен;
• у целевого workspace назначен File Storage Provider по умолчанию;
• хотя бы один ASR-провайдер Unica включён и при необходимости отмечен как default;
• в Запуски ASR (/settings/administration/asr-executions) есть хотя бы одна успешная операция;
• блок Транскрибация на /settings/administration/setup находится в статусе ready.

Если блок не стал ready

• проверьте, что файловый провайдер имеет активный статус;
• проверьте, что ASR-провайдер не просто сохранён, а именно включён;
• встроенный блок не станет ready, пока не появится первая успешная ASR-операция.

6. Биллинг, тарифы и цены моделей

Цель шага

Привести тарифы, лимиты и цены моделей к реальной политике внедрения, чтобы списания и ограничения работали предсказуемо.

Где настраивать

• Настройки -> Администрирование -> Биллинг и лимиты (/settings/administration/platform/billing)
• Настройки -> Администрирование -> Журнал списаний (/settings/administration/platform/billing/charges)
• Настройки -> Администрирование -> Журнал блокировок (/settings/administration/platform/billing/blocks)
• Настройки -> Администрирование -> AI-модели (/settings/administration/platform/models)
• Настройки -> Администрирование -> Рабочие пространства (/settings/administration/access/workspaces)

Что нужно на входе

• какие тарифы должны быть активны;
• какой тариф должен быть default;
• какие лимиты должны действовать на каждом тарифе;
• какие модели должны списывать кредиты и по какой логике.

Что сделать

1. Откройте Биллинг и лимиты и проверьте seed-тарифы, созданные системой при старте.
2. Не назначайте случайные числовые значения: на этом шаге нужно довести тарифы до заранее согласованной политики.
3. Для каждого используемого тарифа проверьте и при необходимости обновите:
   • isActive
   • isDefault
   • includedCreditsAmount
   • includedCreditsPeriod
   • лимиты тарифа
4. Убедитесь, что рабочий default-тариф остаётся активным.
5. В Рабочие пространства привяжите каждому workspace нужный активный тариф.
6. В AI-модели задайте creditsPerUnit для рабочих моделей:
   • LLM и EMBEDDINGS — цена за 1000 токенов
   • ASR — цена за 1 минуту
7. Если модель не должна участвовать в списаниях, creditsPerUnit можно оставить 0.
8. После тестовых операций проверьте Журнал списаний и Журнал блокировок.

Что важно понимать

• Биллинг не заработает “сам по себе” только от наличия тарифов.
• Нужны обе настройки:
  • workspace привязан к тарифу;
  • у используемых моделей заполнен корректный creditsPerUnit, если по ним должны списываться кредиты.

Готово, если

• есть активный рабочий default-тариф;
• целевые workspace привязаны к активным тарифам;
• у тарифицируемых моделей заполнен корректный creditsPerUnit;
• тестовые операции создают ожидаемые записи в Журнал списаний.

Если результат не совпал с ожиданием

• если списаний нет, сначала проверьте creditsPerUnit у конкретной модели;
• если тариф выбран, но кредиты ведут себя странно, проверьте лимиты и includedCreditsAmount;
• если модель должна быть бесплатной, убедитесь, что creditsPerUnit действительно равен 0.

7. Настройки агента

Когда нужен этот раздел

• Если в поставке используется agent runtime.

Где настраивать

• Настройки -> Администрирование -> Настройки агента (/settings/administration/llm/agent-settings)

Что сделать

1. Выберите agent default model.
2. При необходимости выберите fast-path model.
3. При необходимости сохраните smalltalk-фразы.
4. При необходимости ограничьте capabilities агента.

Готово, если

• настройки сохранены без ошибки;
• выбранные модели активны и присутствуют в AI-модели.

8. Workflow-сценарии

Когда нужен этот раздел

• Если workflows входят в поставку и раздел виден в боковом меню.

Где настраивать

• Настройки -> Администрирование -> Workflow-сценарии (/settings/administration/llm/workflows)

Что сделать

1. Создайте сценарий с нуля или скопируйте шаблон.
2. Привяжите сценарий к целевому workspace.
3. Переведите сценарий в опубликованное состояние.

Готово, если

• нужный сценарий имеет статус Опубликован;
• сценарий доступен в целевом workspace.

9. SMTP

Когда нужен этот раздел

• Если в контуре используются письма: приглашения, сброс пароля, служебные уведомления.

Где настраивать

• Настройки -> Администрирование -> SMTP (/settings/administration/platform/smtp)

Что сделать

1. Сохраните SMTP-настройки.
2. Отправьте тестовое письмо.
3. Проверьте журнал отправок на той же странице.

Готово, если

• тестовое письмо отправляется без ошибки;
• в журнале отправок письмо имеет статус Sent.

10. Аутентификация через внешних провайдеров

Когда нужен этот раздел

• Если клиенту нужен вход через Google или Yandex.

Где настраивать

• Настройки -> Администрирование -> Аутентификация (/settings/administration/access/auth)

Что сделать

1. Выберите нужный OAuth-провайдер.
2. Заполните clientId, clientSecret, callbackUrl.
3. Включите провайдер и сохраните настройки.

Готово, если

• на странице входа появился соответствующий OAuth-вариант;
• тестовый вход проходит успешно;
• локальный admin-вход остаётся рабочим резервным способом доступа.

Финальная smoke-check проверка

После завершения настройки выполните единый контрольный прогон:

1. Администратор входит в систему локальной учётной записью.
2. В системе существует хотя бы один рабочий workspace с владельцем и активным тарифом.
3. LLM-операция проходит успешно и использует рабочую модель.
4. В AI-модели активны нужные модели LLM, EMBEDDINGS и, при необходимости, ASR.
5. Тестовый документ индексируется без ошибки.
6. Тестовая транскрибация завершается успешно.
7. В workspace отображаются кредиты и тариф.
8. В Журнал списаний появляется первая запись после тестовых операций.
9. В Журнал блокировок нет неожиданных событий.
10. На /settings/administration/setup блоки Доступ и роли, LLM и модели, Базы знаний, Транскрибация находятся в статусе ready, если эти подсистемы входят в поставку.

Термины

• workspace — рабочее пространство клиента.
• tariff plan — тариф, который назначается workspace.
• tariff limit — отдельный лимит внутри тарифа.
• AI model — запись в едином реестре моделей Unica.
• providerModelKey — точный идентификатор модели у внешнего или внутреннего провайдера.
• creditsPerUnit — цена единицы потребления модели.
• ASR-провайдер — провайдер распознавания речи.
• файловый провайдер — файловый провайдер для загрузки и передачи файлов в смежные сервисы.