AI Platform DocsКорпоративные документы
Программа и методика испытаний ИС "Платформа ИИ"
ООО "ГК "Иннотех", домен Искусственный интеллект, 2026 г.
1. Общие положения
Продукт: Платформа ИИ
Версия: 2026.3.3
Дата: 2026-08-14
1.1. Назначение документа
Настоящий документ определяет программу и методика испытаний (ПМИ) кандидата на первую поставку Платформа ИИ 2026.3.3. ПМИ охватывает пользовательские тестовые кейсы для проверки основных сценариев использования пяти компонентов поставки:
- Agent Registry — каталог агентов;
- Low-code IDE — визуальный редактор Flow;
- Low-code Runtime — среда исполнения Flow;
- Platform RAG — сервис извлечения знаний;
- Memory Service — управляемый слой персистентной памяти.
1.2. Область применения
Испытания проводятся для подтверждения работоспособности пользовательских сценариев: создание агента в Low-code IDE, его публикация оператором, обнаружение в каталоге, поиск и вызов агента, а также использование сервисов Platform RAG и Memory Service.
1.3. Состав компонентов
| Компонент | Назначение |
|---|---|
| Low-code IDE | Создание, сохранение и проверка Flow агента (адаптированная LangFlow) |
| Low-code Runtime | Исполнение неизменяемого Flow через A2A и MCP |
| Agent Registry | Автоматическое обнаружение агентов, каталог, поиск с правами доступа |
| Platform RAG | Извлечение знаний: коллекции, приём документов, гибридный поиск |
| Memory Service | Персистентная память: извлечение фактов, поиск, CRUD, рабочая память сессий |
1.4. Роли пользователей
| Роль | Основная задача | Используемый компонент |
|---|---|---|
| Автор Low-code-агента | Создаёт, сохраняет и проверяет схему в визуальном редакторе | Low-code IDE |
| Пользователь каталога | Просматривает и ищет доступных агентов | Agent Registry |
| Потребитель агента | Вызывает выбранного агента по разрешённому интерфейсу | Platform Agent Gateway, Low-code Runtime |
| Владелец знаний | Управляет коллекциями RAG | Platform RAG, Platform SDK |
| Пользователь агента | Видит, что агент о нём помнит; редактирует и удаляет записи | Memory Service, T1GPT |
1.5. Предварительные условия
Для выполнения пользовательских тестовых кейсов необходимо:
- Развёрнутые среды с компонентами Платформа ИИ 2026.3.3;
- Действующие учётные записи с SSO-входом;
- Настроенные права доступа к рабочим областям;
- Готовый к использованию Agent Registry с обнаруженными агентами;
- Развёрнутый Low-code Runtime с хотя бы одним агентом;
- Доступ к Platform RAG и Memory Service.
2. Тестовые кейсы
2.1. Low-code IDE
ТК-001. Вход в Low-code IDE через SSO
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Low-code IDE | Авторизация пользователя | Вход через SSO | 1. Открыть адрес Low-code IDE, предоставленный администратором. 2. Ввести учётные данные через сервис SSO платформы. 3. Подтвердить вход. | Пользователь перенаправлен в Low-code IDE. Отображается разрешенная рабочая область и палитра компонентов. |
ТК-002. Создание нового Flow
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Low-code IDE | Создание Flow | Создание минимального Flow | 1. Открыть Low-code IDE. 2. Создать новый пустой рабочий Flow. 3. Задать понятное название и описание назначения агента. 4. Добавить компонент входа сообщения. 5. Добавить компонент PlatformLLM и выбрать разрешённый профиль модели.6. Соединить выход модели с компонентом ответа. 7. Проверить типы входных и выходных данных каждого соединения. | Flow создан. Все соединения валидны, типы данных совместимы. Компоненты доступны в палитре. |
ТК-003. Сохранение рабочей версии
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Low-code IDE | Сохранение версии | Сохранение Flow | 1. Открыть существующий Flow. 2. Ввести название, отражающее назначение агента. 3. Нажать «Сохранить». 4. Зафиксировать идентификатор, номер рабочей версии, время сохранения. | Рабочая версия сохранена. Возвращены: идентификатор, номер версии, время сохранения, применённая политика компонентов, версия Low-code IDE. |
ТК-004. Проверка Flow — успешный сценарий
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Low-code IDE | Проверка схемы | Успешная проверка | 1. Открыть сохранённый Flow. 2. Запустить серверную проверку. 3. Дождаться итогового состояния. | Проверка подтверждает: корректность структуры, наличие обязательных полей, соответствие политике компонентов, отсутствие секретов, совместимость с lfx, согласованность входных/выходных данных. Результат содержит версию проверяющего модуля, версию политики и SHA-256 исходных данных. |
ТК-005. Проверка Flow — запрещённый компонент
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Low-code IDE | Проверка схемы | Ошибка component_not_allowed | 1. Открыть Flow с компонентом, отсутствующим в действующей политике. 2. Запустить проверку. 3. Дождаться итогового состояния. | Проверка возвращает ошибку component_not_allowed. Схему нельзя передавать в Low-code Runtime. Необходимо удалить компонент или выбрать разрешённую платформенную замену. |
ТК-006. Проверка Flow — секрет в исходных данных
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Low-code IDE | Проверка схемы | Обнаружение секрета | 1. Вставить ключ API или токен в текстовое поле узла Flow. 2. Запустить проверку. | Проверка обнаруживает значение, похожее на секрет. Требуется удалить значение и использовать профиль Vault. |
ТК-007. Подготовка к передаче
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Low-code IDE | Подготовка артефактов | Формирование материалов поставки | 1. После успешной проверки экспортировать source.json (Flow).2. Сформировать manifest.json версии platform.low-code.publish-manifest/v1.3. Вычислить SHA-256 обоих файлов. 4. Зафиксировать версию проверяющего модуля и политики. | Материалы готовы к передаче оператору. Контрольные суммы зафиксированы. |
ТК-008. Проверка результата пользователем — обнаружение агента
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Agent Registry | Поиск агента | Нахождение агента в каталоге | 1. После сообщения оператора о готовности открыть Agent Registry. 2. Найти агента по названию и типу реализации low-code.3. Сравнить выбранную версию с переданной версией схемы. | Агент обнаружен. Версия совпадает с переданной. |
2.2. Agent Registry
ТК-010. Просмотр списка агентов
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Agent Registry | Просмотр списка | Получение списка разрешённых агентов | 1. Открыть Agent Registry (Swagger UI). 2. Нажать Authorize, выбрать oauth2Password, ввести логин и пароль.3. Выполнить GET /api/v1/agents?limit=20. | Возвращается страница разрешённых агентских записей. Каждая запись содержит безопасные сведения: название, версия, протокол, состояние, владелец. |
ТК-011. Фильтрация списка агентов
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Agent Registry | Фильтрация | Поиск по рабочему пространству и протоколу | 1. Выполнить GET /api/v1/agents?workspaceId=workspace-1&protocol=a2a&implementationType=low-code&limit=20. | Возвращаются агенты, соответствующие всем указанным фильтрам: рабочая область, протокол a2a, тип реализации low-code. |
ТК-012. Просмотр одной записи агента
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Agent Registry | Получение записи | Просмотр карточки агента | 1. Выполнить GET /api/v1/agents/{agentId} с валидным UUID.2. Проверить возвращаемые поля. | Возвращается безопасная карточка: имя, описание, идентификаторы агента и версии, владелец, рабочая область, состояние, протокол, тип реализации. Поле интерфейса вызова возвращается только при наличии права invoke. |
ТК-013. Поиск агентов — успешный сценарий
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Agent Registry | Гибридный поиск | Поиск по тексту | 1. Выполнить POST /api/v1/agents/search с текстом запроса, рабочей областью, фильтрами протокола и типа реализации.2. Указать topK. | Возвращаются разрешённые совпадения выше порога. Смысловая и лексическая оценки не обходят проверку SpiceDB. |
ТК-014. Поиск агентов — пустая выдача
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Agent Registry | Гибридный поиск | Отсутствие совпадений | 1. Выполнить POST /api/v1/agents/search с текстом запроса, для которого нет разрешённых агентов. | Возвращается HTTP 200 и пустой массив matches: []. |
ТК-015. Получение записи отсутствующего агента
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Agent Registry | Получение записи | Запрос к отсутствующему агенту | 1. Выполнить GET /api/v1/agents/{nonexistent-uuid}. | Возвращается HTTP 404. Системы не раскрывают, отсутствующий агент это или недоступный. |
ТК-016. Переход к вызову агента
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Agent Registry | Получение интерфейса вызова | Использование URL вызова | 1. Найти агента с полем интерфейса в Agent Registry. 2. Использовать URL без подмены узла, версии или пути. 3. Выполнить вызов через Platform Agent Gateway. | Platform Agent Gateway проверяет токен, связь маршрута и право на вызов agent#invoke. Вызов выполняется успешно при наличии прав. |
ТК-017. Состояния агента
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Agent Registry | Отображение состояний | Проверка состояний агентов | 1. Открыть список агентов. 2. Проверить отображение состояний: active, degraded, removed, rejected. | active — версия прошла проверку и может быть показана.degraded — агент существует, но нет пригодного эндпоинта.removed — агент подтверждённо удалён.rejected — карточка не прошла проверку. |
ТК-018. Ошибки Agent Registry
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Agent Registry | Обработка ошибок | Коды ошибок API | 1. Выполнить запрос с неверной формой (400/422). 2. Выполнить запрос без токена (401). 3. Выполнить запрос без права (403). 4. Выполнить запрос к отсутствующему агенту (404). 5. Превысить ограничение частоты (429). 6. Запросить при недоступной авторизации (503). | Возвращаются соответствующие HTTP-коды и структурированные ошибки с traceId. Тело ошибки не раскрывает токен, внутренний URL или карточки. |
2.3. Platform RAG
ТК-020. Создание коллекции
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Platform RAG | Управление коллекциями | Создание новой коллекции | 1. Выполнить POST /v1/collections с именем, профилем эмбеддинга, моделью ACL и стратегией чанкинга.2. Указать X-Tenant-Id и X-User-Id. | Возвращается HTTP 201 Created. Коллекция создана с уникальным collection_id, статус created. |
ТК-021. Просмотр коллекции
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Platform RAG | Управление коллекциями | Получение карточки коллекции | 1. Выполнить GET /v1/collections/{collection_id}.2. Проверить статус и параметры коллекции. | Возвращается HTTP 200. Статус коллекции — ready (после индексации первых документов). Отображаются doc_count и chunk_count. |
ТК-022. Приём документов
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Platform RAG | Приём документов | Отправка канонического документа | 1. Выполнить POST /v1/documents:submit с каноническим документом (содержимое, метаданные, ACL, хеш, ключ идемпотентности). | Возвращается HTTP 202 Accepted. Задание зарегистрировано со статусом PENDING. |
ТК-023. Проверка статуса задания приёма
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Platform RAG | Приём документов | Отслеживание статуса ingest | 1. Получить job_id из ответа приёма.2. Периодически запрашивать GET /v1/jobs/{job_id}.3. Дождаться перехода статуса в DONE. | Цепочка статусов: PENDING → RUNNING → DONE. После DONE документ доступен для поиска. |
ТК-024. Идемпотентность приёма
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Platform RAG | Приём документов | Повторная отправка с тем же хешем | 1. Повторно отправить документ с тем же content_hash и idempotency_key. | Возвращается статус DEDUPLICATED. Документ не дублируется. |
ТК-025. Гибридный поиск
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Platform RAG | Поиск | Гибридный запрос по коллекции | 1. Выполнить POST /v1/query с именем коллекции, текстом запроса, режимом hybrid.2. Указать top_k и rerank: true. | Возвращаются цитаты с doc_id, chunk_id, source_url, title, content, score. Результаты ранжированы по семантике и BM25 слиянием RRF. |
ТК-026. Фильтрация поиска по правам
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Platform RAG | Поиск | Поиск с ACL-фильтрацией | 1. Выполнить поиск от имени пользователя без прав на документ. 2. Сравнить результаты с поиском от имени пользователя с правом group:hr. | Пользователь без прав получает пустой items (или без закрытого документа). Пользователь с правами получает цитаты. |
ТК-027. Упаковка контекста
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Platform RAG | Поиск | Упаковка под бюджет токенов | 1. Выполнить POST /v1/retrieve_and_pack с token_budget. | Возвращается упакованный текстовый контекст, количество токенов, режим и массив цитат, вошедших в контекст. |
ТК-028. Переиндексация коллекции
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Platform RAG | Управление коллекциями | Запуск переиндексации | 1. Выполнить POST /v1/collections/{collection_id}:reindex. | Возвращается HTTP 202 Accepted. Новая версия индекса создаётся атомарно. Старая версия сохраняется до завершения. |
ТК-029. Пустой ACL в приватной коллекции
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Platform RAG | Приём документов | Документ без ACL | 1. Отправить документ с пустым acl в приватную коллекцию с политикой reject. | Возвращается HTTP 400 invalid_document. Документ отклонён. |
2.4. Memory Service
ТК-030. Подключение памяти к агенту — добавление памяти
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Memory Service | Запись памяти | Добавление фактов из диалога | 1. Выполнить POST /v1/memories с сообщениями диалога, agent_id, run_id.2. Указать infer: true. | Возвращается HTTP 202 Accepted с event_id и статусом PENDING. Извлечение фактов выполняется асинхронно. |
ТК-031. Проверка статуса события добавления
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Memory Service | Статус события | Ожидание завершения извлечения | 1. Получить event_id из ответа добавления.2. Периодически запрашивать GET /v1/events/{event_id}.3. Дождаться статуса SUCCEEDED. | Цепочка статусов: PENDING → SUCCEEDED. При SUCCEEDED возвращаются memory_ids. |
ТК-032. Поиск памяти
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Memory Service | Поиск памяти | Мультисигнальный поиск по фильтру | 1. Выполнить POST /v1/memories/search с запросом, фильтрами (scope + составные условия), top_k, token_budget. | Возвращаются ранжированные результаты с score, score_details (semantic, bm25), created_at. Результаты уложены в бюджет токенов. |
ТК-033. Список записей памяти
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценаря | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Memory Service | Список памяти | Получение списка по агенту | 1. Выполнить GET /v1/memories?agent_id={agent_id}&page_size=20. | Возвращается HTTP 200 с count и массивом записей (id, memory, скоупы, created_at). |
ТК-034. Получение одной записи
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Memory Service | Управление записями | Просмотр конкретной записи | 1. Выполнить GET /v1/memories/{memory_id}. | Возвращается HTTP 200 с полями: id, memory, user_id, agent_id, categories, hash, created_at, updated_at, role. |
ТК-035. Обновление записи памяти
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Memory Service | Управление записями | Изменение текста факта | 1. Выполнить PUT /v1/memories/{memory_id} с новым текстом. | Возвращается HTTP 200 с обновлённой записью. Изменения немедленно отражаются в поиске. |
ТК-036. Удаление записи памяти
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Memory Service | Управление записями | Soft-delete одной записи | 1. Выполнить DELETE /v1/memories/{memory_id}. | Возвращается HTTP 200 с сообщением «Memory deleted successfully». |
ТК-037. Право на забвение — удаление по фильтру
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Memory Service | Право на забвение | Удаление всех записей по фильтру | 1. Выполнить DELETE /v1/memories?agent_id={agent_id}.2. Проверить ответ. | Возвращается HTTP 200 с deleted_count и confirmation_id для аудита. Удаление необратимо. |
ТК-038. История изменений записи
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Memory Service | История записей | Просмотр журнала изменений | 1. Выполнить GET /v1/memories/{memory_id}/history. | Возвращается HTTP 200 и массив записей с событиями ADD, UPDATE, DELETE. |
ТК-039. Рабочая память сессии — сохранение
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Memory Service | Рабочая память сессии | Сохранение чекпоинта | 1. Выполнить POST /v1/sessions/{session_id}/state с состоянием и ttl_seconds. | Возвращается HTTP 200 с session_id, state, updated_at, ttl_remaining_seconds. |
ТК-040. Рабочая память сессии — восстановление
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Memory Service | Рабочая память сессии | Восстановление чекпоинта | 1. Выполнить GET /v1/sessions/{session_id}/state. | Возвращается HTTP 200 с восстановленным состоянием. При отсутствии — HTTP 404. |
ТК-041. Негативные проверки Memory Service
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Memory Service | Обработка ошибок | Отсутствие обязательных параметров | 1. Выполнить POST /v1/memories без agent_id и run_id.2. Выполнить GET /v1/memories без фильтров.3. Выполнить DELETE /v1/memories без фильтра.4. Запросить чужой user_id при delete.5. Запросить несуществующее событие. | 1. HTTP 400 — отсутствует скоуп.2. HTTP 400 — отсутствует скоуп.3. HTTP 400 — отсутствует фильтр.4. HTTP 403 Wrong user ID.5. HTTP 404. |
2.5. Сквозные пользовательские сценарии
ТК-050. Сквозной путь: создание агента и вызов
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Low-code IDE | Создание агента | Полный путь автора | 1. Войти в Low-code IDE через SSO. 2. Создать пустой Flow. 3. Добавить компонент входа, PlatformLLM, выход.4. Сохранить рабочую версию. 5. Запустить проверку. 6. Устранить все ошибки уровня error.7. Подготовить source.json, manifest.json, SHA-256. | Flow создан, сохранён и проверен. Материалы готовы к передаче. |
| 2 | Low-code Runtime | Развёртывание | Запуск агента оператором | 1. Оператор получает Flow и манифест. 2. Проверяет контрольные суммы. 3. Размещает артефакты в объектное хранилище. 4. Развертывает экземпляр в Kubernetes. 5. Дождается готовности Low-code Runtime. | Low-code Runtime переходит в состояние готовности. Карточка A2A соответствует манифесту. |
| 3 | Agent Registry | Обнаружение | Автоматическое обнаружение | 1. Agent Registry обнаруживает службу Low-code Runtime в Kubernetes. 2. Проверяет карточку агента. 3. Добавляет запись в каталог. | Агент появляется в каталоге со статусом active и типом реализации low-code. |
| 4 | Agent Registry | Поиск | Нахождение агента пользователем | 1. Пользователь открывает Agent Registry. 2. Находит агента по названию. 3. Проверяет наличие права на вызов. | Агент найден. Интерфейс вызова присутствует при наличии права. |
| 5 | Platform Agent Gateway | Вызов | Выполнение вызова агента | 1. Пользователь вызывает агента через Platform Agent Gateway. 2. Gateway проверяет токен и право agent#invoke.3. Заменяет токен на короткоживущее удостоверение. 4. Передаёт запрос в Low-code Runtime. | Вызов выполняется. Исходный токен не передаётся в Low-code Runtime. |
ТК-051. Сквозной путь: использование Platform RAG
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Platform RAG | Создание коллекции | Настройка базы знаний | 1. Создать коллекцию через Platform SDK или Control Plane. 2. Указать имя, профиль эмбеддинга, модель ACL, стратегию чанкинга. | Коллекция создана, статус created. |
| 2 | Platform RAG | Приём документов | Загрузка документов | 1. Отправить канонический документ через submit_documents.2. Дождаться статуса DONE. | Документ проиндексирован и доступен для поиска. |
| 3 | Platform RAG | Поиск | Запрос с цитатами | 1. Выполнить POST /v1/query с текстом запроса.2. Проверить наличие цитат (ссылки на источник). | Результаты содержат doc_id, chunk_id, source_url для проверки достоверности. |
| 4 | Platform RAG | Упаковка контекста | Передача в LLM | 1. Выполнить POST /v1/retrieve_and_pack с token_budget. | Возвращён упакованный контекст, укладывающийся в заданный бюджет токенов. |
ТК-052. Сквозной путь: использование Memory Service
| № | Модуль (компонент) | Функциональность | Название сценария | Действия – Шаги сценария | Ожидаемый результат |
|---|---|---|---|---|---|
| 1 | Memory Service | Добавление памяти | Сохранение фактов о пользователе | 1. Отправить ход диалога через POST /v1/memories.2. Дождаться статуса SUCCEEDED. | Факт извлечён, проведена дедупликация, проиндексирован. |
| 2 | Memory Service | Поиск памяти | Получение релевантных фактов | 1. Выполнить POST /v1/memories/search перед вызовом LLM.2. Проверить ранжирование и бюджет токенов. | Возвращены релевантные факты, ранжированные по семантике и BM25. |
| 3 | Memory Service | Управление записями | Редактирование факта | 1. Отредактировать запись через интерфейс T1GPT или API. 2. Проверить поиск после изменения. | Изменения немедленно отражаются в поиске. |
| 4 | Memory Service | Право на забвение | Удаление своих записей | 1. Пользователь открывает экран «Память агента» в T1GPT. 2. Просматривает записи. 3. Удаляет неверную запись. | Запись удалена. Возвращён confirmation_id для аудита. |
3. Правила проведения испытаний
3.1. Порядок выполнения
- Испытания проводятся в среде, идентичной целевой по составу компонентов и зависимостей.
- Каждый тестовый кейс выполняется последовательно. Пропуск предыдущего кейса допускается только с документированным обоснованием.
- Результат каждого кейса фиксируется как «Прошёл» или «Не прошёл» с указанием причины неудачи.
- При неудаче ключевого кейса (ТК-004, ТК-050) испытания приостанавливаются до устранения причины.
3.2. Критерии приёмки
Испытания считаются пройденными, если:
- Все тестовые кейсы из раздела 2 выполнены.
- Ключевые сценарии (ТК-001 — ТК-007, ТК-010 — ТК-018, ТК-020 — ТК-029, ТК-030 — ТК-041, ТК-050 — ТК-052) прошли успешно.
- Негативные проверки (ТК-005, ТК-006, ТК-029, ТК-041) подтверждают корректную обработку ошибок.
- Сквозные сценарии (ТК-050 — ТК-052) воспроизводят полный пользовательский путь.
3.3. Документирование результатов
Результаты испытаний оформляются в протоколе испытаний, содержащем:
- номер и название тестового кейса;
- дату и исполнителя;
- результат (прошёл / не прошёл);
- при неудаче — описание расхождения с ожидаемым результатом;
- ссылки на журналы и traceId.
4. Ограничения испытаний
Испытания версии 2026.3.3 проводятся с учётом известных ограничений:
- Семантический поиск не проверен на настоящих AI Gateway и OpenSearch — проверяется только совместимость интерфейсов.
- Agent Publisher отсутствует — деплой Low-code Flow выполняется вручную.
- Промышленная среда не реализована — испытания проводятся в средах разработки.
- Platform RAG и Memory Service поставляются как самостоятельные сервисы — интеграция с другими компонентами требует отдельной настройки.
- Автоматическая публикация из Low-code IDE недоступна.
- Промышленная готовность семантического поиска не подтверждена.
Приложение 1. Протокол испытаний
Испытания проведены объединенной комиссией в составе:
От Заказчика: [ФИО, должность]
От Исполнителя: [ФИО, должность]
Объект испытаний: Платформа ИИ
Выявленные замечания и отклонения
Если замечания в ходе испытаний отсутствуют, указывается: «Замечания в ходе испытаний не выявлены».
При наличии замечаний они фиксируются в данном разделе с указанием сценария, сущности отклонения и влияния на итоговую оценку.
Заключение
По результатам проведенных испытаний комиссия пришла к следующему выводу:
решение [рекомендуется / не рекомендуется] к приемке и дальнейшему внедрению.
Подписи сторон
От Заказчика: ___________________ / [Фамилия И.О.] /
От Исполнителя: ___________________ / [Фамилия И.О.] /