НАЧАЛО >> Документация модуля AI >> Руководство администратора модуля AI📄 Скачать в DOCX
Справочник по всем UI-страницам модуля, их полям, действиям, JSON-результатам, правам и опасным флагам находится в разделе ?id=Help/Show&m=AI/Help/Pages.
Общий контракт управляемых AI-операций, policy decision, ручного подтверждения, audit envelope, HealthCheck и TestA описан в разделе ?id=Help/Show&m=AI/Help/GovernanceCore. Для новых промышленных сценариев администратор должен проверять наличие опубликованной AI-операции, policy, feature flag, required permissions, Help и TestA-покрытия до включения сценария пользователям.
Профили входных данных AI, классы данных, source-level Security, masking/redaction, consent на внешнюю передачу и dry-run входного пакета описаны в разделе ?id=Help/Show&m=AI/Help/InputProfiles. Администратор должен включать AI-сценарий только после проверки профиля, field keys, внешней передачи, Help и TestA-покрытия.
AIEnabled - общий выключатель runtime. При включенном модуле runtime-запросы и read-only инструменты выполняются без диагностического флага с проверкой прав пользователя и политик сценария. При выключенном модуле допускаются только явно диагностические операции администратора.ExternalModelsEnabled - разрешение внешних моделей. Offline-политики и локальные сценарии не должны требовать облачного API.WriteToolsEnabled - разрешение write-инструментов. При включенном AIEnabled и WriteToolsEnabled AI-черновики создаются только при явном allowDraftWrite; запись в целевую БД требует отдельного подтверждения через ApplyDraft. При выключенном AIEnabled создание черновиков допускается только в диагностическом режиме администратора.TechnicalUserLogin - технический пользователь для фоновых AI-задач. Его права должны быть минимальными и проверяться политикой сценария.Частные аварийные выключатели настраиваются в АРМ Администратор в параметрах модуля AI: LocalModelsEnabled, AgentsEnabled, MemoryEnabled, RagEnabled, BatchEnabled, QueueToolsEnabled. Рядом с выключателем агентов находится кнопка "Консоль агентных сессий AI": она открывает эксплуатационную страницу AI/Agent в отдельном окне. В AI/GetStatus выключатели отображаются как localModels, agents, memory, rag, batch, queueTools и останавливают соответствующий контур до выполнения операции. Внешние модели и write-инструменты также отражаются в общем списке как externalModels и writeTools.
Инвариант записи данных: AI-инструменты не изменяют целевую ИРБИС-БД напрямую. Queue-инструменты ставят задачи в Queue, draft-инструменты сохраняют AI-черновик в AIDrafts, а фактическая запись библиографической записи возможна только через ApplyDraft после approved review, allowApply=true, проверки владельца, права EDIT и idempotency key.
Поставщики AI редактируются через служебный список записей модуля AIProvider, который открывается из настроек модуля AI в АРМ Администратор. Одна запись AIPROVIDER описывает один provider: идентификатор, тип, endpoint, признаки external/local/offline, capabilities, стоимость, runtime-параметры и требования к локальному запуску. Runtime настраивается интерфейсной таблицей параметров, а локальные требования - явными полями CPU, GPU, RAM, VRAM и свободного места на диске.
Модели AI редактируются отдельно через список записей модуля AIModel. Одна запись AIMODEL привязана к поставщику и хранит ID модели, название, включение, признаки external/local/offline, стоимость, качество, контекст, capabilities, требования к локальному запуску и параметры вызова. Это позволяет вести много моделей для одного поставщика без JSON-таблиц внутри записи AIPROVIDER. ProfilesJson.providers и вложенные providers.models сохраняются как fallback и формат экспорта старых конфигураций.
Инструменты AI редактируются через список записей модуля AITool. Одна запись AITOOL соответствует одному встроенному allowlist-инструменту и хранит включение, режим, права, лимиты, признак внешнего обращения, побочные эффекты, политику подтверждения и схемы входа/выхода. Кодовый реестр остается базовой allowlist и источником исполнителей, а записи AITOOL позволяют администратору управлять опубликованными инструментами без редактирования JSON.
Диагностика provider-профилей и маршрутизации моделей перенесена на страницу AI/Diagnostics. Она показывает текущие профили без раскрытия секретов, позволяет безопасно проверить provider и выполнить ResolveModel по JSON-запросу. Первый срез поддерживает:
mock - локальный диагностический поставщик без сетевых вызовов;ollama-local - локальный offline-профиль Ollama через OpenAI-compatible endpoint http://127.0.0.1:11434/v1;local-openai-compatible - локальный OpenAI-compatible endpoint;cloud-openai-compatible - внешний OpenAI-compatible endpoint, который нельзя использовать без политики внешней передачи данных и включенного ExternalModelsEnabled.Маршрутизатор учитывает capabilities, локальность, стоимость, качество, offline/external-флаги, preferred provider/model и политики local_first, cloud_first, free_first, low_cost_first, quality_first, offline_only, scenario_fixed.
Политика offline_only дополнительно проверяется методом AI::CheckOfflinePolicy. В этом режиме запрещены внешние модели и fallback во внешнюю модель, внешние инструменты и внешнее хранилище памяти. Нарушение возвращает AI_OFFLINE_POLICY_DENIED до обращения к provider adapter, исполнителю инструмента или записи памяти.
Если аварийный выключатель localModels=false или externalModels=false, маршрутизатор исключает соответствующие модели и показывает причину в fallback-chain.
OpenAI-compatible adapter выполняет HTTP-запрос только при явном allowNetwork=true. Без этого флага выбранный локальный или внешний endpoint возвращает управляемую ошибку AI_PROVIDER_NETWORK_DISABLED, что позволяет проверять маршрутизацию и политики без случайной отправки данных наружу.
Рабочие значения страницы AI/Ask задаются в АРМ Администратор в параметрах модуля AI, группа "Страница AI/Ask". Пользовательская форма показывает только Prompt; политика, System prompt, диагностический режим, dry-run, разрешение внешних моделей, fallback во внешние модели, сетевой вызов и показ технических деталей берутся из настроек модуля. Для штатной локальной проверки обычно используются "Политика по умолчанию" = local_first, выключенные "Диагностический режим по умолчанию", "Dry-run по умолчанию", "Разрешить внешние модели по умолчанию" и "Fallback во внешние по умолчанию", включенный "Сетевой вызов по умолчанию" и пустой "System prompt по умолчанию". Настройка "Показывать технические детали" по умолчанию выключена: пользовательская страница показывает ответ модели или понятное сообщение об ошибке, а полный JSON результата скрывается до явного включения этой настройки администратором.
Проверка поставщика через AI/TestProvider по умолчанию не выполняет сетевой вызов. При явном allowNetwork=true локальный OpenAI-compatible runtime проверяется через /models, а результат содержит доступность endpoint, время ответа и код ошибки, если локальный сервис не запущен или вернул некорректный ответ.
Перед вызовом внешней модели AI::Ask() классифицирует отправляемые данные через ClassifyData. Поддерживаются классы public, internal, service, personal, secret, forbidden. Политика задается интерфейсными полями модуля AI в группе "Политика внешней передачи данных"; при импорте/экспорте она отражается в ProfilesJson.dataPolicy. По умолчанию во внешнюю модель можно отправлять только public и только при явном externalDataApproved=true.
Если payload содержит секретные ключи или паттерны вида apiKey=..., token=..., password=..., класс повышается до secret, даже если пользователь указал dataClass=public. Внешний вызов при нарушении политики блокируется до обращения к provider adapter с ошибкой AI_EXTERNAL_DATA_POLICY_DENIED и audit-событием Runtime/externalDataPolicy.
Runtime-запросы и входы инструментов проходят первый срез защиты от prompt injection и tool injection. Явные маркеры переопределения инструкций, раскрытия system/developer prompt или директивы вызова инструментов блокируются до обращения к поставщику или исполнителю инструмента.
Вопрос по FT-документу передает фрагменты как недоверенные данные с явными границами. Системное правило запрещает выполнять инструкции, найденные внутри фрагментов документа; они используются только как источник фактов для ответа.
Основные угрозы для модуля AI:
Базовые меры защиты: маскирование секретов, запрет импорта секретов из backup, политика классов данных, явное подтверждение внешней передачи, аварийные выключатели, лимиты, allowlist инструментов, проверка прав на источник, audit trusted-only, AI-черновики, ручная проверка перед записью и инвалидирование производных данных по источнику. Остаточные риски первого среза: аппаратная проверка локальных моделей уже есть как контракт CheckLocalRuntimeHardware, но автообнаружение реального GPU/VRAM еще должно быть подключено к окружению установки; не все лимиты являются жесткими runtime-счетчиками.
Создание ИМИДЖ-черновика версии 5 выполняется через Queue и требует включенного QueueToolsEnabled. Пользовательский action проверяет права и подписывает DBN/MFN/версию/логин; worker принимает задачу только в Queue-контексте, повторно проверяет HMAC и версию, а готовое review-окно открывается отдельным action под пользовательской сессией. Обычные повторные клики дедуплицируются, forceNew=true всегда создает отдельную задачу.
Для локальных runtime профили provider/model могут задавать требования к локальному запуску: CPU, режим GPU, минимум RAM, минимум VRAM и свободное место на диске. В API эти поля соответствуют cpu, gpuRequired, gpuOptional, minRamGb, minVramGb, minDiskGb. Требования поставщика редактируются в записи AIPROVIDER, требования конкретной модели - в записи AIMODEL. Проверка выполняется через AI/CheckLocalRuntimeHardware и возвращает статус compatible, warning или incompatible без сетевого вызова к модели.
Все инструменты вызываются через allowlist и единый pipeline InvokeTool: schema gate, проверка прав, политика, аудит, исполнение. Настройка инструментов выполняется через модуль AITool в АРМ Администратор. В карточке инструмента есть кнопка диагностического запуска: она открывает AI/Tools с параметром toolId, строит форму по inputSchema и выводит результат вызова после отправки.
Инструменты с побочными эффектами требуют отдельной политики и подтверждения. Прямое изменение целевой БД запрещено: сначала создается AI-черновик, затем review-задача, затем подтвержденное применение.
Долгие FT-операции (ft.prepareDocument, ft.ocr, ft.transcribe) ставятся в штатную очередь Queue. Для их запуска требуется явный флаг allowQueueTask=true; при выключенном AIEnabled допустим только диагностический запуск администратором. Статус задачи проверяется инструментом queue.getProgress по числовому id задачи.
Текстовый runtime-запрос выполняется через AI/Ask: сначала выбирается модель через маршрутизатор, затем вызывается provider adapter. При включенном AIEnabled запрос выполняется штатно без diagnosticExecution; при выключенном AIEnabled разрешен только диагностический запуск администратором. Mock provider не выполняет сетевой вызов.
Вопрос по FT-документу выполняется встроенным виджетом просмотрщика FT/ShowFT через action AI/AskDocument и метод AI::AskDocument(). Виджет показывается только при включенном модуле AI и разрешенном пользователю runtime-доступе. Метод не читает SID-хранилище напрямую, а вызывает allowlist-инструмент ft.getText, поэтому сохраняются проверки прав на модуль FT, запись полного текста, политика инструмента и аудит. Если подготовленный FT/idx.txt отсутствует, постановка подготовки в очередь возможна только после отдельного пользовательского подтверждения, которое передает allowQueueTask=true.
Semantic search выполняется инструментом rag.semanticSearch. Диагностический первый срез строит локальный индекс без внешней модели для Help-страницы и подготовленного FT-документа. Для FT-источника индекс строится через ft.getText, учитывает chunkingProfile, может включать координаты из FT/Paged/coord/fullNNNNN.txt и сохраняет их в metadata chunk. Перед выдачей результата RAG повторно проверяет право VIEW на источник.
Prompt-шаблоны хранятся и редактируются как записи AIPrompt через АРМ Администратор. Раздел ProfilesJson.prompts остается совместимым источником для старых конфигураций, импорта и экспорта; при штатной настройке продуктивным источником являются записи AIPROMPT. Разделы ProfilesJson.scenarioVersions и ProfilesJson.agentProfiles по-прежнему версионируются через schemaVersion и items, чтобы фиксировать, какой prompt и какой mapping-профиль использовались при создании AI-черновика или агентного шага.
Агентные сценарии выполняются через AI_AgentService: сессия хранит цель, выбранный сценарий, модель, шаги, статус и память. Первый прикладной сценарий imageCatalog.toBibDraft создает AI-черновик и review-задачу, после чего переводит сессию в состояние ожидания ручной проверки. Агентный шаг не применяет запись к целевой БД напрямую.
Память агента хранится локально в AIAgentMemory, имеет область (request или session), TTL, владельца и ссылку на источник. Перед записью и чтением памяти проверяются права на Help/FT/record-источник; внешнее хранилище памяти запрещено для offline_only и блокируется политикой.
Первый срез рассчитан на безопасную приемку: mock provider не выполняет сетевой вызов, OpenAI-compatible endpoint требует явного allowNetwork=true, write-инструменты требуют явного подтверждения. Acceptance проверяет как ApplyDraft dryRun, так и фактическое дополнение временной ИМИДЖ-записи после approval с сохранением исходных полей, идемпотентным повтором и cleanup. Диагностический запуск при выключенном AIEnabled доступен только администратору и не должен становиться продуктивным режимом.
Локальные модели проверяются отдельно от облачных: profile может пометить provider/model как local, offline, external=false, задать аппаратные требования и порядок fallback. Если локальный runtime недоступен, сценарий должен возвращать управляемую ошибку или следовать явно разрешенной fallback-политике; автоматический переход в облако для offline_only запрещен.
AI-события записываются во внутренний журнал AIToolAudit на записи модуля AI. Запись событий разрешена только доверенным компонентам модуля: runtime, маршрутизатору моделей, tool pipeline, agent/review/draft-сервисам. Внешний вызов AI/AuditEvent не принимает пользовательские события.
Администратор может читать журнал через AI/ListAuditEvents и страницу AI/Diagnostics. Отчет поддерживает фильтры по пользователю, компоненту, типу события, инструменту, результату, коду ошибки и времени. Детали событий маскируются так же, как настройки поставщиков и секреты.
Для контроля внешней передачи данных используется AI/ListExternalTransfers и отдельный блок на странице AI/Diagnostics. Отчет строится по audit-журналу, показывает попытки передачи во внешние модели, класс данных, причины блокировки, provider/model и размеры prompt/answer без раскрытия секретов.
Эксплуатационные изменения также пишутся в AIToolAudit: AI/EnsureSchema фиксирует Maintenance/schema.ensure, AI/RotateSecret фиксирует Maintenance/secret.rotate, AI/UpdateEmergencySwitches фиксирует Maintenance/emergency.update, AI/InvalidateDerivedData фиксирует Maintenance/derived.invalidate. Значения секретов в ответах и audit не возвращаются.
Хранилища модуля создаются и обновляются через AI/EnsureSchema. Операцию можно выполнять повторно: она инициализирует SID SQLite-хранилища AIToolAudit, AIDrafts, AIAgentSessions, AIAgentSteps, AIAgentMemory, AIReviewTasks, AIEmbeddingChunks, AIToolCallCounters, AIToolConcurrencyLocks и сохраняет текущую версию схемы в записи модуля.
Статус схемы отображается в AI/GetStatus в блоке schema: текущая версия, целевая версия, количество зарегистрированных хранилищ и наличие записи модуля.
Структуру ProfilesJson можно получить через AI/GetProfileSchema. Ответ содержит версию схемы, место хранения настроек AI.ProfilesJson, место хранения секретов AI.SecretsJson, место хранения технического пользователя AI.TechnicalUserLogin, описание разделов и безопасные значения по умолчанию.
Prompt-шаблоны должны добавляться через записи AIPrompt, а не через ручное редактирование JSON или код страниц. Раздел ProfilesJson.prompts сохраняется как совместимый формат импорта/экспорта; остальные версионируемые разделы agentProfiles, scenarioVersions, mappingProfiles, toolPolicies и toolSchemas остаются в профильной структуре AI::GetProfileSchema() и хранят schemaVersion и items.
Дефолтный профиль версии 7 mappingProfiles.items.imageCatalog.default описывает сценарий imageCatalog.toBibDraft: источник и цель — одна запись в БД IMAGE, первичный текст берется из всех повторений и подполей 22, дата IMAGE-записи из поля 24 используется лишь как слабый временной prior, путь изображения — из 952^b/952^B/952^*. Перед классификацией imageCatalog.reconstruction.v1 согласует до шести дедуплицированных OCR-кандидатов: 22, координатный 953 и последние принятые OCR-артефакты. Сервер отклоняет строки без корректных sourceRefs или достаточного покрытия. Число из вторичного артефакта принимается только при подтверждении 22/953 либо еще одним независимым кандидатом; это же правило применяется к числовым библиографическим полям. Реконструкция не записывается в 22; она хранится в черновике вместе с audit. Рабочий лист определяется из allowlist PAZK, PVK, SPEC, ASP, NJ, AUNTD, MUSP; SPEC не используется без признака тома или выпуска, а диапазон страниц библиографии не считается признаком ASP. Локальный offline_only pipeline использует prompt-профили imageCatalog.classification.v7, imageCatalog.extraction.v7, imageCatalog.verification.v7, типозависимую схему, ближайшие проверенные примеры и обязательную позиционную evidence validation по исходным OCR-кандидатам. Дополнительный локальный профиль Resources/bibliographic-abbreviations.json учитывает ГОСТ Р 7.0.12-2011, ГОСТ 7.11-2004 и исторические ГОСТ 7.12-93/7.12-77: корректная полная форма модели сохраняется, если сокращенный rawEvidence подтверждает ее несколькими независимыми якорями; один общий акроним недостаточен. Каждый скаляр содержит confidence, rawEvidence, evidenceCandidateId, зону и строки. Помимо заглавия, авторов, публикации и объема извлекаются ответственность, параллельное заглавие, издание, физические характеристики, серия, ISBN/ISSN, цена, тираж, переплет, примечания, классификационные индексы и связи многотомного/аналитического описания. Первый автор записывается в неповторяемое 700, остальные — в 701, участники — в 702, коллективы — в 710/711. Обязательные поля заданы отдельно для каждого рабочего листа; checksum ISBN/ISSN, согласованность публикационной зоны и конфликт ролей превращаются в issues. Поля 22, 24, 952, 953 и уже заполненные библиографические значения сохраняются.
Рабочие нормативные конспекты и ссылки на официальные источники находятся в разделе Нормативные ориентиры.
В этом же профиле задаются duplicateKeys и duplicateRules. Правило imageCatalog.titleAuthorByType выполняет read-only поиск по заглавию/автору и подставляет в фильтр V= фактически определенный рабочий лист. Оно проверяет права VIEW на найденные записи и возвращает кандидатов в duplicateCheck.scenarioRules; слияние или создание дублетных записей не выполняется.
Неверсионируемые эксплуатационные разделы: providers, models, limits, dataPolicy, emergencySwitches, memory, rag, localRuntime, askPage. Для поставщиков продуктивным источником являются записи AIProvider; для моделей - записи AIModel; для prompt-шаблонов - записи AIPrompt; для инструментов - записи AITool; для лимитов, политики данных, памяти, RAG, локальной среды, аварийных выключателей и дефолтов страницы AI/Ask - отдельные интерфейсные параметры модуля AI. Соответствующие разделы ProfilesJson сохраняются для совместимости старых конфигураций, импорта и экспорта.
Технический пользователь задается полем TechnicalUserLogin в настройках модуля. Он предназначен для фоновых AI-задач и должен получать минимальные права на конкретные БД, FT-объекты и страницы; сценарии не должны расширять его права за счет agent-профиля или prompt.
Если исходный объект изменен, закрыт правами или должен быть исключен из AI-контекста, администратор запускает AI/InvalidateDerivedData. Операция принимает источник help, ft или record, помечает соответствующие строки AIEmbeddingChunks как stale=1, переводит связанную память агента в статус invalidated и пишет audit-событие Maintenance/derived.invalidate.
Для изменения прав источника указывайте reason=rightsChanged. Ответ содержит rebuildPolicy: blocksServingStaleChunks=true, postRightsCheckRequired=true, rebuildRequired=true при наличии инвалидированных данных и queueRecommended=true для последующего административного или фонового перестроения индекса после проверки прав.
Операцию можно выполнить через API или через форму на странице AI/Diagnostics. Регламент эксплуатации: после изменения прав на Help-страницу, FT-документ или запись БД нужно инвалидировать производные данные этого источника до следующего продуктивного AI-сценария. RAG не возвращает stale-чанки, а GetAgentSession не возвращает память со статусом invalidated; физическое удаление можно выполнять отдельной регламентной процедурой после проверки журналов.
Администратор может выгрузить конфигурацию через AI/ExportConfiguration. Экспорт содержит эффективный профиль, включая значения интерфейсных полей модуля AI, версию формата и статус схемы, но не содержит SecretsJson и не раскрывает значения ключей, токенов и паролей.
Импорт выполняется через AI/ImportConfiguration. Секреты из импортируемого файла не принимаются: реальные значения в секретных полях отбрасываются, а существующий локальный секрет сохраняется только при маске ***. После переноса конфигурации секреты поставщиков нужно задать в настройках конкретной инсталляции.
Для ротации отдельного секрета используется AI/RotateSecret с путем секретного поля, например providers.cloud-openai-compatible.apiKey. Операция заменяет значение в SecretsJson, не меняя публичный профиль с маской ***, и пишет событие Maintenance/secret.rotate.
Лимиты задаются в АРМ Администратор в настройках модуля AI, группа "Лимиты выполнения AI". При импорте/экспорте они отражаются в ProfilesJson.limits. Эффективные значения видны на странице AI/Diagnostics. Первый срез применяет:
maxPromptChars и maxSystemChars для runtime-запросов;maxTokens для ограничения параметра ответа;maxModelCostLevel для запрета слишком дорогой выбранной модели;maxAgentSteps для остановки агентной сессии до выполнения следующего шага.maxToolCallsPerStep для ограничения числа фактических вызовов инструментов в рамках одного агентного шага.maxToolInputBytes для ограничения размера входного JSON инструмента;maxFileBytes для ограничения размера передаваемого инструменту файлового или текстового payload;maxToolExecutionSeconds для отказа при исчерпанном бюджете времени операции;maxConcurrentToolCalls для ограничения числа параллельных вызовов инструментов в одном контексте.При нарушении лимита AI::Ask() возвращает управляемые ошибки AI_LIMIT_PROMPT_CHARS, AI_LIMIT_SYSTEM_CHARS, AI_LIMIT_MAX_TOKENS или AI_LIMIT_MODEL_COST до вызова поставщика. Агентная сессия при превышении maxAgentSteps переводится в limit_exceeded с ошибкой AI_LIMIT_AGENT_STEPS. Tool pipeline до выполнения инструмента возвращает AI_LIMIT_TOOL_CALLS, AI_LIMIT_TOOL_INPUT_BYTES, AI_LIMIT_FILE_BYTES, AI_LIMIT_TOOL_TIME или AI_LIMIT_TOOL_PARALLELISM.
UI-страницы находятся в modules/AI/Pages. PAGE-записи создаются через AI/EnsurePages. Для каждой страницы используется id вида AI/<Name>: права, название и положение в дереве берутся из PAGE-записи, а исполняемый код загружается из файла modules/AI/Pages/<Name>.page.
AI/Ask;AI/Diagnostics;AI/Reviews.AI/AskDocument и AI/ImageCatalog не являются PAGE-страницами. Пользовательский вход для вопроса по документу расположен в FT/ShowFT, а ИМИДЖ-сценарий запускается подписанной кнопкой "AI-черновик" выбранной записи в АРМ Каталогизатор и продолжается в модальном ExtJS-окне текущей операции. AI/EnsurePages удаляет старые PAGE-записи этих технических интерфейсов, если они существовали.
Отдельные диагностические и эксплуатационные страницы также регистрируются как PAGE-записи, но не показываются в общей навигации рабочих AI-страниц:
AI/Tools открывается из карточки записи AITool кнопкой диагностического запуска;AI/Agent открывается из настроек модуля AI кнопкой "Консоль агентных сессий AI".AI/EnsurePages создает записи без привязки к pidm/pida, чтобы Pages/Show подключал файл страницы по id. Для административных страниц задается право VIEW для SITESPEC/ADMIN; изменение состава доступных ролей должно выполняться через права PAGE-записей, а не через проверку внутри файла страницы.