Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1069999
Тема сообщения
ПОЛНОСТЬЮ УПРОСТИТЬ ПРОГРАММНУЮ ЧАСТЬ И УБРАТЬ ПРИВЯЗКУ К КОНКРЕТНОМУ AI-СТЕКУ
Тип сообщения
Замечание к КД
Поставщик
Товарищество с ограниченной ответственностью "SilkTech"
Представитель поставщика
ОМИРБЕКОВ САЙЛАУ ЖАКЫПБЕКОВИЧ
Дата и время отправки сообщения
2026-10-09 00:15:16
Текст сообщения
1. Просим существенно упростить раздел технической спецификации, посвященный программной архитектуре комплекса.
2. Техническая спецификация должна описывать необходимые пользователю функции, а не предписывать разработчику и поставщику внутреннее устройство программной системы.
3. В текущей редакции ТС устанавливает конкретную архитектуру локального AI-инференса.
4. Требуется специализированный сервис или фреймворк локального инференса.
5. Должно поддерживаться квантование весов 4-bit, 8-bit и 16-bit.
6. Должно обеспечиваться оптимизированное распределение слоев модели между GPU и оперативной памятью.
7. Далее требуется открытая мультиязычная языковая модель размером 14B–32B параметров.
8. Отдельно требуются модели компьютерного зрения.
9. Модели генерации графического контента.
10. Семантический векторный поиск.
11. Специализированный брокер сообщений.
12. Очереди выполнения задач.
13. Реляционная СУБД промышленного уровня.
14. Векторное расширение или отдельная векторная база данных.
15. Такая совокупность требований представляет собой техническую архитектуру конкретного программного комплекса.
16. Для Заказчика не имеет значения, используется ли внутри системы отдельный message broker, встроенная очередь задач либо иной механизм диспетчеризации.
17. Пользователю необходим результат: при высокой нагрузке задания не должны теряться, а пользователи не должны терять свои сессии.
18. Следовательно, необходимо установить именно данный функциональный результат.
19. Внутреннее средство его достижения должно определяться разработчиком.
20. То же относится к векторной базе данных.
21. Семантический поиск может быть реализован отдельной vector DB.
22. Может быть реализован расширением обычной СУБД.
23. Может использовать встроенный поисковый индекс.
24. Может применяться иной технический механизм.
25. Все варианты функционально допустимы.
26. Поэтому из ТС следует исключить требования к конкретному классу СУБД и внутренней архитектуре хранения.
27. Достаточно потребовать хранение учетных записей, истории, учебных материалов, результатов, проектов и возможность быстрого поиска.
28. Аналогично не следует обязательно требовать конкретные варианты квантования 4/8/16 bit.
29. Это внутренняя оптимизация модели.
30. Различные современные inference-движки могут использовать 2-bit, 3-bit, 4-bit, 5-bit, 6-bit, 8-bit, FP8, FP16, BF16 либо смешанные режимы.
31. Если результат соответствует требованиям по качеству и скорости, поставщик не должен быть ограничен конкретным форматом.
32. Просим заменить данный параметр требованием обеспечить локальную работу модели в установленном объеме памяти с приемлемой скоростью.
33. Также необходимо пересмотреть требование к размеру основной LLM 14B–32B параметров.
34. Количество параметров не является прямым показателем качества модели.
35. Современная модель на 8B параметров может превосходить более старую модель на 14B.
36. Mixture-of-Experts модели также имеют иное соотношение общего и активного числа параметров.
37. Поэтому диапазон 14B–32B способен исключить более новые и эффективные модели.
38. Для учебного процесса важны качество русского и казахского языка, генерация программного кода, соблюдение системных инструкций, возможность объяснения материала и локальная работа.
39. Именно эти функции следует сделать обязательными.
40. Количество параметров сделать ориентировочным либо полностью исключить.
41. Особо важно исключить любую скрытую привязку к конкретной модели LLM.
42. ТС должна прямо допускать различные открытые и коммерческие модели при условии законного использования и локального исполнения.
43. Просим также разрешить замену AI-моделей на более современные в течение срока эксплуатации комплекса.
44. Если жестко закрепить архитектуру и размер модели, комплекс быстро устареет.
45. В сфере AI модели меняются значительно быстрее традиционного оборудования.
46. Программная платформа должна быть обновляемой.
47. Следующий излишне конкретный блок — семь предустановленных учебно-методических модулей.
48. Модули называются «Основы искусственного интеллекта», «Инженерия промптов», «Разработка ПО с ИИ», «Интеллектуальные агенты», «Компьютерное зрение», «Генеративные медиа», «Анализ документов».
49. Сами образовательные направления разумны.
50. Однако не следует требовать точных названий модулей либо определенного внутреннего деления продукта.
51. Альтернативная платформа может объединить несколько тем в один курс.
52. Может, наоборот, разбить одну тему на несколько курсов.
53. Это не влияет на образовательный результат.
54. Просим определить перечень изучаемых компетенций и разрешить любую структуру курсов.
55. Необходимо оставить: основы нейронных сетей, работа с запросами, использование AI при программировании, автоматизация, компьютерное зрение, генерация контента и анализ документов.
56. Количество внутренних программных модулей поставщик должен определять самостоятельно.
57. Аналогично личный кабинет учащегося не должен быть привязан к конкретному интерфейсу.
58. Необходимо оставить:
- персональную авторизацию;
- сохранение проектов;
- историю работы;
- доступ к заданиям;
- возможность программирования;
- хранение файлов;
- отображение прогресса.
59. Неважно, называются ли элементы интерфейса «песочница», «файловый менеджер», «проект» либо иначе.
60. Кабинет преподавателя также необходимо определять функционально.
61. Учитель должен управлять пользователями и группами.
62. Назначать задания.
63. Видеть прогресс.
64. Контролировать активность.
65. При необходимости выводить работу пользователя на общий экран.
66. Реализация функций может различаться.
67. Далее просим пересмотреть требование полного восстановления программного контура из резервной копии не более чем за 2 часа.
68. Необходимо указать объем исходных данных, относительно которого действует двухчасовой показатель.
69. Восстановление 50 ГБ и 4 ТБ резервной копии объективно занимает различное время.
70. Более корректно установить RTO и RPO при определенном контрольном объеме.
71. Если Заказчик не располагает конкретным расчетом, просим использовать более общий показатель.
72. Например, возможность восстановления системы из актуальной резервной копии.
73. Также следует исключить обязательную ежедневную инкрементную схему, если альтернативная система выполняет ежедневную полную, дифференциальную или snapshot-копию и обеспечивает не худший результат.
74. Вид резервного копирования является технологическим решением.
75. Заказчику необходимы сохранность данных и возможность восстановления.
76. Отдельный вопрос — программное обеспечение для онлайн-обучения.
77. Требуется не менее семи лицензий.
78. Функции включают мгновенное создание уроков без предварительной регистрации или планирования, видеозвонки, демонстрацию экрана, чат, управление занятиями, создание, редактирование и планирование.
79. Просим сформулировать данный раздел без признаков конкретной коммуникационной платформы.
80. Достаточно указать функции онлайн-видеосвязи, демонстрации экрана, группового чата и планирования.
81. Следует допустить веб-сервис, локальное ПО либо иное лицензионное решение.
82. Не нужно предписывать точный пользовательский сценарий создания конференции.
83. Также необходимо уточнить срок лицензий.
84. В ТС указано количество лицензий, но не указан срок их действия.
85. Если подписка должна быть годовой, трехлетней либо бессрочной, это должно быть определено заранее.
86. Цена такого ПО существенно зависит от срока.
87. Просим установить минимальный срок лицензии.
88. В целом предлагаем заменить весь раздел внутренней архитектуры программного комплекса коротким функциональным перечнем.
89. Система должна:
- работать локально без обязательного внешнего облака;
- обеспечивать не менее 14 ученических учетных записей;
- поддерживать русский, казахский и желательно английский язык;
- обеспечивать локального AI-ассистента;
- поддерживать программирование;
- компьютерное зрение;
- генерацию материалов;
- анализ документов;
- хранение проектов;
- управление пользователями;
- учет прогресса;
- резервное копирование;
- возможность восстановления;
- работу через веб-браузер.
90. Все остальные внутренние компоненты необходимо оставить на усмотрение разработчика/поставщика.
91. Это позволит предложить открытые программные решения, отечественные разработки и альтернативные коммерческие платформы.
92. В текущей редакции потенциальному поставщику фактически необходимо воспроизвести конкретный AI-стек Заказчика.
93. Это неоправданно сужает конкуренцию.
94. Особенно с учетом быстрого развития технологий искусственного интеллекта.
95. ТС должна допускать решения, которые являются более современными на дату поставки.
96. Просим прямо установить, что отличия названий программных компонентов, моделей, СУБД, framework, inference engine, message broker и внутренней архитектуры не являются несоответствием при обеспечении требуемых функций.
97. Просим также исключить необходимость использовать платформенные технологии конкретного производителя оборудования.
98. Операционная среда должна быть любой стабильной, поддерживаемой и совместимой с предлагаемым оборудованием.
99. Необходимо допустить Linux, Unix-подобные и иные серверные операционные системы при обеспечении требуемых функций.
100. Просим увеличить срок поставки с 15 до минимум 30 календарных дней, поскольку поставщику необходимо не только поставить оборудование, но и развернуть сложный локальный программный комплекс, создать учетные записи, настроить AI-модели, резервное копирование и сетевую инфраструктуру.
2. Техническая спецификация должна описывать необходимые пользователю функции, а не предписывать разработчику и поставщику внутреннее устройство программной системы.
3. В текущей редакции ТС устанавливает конкретную архитектуру локального AI-инференса.
4. Требуется специализированный сервис или фреймворк локального инференса.
5. Должно поддерживаться квантование весов 4-bit, 8-bit и 16-bit.
6. Должно обеспечиваться оптимизированное распределение слоев модели между GPU и оперативной памятью.
7. Далее требуется открытая мультиязычная языковая модель размером 14B–32B параметров.
8. Отдельно требуются модели компьютерного зрения.
9. Модели генерации графического контента.
10. Семантический векторный поиск.
11. Специализированный брокер сообщений.
12. Очереди выполнения задач.
13. Реляционная СУБД промышленного уровня.
14. Векторное расширение или отдельная векторная база данных.
15. Такая совокупность требований представляет собой техническую архитектуру конкретного программного комплекса.
16. Для Заказчика не имеет значения, используется ли внутри системы отдельный message broker, встроенная очередь задач либо иной механизм диспетчеризации.
17. Пользователю необходим результат: при высокой нагрузке задания не должны теряться, а пользователи не должны терять свои сессии.
18. Следовательно, необходимо установить именно данный функциональный результат.
19. Внутреннее средство его достижения должно определяться разработчиком.
20. То же относится к векторной базе данных.
21. Семантический поиск может быть реализован отдельной vector DB.
22. Может быть реализован расширением обычной СУБД.
23. Может использовать встроенный поисковый индекс.
24. Может применяться иной технический механизм.
25. Все варианты функционально допустимы.
26. Поэтому из ТС следует исключить требования к конкретному классу СУБД и внутренней архитектуре хранения.
27. Достаточно потребовать хранение учетных записей, истории, учебных материалов, результатов, проектов и возможность быстрого поиска.
28. Аналогично не следует обязательно требовать конкретные варианты квантования 4/8/16 bit.
29. Это внутренняя оптимизация модели.
30. Различные современные inference-движки могут использовать 2-bit, 3-bit, 4-bit, 5-bit, 6-bit, 8-bit, FP8, FP16, BF16 либо смешанные режимы.
31. Если результат соответствует требованиям по качеству и скорости, поставщик не должен быть ограничен конкретным форматом.
32. Просим заменить данный параметр требованием обеспечить локальную работу модели в установленном объеме памяти с приемлемой скоростью.
33. Также необходимо пересмотреть требование к размеру основной LLM 14B–32B параметров.
34. Количество параметров не является прямым показателем качества модели.
35. Современная модель на 8B параметров может превосходить более старую модель на 14B.
36. Mixture-of-Experts модели также имеют иное соотношение общего и активного числа параметров.
37. Поэтому диапазон 14B–32B способен исключить более новые и эффективные модели.
38. Для учебного процесса важны качество русского и казахского языка, генерация программного кода, соблюдение системных инструкций, возможность объяснения материала и локальная работа.
39. Именно эти функции следует сделать обязательными.
40. Количество параметров сделать ориентировочным либо полностью исключить.
41. Особо важно исключить любую скрытую привязку к конкретной модели LLM.
42. ТС должна прямо допускать различные открытые и коммерческие модели при условии законного использования и локального исполнения.
43. Просим также разрешить замену AI-моделей на более современные в течение срока эксплуатации комплекса.
44. Если жестко закрепить архитектуру и размер модели, комплекс быстро устареет.
45. В сфере AI модели меняются значительно быстрее традиционного оборудования.
46. Программная платформа должна быть обновляемой.
47. Следующий излишне конкретный блок — семь предустановленных учебно-методических модулей.
48. Модули называются «Основы искусственного интеллекта», «Инженерия промптов», «Разработка ПО с ИИ», «Интеллектуальные агенты», «Компьютерное зрение», «Генеративные медиа», «Анализ документов».
49. Сами образовательные направления разумны.
50. Однако не следует требовать точных названий модулей либо определенного внутреннего деления продукта.
51. Альтернативная платформа может объединить несколько тем в один курс.
52. Может, наоборот, разбить одну тему на несколько курсов.
53. Это не влияет на образовательный результат.
54. Просим определить перечень изучаемых компетенций и разрешить любую структуру курсов.
55. Необходимо оставить: основы нейронных сетей, работа с запросами, использование AI при программировании, автоматизация, компьютерное зрение, генерация контента и анализ документов.
56. Количество внутренних программных модулей поставщик должен определять самостоятельно.
57. Аналогично личный кабинет учащегося не должен быть привязан к конкретному интерфейсу.
58. Необходимо оставить:
- персональную авторизацию;
- сохранение проектов;
- историю работы;
- доступ к заданиям;
- возможность программирования;
- хранение файлов;
- отображение прогресса.
59. Неважно, называются ли элементы интерфейса «песочница», «файловый менеджер», «проект» либо иначе.
60. Кабинет преподавателя также необходимо определять функционально.
61. Учитель должен управлять пользователями и группами.
62. Назначать задания.
63. Видеть прогресс.
64. Контролировать активность.
65. При необходимости выводить работу пользователя на общий экран.
66. Реализация функций может различаться.
67. Далее просим пересмотреть требование полного восстановления программного контура из резервной копии не более чем за 2 часа.
68. Необходимо указать объем исходных данных, относительно которого действует двухчасовой показатель.
69. Восстановление 50 ГБ и 4 ТБ резервной копии объективно занимает различное время.
70. Более корректно установить RTO и RPO при определенном контрольном объеме.
71. Если Заказчик не располагает конкретным расчетом, просим использовать более общий показатель.
72. Например, возможность восстановления системы из актуальной резервной копии.
73. Также следует исключить обязательную ежедневную инкрементную схему, если альтернативная система выполняет ежедневную полную, дифференциальную или snapshot-копию и обеспечивает не худший результат.
74. Вид резервного копирования является технологическим решением.
75. Заказчику необходимы сохранность данных и возможность восстановления.
76. Отдельный вопрос — программное обеспечение для онлайн-обучения.
77. Требуется не менее семи лицензий.
78. Функции включают мгновенное создание уроков без предварительной регистрации или планирования, видеозвонки, демонстрацию экрана, чат, управление занятиями, создание, редактирование и планирование.
79. Просим сформулировать данный раздел без признаков конкретной коммуникационной платформы.
80. Достаточно указать функции онлайн-видеосвязи, демонстрации экрана, группового чата и планирования.
81. Следует допустить веб-сервис, локальное ПО либо иное лицензионное решение.
82. Не нужно предписывать точный пользовательский сценарий создания конференции.
83. Также необходимо уточнить срок лицензий.
84. В ТС указано количество лицензий, но не указан срок их действия.
85. Если подписка должна быть годовой, трехлетней либо бессрочной, это должно быть определено заранее.
86. Цена такого ПО существенно зависит от срока.
87. Просим установить минимальный срок лицензии.
88. В целом предлагаем заменить весь раздел внутренней архитектуры программного комплекса коротким функциональным перечнем.
89. Система должна:
- работать локально без обязательного внешнего облака;
- обеспечивать не менее 14 ученических учетных записей;
- поддерживать русский, казахский и желательно английский язык;
- обеспечивать локального AI-ассистента;
- поддерживать программирование;
- компьютерное зрение;
- генерацию материалов;
- анализ документов;
- хранение проектов;
- управление пользователями;
- учет прогресса;
- резервное копирование;
- возможность восстановления;
- работу через веб-браузер.
90. Все остальные внутренние компоненты необходимо оставить на усмотрение разработчика/поставщика.
91. Это позволит предложить открытые программные решения, отечественные разработки и альтернативные коммерческие платформы.
92. В текущей редакции потенциальному поставщику фактически необходимо воспроизвести конкретный AI-стек Заказчика.
93. Это неоправданно сужает конкуренцию.
94. Особенно с учетом быстрого развития технологий искусственного интеллекта.
95. ТС должна допускать решения, которые являются более современными на дату поставки.
96. Просим прямо установить, что отличия названий программных компонентов, моделей, СУБД, framework, inference engine, message broker и внутренней архитектуры не являются несоответствием при обеспечении требуемых функций.
97. Просим также исключить необходимость использовать платформенные технологии конкретного производителя оборудования.
98. Операционная среда должна быть любой стабильной, поддерживаемой и совместимой с предлагаемым оборудованием.
99. Необходимо допустить Linux, Unix-подобные и иные серверные операционные системы при обеспечении требуемых функций.
100. Просим увеличить срок поставки с 15 до минимум 30 календарных дней, поскольку поставщику необходимо не только поставить оборудование, но и развернуть сложный локальный программный комплекс, создать учетные записи, настроить AI-модели, резервное копирование и сетевую инфраструктуру.
Ответы представителей заказчика и организатора, секретаря
Дата:
2026-10-14 12:44:17
Автор:
КАРИМОВА ЖАЗИРА МУРАТКАНОВНА
Решение:
Внести изменения и (или) дополнения в проект конкурсной документации
Описание внесения изменения
1. Не принимается. Закупается комплекс с локальным исполнением ИИ-моделей, распределением задач, сохранением пользовательских сессий и семантическим поиском. ТС определяет необходимые классы компонентов без конкретных наименований фреймворков, брокеров сообщений и СУБД.
2. Не согласны. Согласно форме ТС указываются функциональные, технические, качественные и эксплуатационные характеристики товара. ТС устанавливает классы компонентов и их функции, а выбор конкретных программных продуктов остается за поставщиком.
3. Не согласны. П. 3.1 устанавливает функциональные требования к службе запуска моделей (локальное исполнение, квантование, распределение слоев между GPU и памятью) без указания конкретного продукта.
4. Термин «специализированный сервис/фреймворк» определяет назначение компонента, а не конкретный продукт. Допускаются любой inference-движок, встроенный сервис, контейнеризованное или виртуализированное решение при обеспечении требований ТС.
5. Да. Поддержка этих режимов позволяет выбирать баланс между качеством ответа, скоростью и объемом памяти. Требование сохраняется.
6. Да. Эта функция позволяет эффективно использовать ресурсы сервера при одновременной работе нескольких моделей и пользователей. Требование сохраняется.
7. Да. Конкретное наименование LLM не установлено. Требования к числу параметров, открытости и функциям модели применяются совместно (п. 3.1).
8. Требуются функции детекции объектов в реальном времени и сегментации (п. 3.1) для модуля «Компьютерное зрение». Развертывать их в отдельном приложении или на отдельном сервере не обязательно.
9. Функция нужна для модуля «Генеративные медиа» (п. 3.5). Конкретная модель не установлена.
10. Функция нужна для долговременной памяти ассистента и индексации учебных материалов (п. 3.2). Конкретный продукт не установлен.
11. Отдельный сервер для брокера сообщений не требуется. Допускается его интеграция в программную платформу при сохранении функций брокера и диспетчеризации.
12. Очереди нужны, чтобы при пиковой нагрузке задачи ставились в очередь без падения пользовательских сессий (п. 3.1) и распределялись между узлами (п. 2.2, 4.2).
13. Нужна для хранения учетных записей, учебных планов, результатов тестирования и метаданных (п. 3.2). Конкретная СУБД не установлена.
14. Отдельная векторная база данных не является единственным допустимым решением: ТС прямо предусматривает векторное расширение основной СУБД либо векторную базу данных.
15. Не согласны. ТС определяет классы компонентов и их функции без наименований конкретных продуктов. Такой совокупности соответствуют разные открытые и коммерческие программные решения.
16. Отдельный сервер для брокера не требуется; допускается встроенная реализация, если она обеспечивает функции брокера сообщений и диспетчеризации задач.
17. Этот результат уже предусмотрен п. 3.1: при превышении пиковой нагрузки задачи ставятся в очередь без падения сессий. Кроме того, требуется распределение задач между узлами и их перенаправление при отказе узла (п. 4.2).
18. Функциональный результат в ТС уже установлен (см. ответ на п. 17). Требование к функциям брокера и диспетчеризации сохраняется.
19. Конкретный программный продукт для брокера и очередей не установлен и определяется поставщиком.
20. ТС уже допускает векторное расширение основной СУБД либо отдельную векторную БД.
21. Да, допускается.
22. Да, прямо предусмотрено п. 3.2.
23. Допускается, если реализован векторный семантический поиск по п. 3.2. Полнотекстовый поиск семантический не заменяет.
24. Допускается, если выполняются функции п. 3.2: долговременная память, индексация учебных материалов, семантический поиск.
25. Допустимы варианты, соответствующие п. 3.2 (см. ответы на п. 21–24).
26. Не принимается. Требования к реляционной СУБД и векторному хранилищу сохраняются; конкретные программные продукты не установлены.
27. Не принимается. Предложенный перечень не охватывает семантический поиск и долговременную память ассистента, для которых нужно векторное хранилище.
28. Не принимается. Поддержка дополнительных форматов представления весов не запрещена, но не заменяет поддержку режимов, прямо предусмотренных ТС.
29. Не согласны. Режимы квантования — проверяемая характеристика службы инференса, от которой зависят объем занимаемой памяти и возможность одновременно запускать модели. Кроме того, квантование входит в содержание учебного модуля «Основы искусственного интеллекта» (п. 3.5).
30. Перечисленные дополнительные форматы допускаются, но поддержка режимов 4, 8 и 16 бит обязательна.
31. Требования к скорости и качеству в ТС отдельно не установлены, поэтому соответствие проверяется по установленным характеристикам, включая поддержку режимов 4, 8 и 16 бит.
32. Не принимается. «Приемлемая скорость» не является объективно проверяемым показателем.
33. Не принимается. Требования к числу параметров и функциям модели применяются совместно.
34. Количество параметров — объективная, проверяемая характеристика модели. Функциональные требования (языки, код, инструкции) применяются вместе с ней, а не вместо нее.
35. Модель 8B не соответствует нижнему значению 14B, указанному в ТС, даже при заявленном более высоком качестве.
36. Принято к сведению. Порядок учета общих и активных параметров MoE требует уточнения для однозначной оценки (см. ответ на запрос № 1070000).
37. Не согласны. Требованию соответствует широкий круг современных открытых мультиязычных моделей разных разработчиков.
38. Эти требования уже предусмотрены п. 1.4, 3.1 и 3.5 ТС.
39. Эти функции уже являются обязательными (п. 3.1) и применяются вместе с требованиями к модели.
40. Не принимается.
41. Конкретное наименование LLM в ТС не установлено. Требованиям соответствуют модели разных разработчиков.
42. Коммерческая программная платформа допускается, если основная модель открытая и все компоненты используются законно. Требование открытости основной модели сохраняется.
43. Замена моделей на более современные не запрещена при сохранении совместимости, локального исполнения и предусмотренных функций. Дополнительная обязанность поставщика по бесплатному обновлению моделей на весь срок эксплуатации не устанавливается.
44. Требование к размеру модели минимальное («не менее»), а замена моделей в ходе эксплуатации не запрещена (см. ответ на п. 43).
45. Принято к сведению (см. ответ на п. 43).
46. ТС не запрещает обновлять программную платформу и модели. Доступ к Интернету для получения обновлений допускается при соблюдении правил доступа Заказчика и требования п. 1.4.
47. Названия семи модулей обозначают обязательные образовательные направления, а не товарные наименования программных продуктов.
48. Да, это перечень обязательных образовательных направлений п. 3.5.
49. Принято к сведению.
50. Разъясняем: другие названия разделов и иная группировка тем допускаются, если присутствуют все предусмотренные сценарии и компетенции.
51. Допускается на условиях, указанных в ответе на п. 50.
52. Допускается на условиях, указанных в ответе на п. 50.
53. Принято к сведению (см. ответ на п. 50).
54. Перечень направлений и сценариев п. 3.5 определяет компетенции. Структура курсов не регламентирована (см. ответ на п. 50).
55. Все семь направлений в ТС сохраняются вместе с предусмотренными п. 3.5 сценариями.
56. Количество и структура внутренних программных модулей не регламентированы, если реализованы все направления и сценарии п. 3.5.
57. ТС устанавливает функции личного кабинета (п. 3.3). Графическое оформление, расположение элементов и названия кнопок не регламентированы.
58. Эти функции в ТС сохраняются (п. 3.3) вместе с требованиями изоляции персонального пространства и доступа через браузер без установки клиентского ПО.
59. Разъясняем: термины «песочница» и «файловый менеджер» обозначают функциональные возможности, которые должны быть реализованы независимо от названий элементов интерфейса.
60. П. 3.4 уже определяет кабинет преподавателя через функции. Оформление интерфейса не регламентировано.
61. Предусмотрено п. 3.4: создание учетных записей, сброс паролей, группировка по классам/группам.
62. Предусмотрено п. 3.4 (конструктор учебных материалов, индивидуальные и групповые задания).
63. Предусмотрено п. 3.4 (аналитика успеваемости).
64. Предусмотрено п. 3.4 (мониторинг статуса в реальном времени), а также ограничение доступа к вычислительным ресурсам.
65. Предусмотрено п. 3.4 (вывод работы выбранного обучающегося на экран интерактивной панели).
66. Да, реализация и оформление функций не регламентированы, если выполнены все функции п. 3.4.
67. Требование о сроке восстановления сохраняется. Замечание принимается в части конкретизации условий проверки (см. ответ на п. 68).
68. Принимается. Разъясняем условия применения п. 4.3. Время восстановления определяется для полного развертывания программного контура (база данных, персональные файлы обучающихся, системные конфигурации — п. 4.1) из резервной копии объемом до 1 ТБ на внешнем накопителе на оборудование Комплекса с установленной операционной системой. Отсчет времени ведется с момента запуска процедуры восстановления до возобновления доступа обучающихся к личным кабинетам.
69. Принято к сведению (см. ответ на п. 68).
70. RTO установлен п. 4.3 (не более 2 часов), условия его проверки приведены в ответе на п. 68. Отдельное значение RPO не устанавливается.
71. Не принимается (см. ответ на п. 72).
72. Не принимается. Замена на общую формулировку «возможность восстановления» исключает требования к периодичности, способу копирования и сроку восстановления.
73. Не принимается. Требование ежедневного инкрементного копирования сохраняется. Дополнительные полные, дифференциальные и иные копии допускаются; snapshot-механизм соответствует требованию, если обеспечивает инкрементное копирование.
74. Конкретный программный продукт резервного копирования не установлен. Требования к периодичности и способу копирования сохраняются.
75. Эти потребности обеспечиваются требованиями п. 4.1 и 4.3, которые сохраняются.
76. См. ответы на п. 77–87.
77. Да, количество сохраняется — не менее семи лицензий.
78. Да, эти функции установлены ТС и сохраняются.
79. Производитель коммуникационной платформы не установлен. Раздел описывает функции, а не конкретный продукт.
80. Не принимается в части исключения оперативного создания занятия без предварительного планирования: это самостоятельная требуемая пользовательская функция. Сохраняются также интерфейс на казахском, русском и английском языках и управление уроками.
81. Веб-сервис или устанавливаемое ПО допускаются при выполнении всех требований раздела. Использование сервиса онлайн-обучения не отменяет требование локального исполнения основного ИИ-комплекса.
82. Точные названия кнопок и расположение элементов не регламентированы. Возможность оперативно создать занятие без предварительного планирования сохраняется как функция.
83. Принимается (см. ответ на п. 87).
84. Замечание о неопределенности срока лицензий принимается.
85. Принимается (см. ответ на п. 87).
86. Принято к сведению (см. ответ на п. 87).
87. Принимается. В ТС включено условие: «Срок действия лицензии не менее 12 месяцев». Количество сохраняется — не менее семи лицензий.
88. Не принимается: такой перечень не охватывает все установленные требования к Комплексу.
89. Перечисленные функции в ТС уже есть (п. 1.1–1.4, 3.3–3.5, 4.1–4.3). Английский язык является обязательным, а не желательным (п. 3.1). Перечень не охватывает требования к распределенной обработке, очередям, семантическому поиску, отказоустойчивости, периодичности копирования и сроку восстановления, поэтому заменить им ТС нельзя.
90. Конкретные программные продукты и так выбирает поставщик. Классы компонентов и их функции, установленные ТС, сохраняются.
91. Открытые решения, отечественные разработки и коммерческие платформы допускаются при соответствии ТС и в действующей редакции.
92. Не согласны. ТС не содержит наименований конкретных фреймворков, моделей, СУБД и брокеров и допускает разные варианты реализации (см. ответы на п. 4, 11, 14, 22).
93. Не согласны (см. ответ на п. 92).
94. Принято к сведению. ТС устанавливает минимальные требования и не запрещает более современные решения (см. ответ на п. 95).
95. Более современные решения допускаются при соответствии ТС. Изменение обязательных функций и характеристик нельзя обосновать только иным названием или более новой версией продукта.
96. Отличие названий программных компонентов само по себе не является несоответствием. При этом обязательные функции и технические характеристики (включая классы компонентов, параметры модели и режимы квантования) должны быть соблюдены.
97. ТС не требует использовать технологии конкретного производителя. Формулировка п. 3.1 «с поддержкой аппаратного ускорения ИИ на уровне платформы производителя» означает поддержку ускорения того оборудования, которое предложено поставщиком.
98. Конкретная ОС не названа. Допускается любая ОС, обеспечивающая требования п. 3.1.
99. Linux, Unix-подобные и иные системы допускаются при обеспечении предусмотренной совместимости, аппаратного ускорения и работы программного комплекса.
100. Не принимается. Общий срок поставки остается 15 календарных дней со дня вступления договора в силу. Чтобы изменить срок поставки, Заказчику необходимо отменить данный конкурс, внести изменение в годовой план и заново объявить конкурс, что создает прямую угрозу срыва своевременного оснащения и поставки оборудования, необходимого для непрерывности учебного процесса. Развертывание и настройка выполняются в пределах срока поставки. Для поставщика из Реестра казахстанских товаропроизводителей сохраняется срок 60 календарных дней на основании п. 569 Правил осуществления государственных закупок, утвержденных приказом Министра финансов РК от 9 октября 2024 года № 687.
2. Не согласны. Согласно форме ТС указываются функциональные, технические, качественные и эксплуатационные характеристики товара. ТС устанавливает классы компонентов и их функции, а выбор конкретных программных продуктов остается за поставщиком.
3. Не согласны. П. 3.1 устанавливает функциональные требования к службе запуска моделей (локальное исполнение, квантование, распределение слоев между GPU и памятью) без указания конкретного продукта.
4. Термин «специализированный сервис/фреймворк» определяет назначение компонента, а не конкретный продукт. Допускаются любой inference-движок, встроенный сервис, контейнеризованное или виртуализированное решение при обеспечении требований ТС.
5. Да. Поддержка этих режимов позволяет выбирать баланс между качеством ответа, скоростью и объемом памяти. Требование сохраняется.
6. Да. Эта функция позволяет эффективно использовать ресурсы сервера при одновременной работе нескольких моделей и пользователей. Требование сохраняется.
7. Да. Конкретное наименование LLM не установлено. Требования к числу параметров, открытости и функциям модели применяются совместно (п. 3.1).
8. Требуются функции детекции объектов в реальном времени и сегментации (п. 3.1) для модуля «Компьютерное зрение». Развертывать их в отдельном приложении или на отдельном сервере не обязательно.
9. Функция нужна для модуля «Генеративные медиа» (п. 3.5). Конкретная модель не установлена.
10. Функция нужна для долговременной памяти ассистента и индексации учебных материалов (п. 3.2). Конкретный продукт не установлен.
11. Отдельный сервер для брокера сообщений не требуется. Допускается его интеграция в программную платформу при сохранении функций брокера и диспетчеризации.
12. Очереди нужны, чтобы при пиковой нагрузке задачи ставились в очередь без падения пользовательских сессий (п. 3.1) и распределялись между узлами (п. 2.2, 4.2).
13. Нужна для хранения учетных записей, учебных планов, результатов тестирования и метаданных (п. 3.2). Конкретная СУБД не установлена.
14. Отдельная векторная база данных не является единственным допустимым решением: ТС прямо предусматривает векторное расширение основной СУБД либо векторную базу данных.
15. Не согласны. ТС определяет классы компонентов и их функции без наименований конкретных продуктов. Такой совокупности соответствуют разные открытые и коммерческие программные решения.
16. Отдельный сервер для брокера не требуется; допускается встроенная реализация, если она обеспечивает функции брокера сообщений и диспетчеризации задач.
17. Этот результат уже предусмотрен п. 3.1: при превышении пиковой нагрузки задачи ставятся в очередь без падения сессий. Кроме того, требуется распределение задач между узлами и их перенаправление при отказе узла (п. 4.2).
18. Функциональный результат в ТС уже установлен (см. ответ на п. 17). Требование к функциям брокера и диспетчеризации сохраняется.
19. Конкретный программный продукт для брокера и очередей не установлен и определяется поставщиком.
20. ТС уже допускает векторное расширение основной СУБД либо отдельную векторную БД.
21. Да, допускается.
22. Да, прямо предусмотрено п. 3.2.
23. Допускается, если реализован векторный семантический поиск по п. 3.2. Полнотекстовый поиск семантический не заменяет.
24. Допускается, если выполняются функции п. 3.2: долговременная память, индексация учебных материалов, семантический поиск.
25. Допустимы варианты, соответствующие п. 3.2 (см. ответы на п. 21–24).
26. Не принимается. Требования к реляционной СУБД и векторному хранилищу сохраняются; конкретные программные продукты не установлены.
27. Не принимается. Предложенный перечень не охватывает семантический поиск и долговременную память ассистента, для которых нужно векторное хранилище.
28. Не принимается. Поддержка дополнительных форматов представления весов не запрещена, но не заменяет поддержку режимов, прямо предусмотренных ТС.
29. Не согласны. Режимы квантования — проверяемая характеристика службы инференса, от которой зависят объем занимаемой памяти и возможность одновременно запускать модели. Кроме того, квантование входит в содержание учебного модуля «Основы искусственного интеллекта» (п. 3.5).
30. Перечисленные дополнительные форматы допускаются, но поддержка режимов 4, 8 и 16 бит обязательна.
31. Требования к скорости и качеству в ТС отдельно не установлены, поэтому соответствие проверяется по установленным характеристикам, включая поддержку режимов 4, 8 и 16 бит.
32. Не принимается. «Приемлемая скорость» не является объективно проверяемым показателем.
33. Не принимается. Требования к числу параметров и функциям модели применяются совместно.
34. Количество параметров — объективная, проверяемая характеристика модели. Функциональные требования (языки, код, инструкции) применяются вместе с ней, а не вместо нее.
35. Модель 8B не соответствует нижнему значению 14B, указанному в ТС, даже при заявленном более высоком качестве.
36. Принято к сведению. Порядок учета общих и активных параметров MoE требует уточнения для однозначной оценки (см. ответ на запрос № 1070000).
37. Не согласны. Требованию соответствует широкий круг современных открытых мультиязычных моделей разных разработчиков.
38. Эти требования уже предусмотрены п. 1.4, 3.1 и 3.5 ТС.
39. Эти функции уже являются обязательными (п. 3.1) и применяются вместе с требованиями к модели.
40. Не принимается.
41. Конкретное наименование LLM в ТС не установлено. Требованиям соответствуют модели разных разработчиков.
42. Коммерческая программная платформа допускается, если основная модель открытая и все компоненты используются законно. Требование открытости основной модели сохраняется.
43. Замена моделей на более современные не запрещена при сохранении совместимости, локального исполнения и предусмотренных функций. Дополнительная обязанность поставщика по бесплатному обновлению моделей на весь срок эксплуатации не устанавливается.
44. Требование к размеру модели минимальное («не менее»), а замена моделей в ходе эксплуатации не запрещена (см. ответ на п. 43).
45. Принято к сведению (см. ответ на п. 43).
46. ТС не запрещает обновлять программную платформу и модели. Доступ к Интернету для получения обновлений допускается при соблюдении правил доступа Заказчика и требования п. 1.4.
47. Названия семи модулей обозначают обязательные образовательные направления, а не товарные наименования программных продуктов.
48. Да, это перечень обязательных образовательных направлений п. 3.5.
49. Принято к сведению.
50. Разъясняем: другие названия разделов и иная группировка тем допускаются, если присутствуют все предусмотренные сценарии и компетенции.
51. Допускается на условиях, указанных в ответе на п. 50.
52. Допускается на условиях, указанных в ответе на п. 50.
53. Принято к сведению (см. ответ на п. 50).
54. Перечень направлений и сценариев п. 3.5 определяет компетенции. Структура курсов не регламентирована (см. ответ на п. 50).
55. Все семь направлений в ТС сохраняются вместе с предусмотренными п. 3.5 сценариями.
56. Количество и структура внутренних программных модулей не регламентированы, если реализованы все направления и сценарии п. 3.5.
57. ТС устанавливает функции личного кабинета (п. 3.3). Графическое оформление, расположение элементов и названия кнопок не регламентированы.
58. Эти функции в ТС сохраняются (п. 3.3) вместе с требованиями изоляции персонального пространства и доступа через браузер без установки клиентского ПО.
59. Разъясняем: термины «песочница» и «файловый менеджер» обозначают функциональные возможности, которые должны быть реализованы независимо от названий элементов интерфейса.
60. П. 3.4 уже определяет кабинет преподавателя через функции. Оформление интерфейса не регламентировано.
61. Предусмотрено п. 3.4: создание учетных записей, сброс паролей, группировка по классам/группам.
62. Предусмотрено п. 3.4 (конструктор учебных материалов, индивидуальные и групповые задания).
63. Предусмотрено п. 3.4 (аналитика успеваемости).
64. Предусмотрено п. 3.4 (мониторинг статуса в реальном времени), а также ограничение доступа к вычислительным ресурсам.
65. Предусмотрено п. 3.4 (вывод работы выбранного обучающегося на экран интерактивной панели).
66. Да, реализация и оформление функций не регламентированы, если выполнены все функции п. 3.4.
67. Требование о сроке восстановления сохраняется. Замечание принимается в части конкретизации условий проверки (см. ответ на п. 68).
68. Принимается. Разъясняем условия применения п. 4.3. Время восстановления определяется для полного развертывания программного контура (база данных, персональные файлы обучающихся, системные конфигурации — п. 4.1) из резервной копии объемом до 1 ТБ на внешнем накопителе на оборудование Комплекса с установленной операционной системой. Отсчет времени ведется с момента запуска процедуры восстановления до возобновления доступа обучающихся к личным кабинетам.
69. Принято к сведению (см. ответ на п. 68).
70. RTO установлен п. 4.3 (не более 2 часов), условия его проверки приведены в ответе на п. 68. Отдельное значение RPO не устанавливается.
71. Не принимается (см. ответ на п. 72).
72. Не принимается. Замена на общую формулировку «возможность восстановления» исключает требования к периодичности, способу копирования и сроку восстановления.
73. Не принимается. Требование ежедневного инкрементного копирования сохраняется. Дополнительные полные, дифференциальные и иные копии допускаются; snapshot-механизм соответствует требованию, если обеспечивает инкрементное копирование.
74. Конкретный программный продукт резервного копирования не установлен. Требования к периодичности и способу копирования сохраняются.
75. Эти потребности обеспечиваются требованиями п. 4.1 и 4.3, которые сохраняются.
76. См. ответы на п. 77–87.
77. Да, количество сохраняется — не менее семи лицензий.
78. Да, эти функции установлены ТС и сохраняются.
79. Производитель коммуникационной платформы не установлен. Раздел описывает функции, а не конкретный продукт.
80. Не принимается в части исключения оперативного создания занятия без предварительного планирования: это самостоятельная требуемая пользовательская функция. Сохраняются также интерфейс на казахском, русском и английском языках и управление уроками.
81. Веб-сервис или устанавливаемое ПО допускаются при выполнении всех требований раздела. Использование сервиса онлайн-обучения не отменяет требование локального исполнения основного ИИ-комплекса.
82. Точные названия кнопок и расположение элементов не регламентированы. Возможность оперативно создать занятие без предварительного планирования сохраняется как функция.
83. Принимается (см. ответ на п. 87).
84. Замечание о неопределенности срока лицензий принимается.
85. Принимается (см. ответ на п. 87).
86. Принято к сведению (см. ответ на п. 87).
87. Принимается. В ТС включено условие: «Срок действия лицензии не менее 12 месяцев». Количество сохраняется — не менее семи лицензий.
88. Не принимается: такой перечень не охватывает все установленные требования к Комплексу.
89. Перечисленные функции в ТС уже есть (п. 1.1–1.4, 3.3–3.5, 4.1–4.3). Английский язык является обязательным, а не желательным (п. 3.1). Перечень не охватывает требования к распределенной обработке, очередям, семантическому поиску, отказоустойчивости, периодичности копирования и сроку восстановления, поэтому заменить им ТС нельзя.
90. Конкретные программные продукты и так выбирает поставщик. Классы компонентов и их функции, установленные ТС, сохраняются.
91. Открытые решения, отечественные разработки и коммерческие платформы допускаются при соответствии ТС и в действующей редакции.
92. Не согласны. ТС не содержит наименований конкретных фреймворков, моделей, СУБД и брокеров и допускает разные варианты реализации (см. ответы на п. 4, 11, 14, 22).
93. Не согласны (см. ответ на п. 92).
94. Принято к сведению. ТС устанавливает минимальные требования и не запрещает более современные решения (см. ответ на п. 95).
95. Более современные решения допускаются при соответствии ТС. Изменение обязательных функций и характеристик нельзя обосновать только иным названием или более новой версией продукта.
96. Отличие названий программных компонентов само по себе не является несоответствием. При этом обязательные функции и технические характеристики (включая классы компонентов, параметры модели и режимы квантования) должны быть соблюдены.
97. ТС не требует использовать технологии конкретного производителя. Формулировка п. 3.1 «с поддержкой аппаратного ускорения ИИ на уровне платформы производителя» означает поддержку ускорения того оборудования, которое предложено поставщиком.
98. Конкретная ОС не названа. Допускается любая ОС, обеспечивающая требования п. 3.1.
99. Linux, Unix-подобные и иные системы допускаются при обеспечении предусмотренной совместимости, аппаратного ускорения и работы программного комплекса.
100. Не принимается. Общий срок поставки остается 15 календарных дней со дня вступления договора в силу. Чтобы изменить срок поставки, Заказчику необходимо отменить данный конкурс, внести изменение в годовой план и заново объявить конкурс, что создает прямую угрозу срыва своевременного оснащения и поставки оборудования, необходимого для непрерывности учебного процесса. Развертывание и настройка выполняются в пределах срока поставки. Для поставщика из Реестра казахстанских товаропроизводителей сохраняется срок 60 календарных дней на основании п. 569 Правил осуществления государственных закупок, утвержденных приказом Министра финансов РК от 9 октября 2024 года № 687.
