Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1069234
Тема сообщения
Нарушения в ТС
Тип сообщения
Замечание к АД
Поставщик
Товарищество с ограниченной ответственностью "IT-Quantum"
Представитель поставщика
ҚАЙРАТҰЛЫ БАУЫРЖАН
Дата и время отправки сообщения
2026-10-01 09:31:00
Текст сообщения
ЗАМЕЧАНИЯ
1. Требования к информационно-интерактивному стенду с дополненной реальностью и искусственным интеллектом чрезмерно детализируют конкретный программный сценарий, структуру пользовательского интерфейса и внутреннюю архитектуру продукта вместо определения конечного образовательного результата.
2. Физический стенд должен содержать до 20% информации, а AR-часть — до 80%. Не определено, каким образом должен измеряться процент информационного содержания: по количеству символов, площади, числу смысловых блоков, объему файлов либо иному показателю.
3. Просим исключить процентное деление 20/80 либо установить объективную методику его расчета.
4. AR-контент должен запускаться через QR-код именно в мобильном веб-браузере. Эквивалентная система может использовать WebAR, PWA, отдельное мобильное приложение либо гибридное решение. Конечным результатом является доступ к AR-контенту после сканирования кода.
5. Просим допустить любой технический способ, не требующий дополнительных платных действий от пользователя и обеспечивающий заявленные функции.
6. Программа обязательно должна запрашивать разрешение на камеру, датчики движения и ориентации, микрофон и геолокацию. Не все функции AR требуют постоянного доступа к микрофону и геолокации.
7. Обязательный запрос геолокации особенно нуждается в обосновании, поскольку стенд физически расположен внутри школы. Местоположение пользователя может не быть необходимо для отображения образовательного AR-контента.
8. Просим определить конкретную функциональную задачу, для которой обязательна геолокация, и исключить избыточный сбор данных.
9. Аналогично микрофон должен запрашиваться только при использовании голосового помощника, а не как обязательное разрешение для самого доступа к AR-сцене.
10. ТС требует после выдачи разрешений предлагать пользователю отдельный обучающий курс по интерфейсу. Это описание конкретного пользовательского сценария. Эквивалентный продукт может иметь настолько простой интерфейс, что отдельный onboarding не требуется.
11. Просим сделать обучение необязательной функцией.
12. Виртуальная 3D-сцена должна учитывать показания инерционных датчиков устройства для эффекта погружения. Не все смартфоны одинаково точно поддерживают гироскоп, акселерометр и магнитометр.
13. Далее в минимальных требованиях к смартфону действительно фиксируется обязательное наличие всех трех сенсоров. Это исключает использование на устройствах, которые способны корректно работать с камерным AR, но не имеют, например, магнитометра.
14. Просим определить минимально необходимый набор сенсоров по функциональной необходимости.
15. ТС требует голосовое сопровождение на казахском, русском и английском языках. Если образовательная организация использует преимущественно государственный и русский языки, просим обосновать обязательность английской озвучки всего контента и соответствующие расходы на локализацию.
16. Виртуальный помощник должен поддерживать текстовое и голосовое общение и выдавать ответы в текстовой либо аудиоформе. Не определено, должен ли это быть генеративный ИИ, заранее запрограммированный бот, retrieval-based система либо другой механизм.
17. Термин «искусственный интеллект» используется без критериев качества, модели, точности ответов, способов ограничения нежелательного контента, источников знаний и механизмов защиты детей.
18. Просим установить требования к безопасности ИИ-компонента: ограничения тематики, фильтрацию, журналирование, запрет выдачи потенциально опасного контента, обработку персональных данных, хранение голосовых запросов и порядок обновления модели.
19. Не указано, используется ли внешний облачный AI API. Если используется, необходимо определить, куда передаются голосовые и текстовые данные учащихся, в какой юрисдикции хранятся данные и кто является оператором сервиса.
20. Если система требует постоянного доступа в Интернет для работы AI-компонента, необходимо прямо указать требования к каналу связи и последствия отсутствия Интернета.
21. В технической спецификации подробно предписан сценарий завершения работы со стендом: кнопка «Закрыть» должна переводить пользователя в виртуальный центральный хаб/зал. Это конкретная UI-реализация.
22. Эквивалентная платформа может использовать меню, вкладки, карту тематик, дерево контента либо иной навигационный сценарий. Просим не фиксировать обязательное наличие кнопки «Закрыть» и виртуального зала.
23. Система должна автоматически анализировать тематику посещенного стенда и генерировать дополнительные AR-стенды из смежной тематической группы. Фактически описан конкретный рекомендательный алгоритм.
24. Просим заменить требование на возможность перехода к связанным образовательным материалам без предписания внутренней логики.
25. Далее обязательно отображается интерактивная книжная полка с ровно семью виртуальными книгами. Количество и представление разделов являются элементами конкретного интерфейса, не связанными с конечным образовательным результатом.
26. Просим допустить не менее семи тематических направлений либо иной способ навигации без обязательной визуализации в виде книжной полки.
27. Предписаны конкретные названия семи книг: безопасность, культура и коммуникация, здоровый организм, развитие личности, учебные дисциплины, индивидуальные школы, 3D-фигуры и абстракции.
28. Если эти направления являются обязательными образовательными разделами, необходимо сформулировать требование к наличию соответствующего контента, а не к метафоре «книг».
29. Предусмотрено кэширование данных ранее приобретенных/освоенных стендов, адаптивная навигация по поведению пользователя и модульная архитектура. Указанные требования относятся к внутренней реализации платформы.
30. Просим оставить функционал быстрого повторного доступа и масштабируемости без обязательного кэширования либо определенной архитектуры.
31. Содержательная часть AR-стенда детализирована вплоть до конкретных интерактивных сценариев: виртуальный скворечник, посадка дерева, карта профессий, выбор персонажа, моделирование рабочего процесса, дебаты через анимационные модели и т.д.
32. Подобная детализация может соответствовать заранее разработанной платформе. Просим допустить эквивалентные интерактивные упражнения, раскрывающие те же темы.
33. В технических требованиях установлено, что объем программы должен быть минимум 3 МБ. Минимальный размер программного продукта не является показателем качества. Программа объемом 2 МБ может быть оптимизирована лучше, а приложение 100 МБ — не обязательно функциональнее.
34. Просим исключить минимальный объем 3 МБ как технически нецелесообразный показатель.
35. Еще более ограничивающими являются серверные требования: ОС — Linux, веб-сервер — Nginx, язык программирования — JavaScript. Это прямая фиксация внутреннего технологического стека разработчика.
36. Для Заказчика не имеет значения, написан backend на JavaScript, Python, Java, Go, PHP, C# либо другом языке, если сервис выполняет требуемые функции.
37. Аналогично Apache, Caddy, IIS, cloud load balancer либо managed serverless architecture могут обеспечивать те же функции, что Nginx.
38. Просим полностью исключить требования к языку программирования, конкретному веб-серверу и внутренней серверной ОС либо сформулировать их как совместимость/результат.
39. Минимальные требования к смартфону также чрезмерно конкретны: Android не ниже 9, iOS не ниже 11, камера не менее 8 Мп, ОЗУ минимум 2 ГБ, экран не менее 640х480 и обязательные сенсоры.
40. Качество AR не определяется напрямую мегапикселями камеры. Более современная камера 5 Мп с хорошей оптикой теоретически может лучше считывать QR-код, чем старая 8 Мп.
41. Просим определять совместимость по факту поддержки браузера/WebAR и необходимых API.
42. Требование геолокации для доступа к защищенным страницам также необычно. Геолокация сама по себе не является стандартным механизмом аутентификации и может быть неточной внутри здания.
43. Просим обосновать данную архитектуру безопасности и допустить обычные современные средства контроля доступа.
44. Техническая поддержка предусматривает обновление AR-контента в течение одного года, однако не указано количество обновлений, максимальный объем работ, сроки реакции, количество новых материалов и порядок согласования.
45. Просим конкретизировать объем годовой поддержки, чтобы все участники оценивали одинаковый объем обязательств.
46. Требование авторизации производителя/правообладателя, исходного кода и патента дополнительно делает участие зависимым от владельца заранее существующей платформы.
47. В целом раздел AR/AI-стенда следует переработать через функциональные результаты: физический стенд, QR-доступ, AR-объекты, трехъязычный контент, интерактивность, безопасный AI-помощник, адаптивность для современных смартфонов, годовая поддержка и надежная работа, не фиксируя внутренний стек и конкретные сценарии интерфейса.
1. Требования к информационно-интерактивному стенду с дополненной реальностью и искусственным интеллектом чрезмерно детализируют конкретный программный сценарий, структуру пользовательского интерфейса и внутреннюю архитектуру продукта вместо определения конечного образовательного результата.
2. Физический стенд должен содержать до 20% информации, а AR-часть — до 80%. Не определено, каким образом должен измеряться процент информационного содержания: по количеству символов, площади, числу смысловых блоков, объему файлов либо иному показателю.
3. Просим исключить процентное деление 20/80 либо установить объективную методику его расчета.
4. AR-контент должен запускаться через QR-код именно в мобильном веб-браузере. Эквивалентная система может использовать WebAR, PWA, отдельное мобильное приложение либо гибридное решение. Конечным результатом является доступ к AR-контенту после сканирования кода.
5. Просим допустить любой технический способ, не требующий дополнительных платных действий от пользователя и обеспечивающий заявленные функции.
6. Программа обязательно должна запрашивать разрешение на камеру, датчики движения и ориентации, микрофон и геолокацию. Не все функции AR требуют постоянного доступа к микрофону и геолокации.
7. Обязательный запрос геолокации особенно нуждается в обосновании, поскольку стенд физически расположен внутри школы. Местоположение пользователя может не быть необходимо для отображения образовательного AR-контента.
8. Просим определить конкретную функциональную задачу, для которой обязательна геолокация, и исключить избыточный сбор данных.
9. Аналогично микрофон должен запрашиваться только при использовании голосового помощника, а не как обязательное разрешение для самого доступа к AR-сцене.
10. ТС требует после выдачи разрешений предлагать пользователю отдельный обучающий курс по интерфейсу. Это описание конкретного пользовательского сценария. Эквивалентный продукт может иметь настолько простой интерфейс, что отдельный onboarding не требуется.
11. Просим сделать обучение необязательной функцией.
12. Виртуальная 3D-сцена должна учитывать показания инерционных датчиков устройства для эффекта погружения. Не все смартфоны одинаково точно поддерживают гироскоп, акселерометр и магнитометр.
13. Далее в минимальных требованиях к смартфону действительно фиксируется обязательное наличие всех трех сенсоров. Это исключает использование на устройствах, которые способны корректно работать с камерным AR, но не имеют, например, магнитометра.
14. Просим определить минимально необходимый набор сенсоров по функциональной необходимости.
15. ТС требует голосовое сопровождение на казахском, русском и английском языках. Если образовательная организация использует преимущественно государственный и русский языки, просим обосновать обязательность английской озвучки всего контента и соответствующие расходы на локализацию.
16. Виртуальный помощник должен поддерживать текстовое и голосовое общение и выдавать ответы в текстовой либо аудиоформе. Не определено, должен ли это быть генеративный ИИ, заранее запрограммированный бот, retrieval-based система либо другой механизм.
17. Термин «искусственный интеллект» используется без критериев качества, модели, точности ответов, способов ограничения нежелательного контента, источников знаний и механизмов защиты детей.
18. Просим установить требования к безопасности ИИ-компонента: ограничения тематики, фильтрацию, журналирование, запрет выдачи потенциально опасного контента, обработку персональных данных, хранение голосовых запросов и порядок обновления модели.
19. Не указано, используется ли внешний облачный AI API. Если используется, необходимо определить, куда передаются голосовые и текстовые данные учащихся, в какой юрисдикции хранятся данные и кто является оператором сервиса.
20. Если система требует постоянного доступа в Интернет для работы AI-компонента, необходимо прямо указать требования к каналу связи и последствия отсутствия Интернета.
21. В технической спецификации подробно предписан сценарий завершения работы со стендом: кнопка «Закрыть» должна переводить пользователя в виртуальный центральный хаб/зал. Это конкретная UI-реализация.
22. Эквивалентная платформа может использовать меню, вкладки, карту тематик, дерево контента либо иной навигационный сценарий. Просим не фиксировать обязательное наличие кнопки «Закрыть» и виртуального зала.
23. Система должна автоматически анализировать тематику посещенного стенда и генерировать дополнительные AR-стенды из смежной тематической группы. Фактически описан конкретный рекомендательный алгоритм.
24. Просим заменить требование на возможность перехода к связанным образовательным материалам без предписания внутренней логики.
25. Далее обязательно отображается интерактивная книжная полка с ровно семью виртуальными книгами. Количество и представление разделов являются элементами конкретного интерфейса, не связанными с конечным образовательным результатом.
26. Просим допустить не менее семи тематических направлений либо иной способ навигации без обязательной визуализации в виде книжной полки.
27. Предписаны конкретные названия семи книг: безопасность, культура и коммуникация, здоровый организм, развитие личности, учебные дисциплины, индивидуальные школы, 3D-фигуры и абстракции.
28. Если эти направления являются обязательными образовательными разделами, необходимо сформулировать требование к наличию соответствующего контента, а не к метафоре «книг».
29. Предусмотрено кэширование данных ранее приобретенных/освоенных стендов, адаптивная навигация по поведению пользователя и модульная архитектура. Указанные требования относятся к внутренней реализации платформы.
30. Просим оставить функционал быстрого повторного доступа и масштабируемости без обязательного кэширования либо определенной архитектуры.
31. Содержательная часть AR-стенда детализирована вплоть до конкретных интерактивных сценариев: виртуальный скворечник, посадка дерева, карта профессий, выбор персонажа, моделирование рабочего процесса, дебаты через анимационные модели и т.д.
32. Подобная детализация может соответствовать заранее разработанной платформе. Просим допустить эквивалентные интерактивные упражнения, раскрывающие те же темы.
33. В технических требованиях установлено, что объем программы должен быть минимум 3 МБ. Минимальный размер программного продукта не является показателем качества. Программа объемом 2 МБ может быть оптимизирована лучше, а приложение 100 МБ — не обязательно функциональнее.
34. Просим исключить минимальный объем 3 МБ как технически нецелесообразный показатель.
35. Еще более ограничивающими являются серверные требования: ОС — Linux, веб-сервер — Nginx, язык программирования — JavaScript. Это прямая фиксация внутреннего технологического стека разработчика.
36. Для Заказчика не имеет значения, написан backend на JavaScript, Python, Java, Go, PHP, C# либо другом языке, если сервис выполняет требуемые функции.
37. Аналогично Apache, Caddy, IIS, cloud load balancer либо managed serverless architecture могут обеспечивать те же функции, что Nginx.
38. Просим полностью исключить требования к языку программирования, конкретному веб-серверу и внутренней серверной ОС либо сформулировать их как совместимость/результат.
39. Минимальные требования к смартфону также чрезмерно конкретны: Android не ниже 9, iOS не ниже 11, камера не менее 8 Мп, ОЗУ минимум 2 ГБ, экран не менее 640х480 и обязательные сенсоры.
40. Качество AR не определяется напрямую мегапикселями камеры. Более современная камера 5 Мп с хорошей оптикой теоретически может лучше считывать QR-код, чем старая 8 Мп.
41. Просим определять совместимость по факту поддержки браузера/WebAR и необходимых API.
42. Требование геолокации для доступа к защищенным страницам также необычно. Геолокация сама по себе не является стандартным механизмом аутентификации и может быть неточной внутри здания.
43. Просим обосновать данную архитектуру безопасности и допустить обычные современные средства контроля доступа.
44. Техническая поддержка предусматривает обновление AR-контента в течение одного года, однако не указано количество обновлений, максимальный объем работ, сроки реакции, количество новых материалов и порядок согласования.
45. Просим конкретизировать объем годовой поддержки, чтобы все участники оценивали одинаковый объем обязательств.
46. Требование авторизации производителя/правообладателя, исходного кода и патента дополнительно делает участие зависимым от владельца заранее существующей платформы.
47. В целом раздел AR/AI-стенда следует переработать через функциональные результаты: физический стенд, QR-доступ, AR-объекты, трехъязычный контент, интерактивность, безопасный AI-помощник, адаптивность для современных смартфонов, годовая поддержка и надежная работа, не фиксируя внутренний стек и конкретные сценарии интерфейса.
