Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 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-модели, резервное копирование и сетевую инфраструктуру.
