Интересная штука. Хотел потыкать, но у вас регистрация только по приглашениям. Судя по описанию и скринам интерфейса (здесь и у вас на сайте), я бы сказал, вашей системе недостаёт векторного поиска. Полезная штука, когда документации много и коррелирует с вашими планами - я имею в виду ИИ помощника (RAG)
В целом тяжеловато что-то делать когда это происходит не в IDE, а в окне браузера. Но все же тоже изредка этим грешу)). Конкретно про облачный deepseek могу сказать, что если сначала обговорить с ним архитектуру или продумать ее самому (или описать если она уже разработана), а deepseek'у максимально конкретизировать задачу - то он не занимается такой ерундой.
А в целом работа через ИИ это постоянный жесткий codereview, даже покруче чем с джунами. И задачи описывать приходится мегаподробно. А там где мегаподробно описывать не нужно - проще самому руками сделать. Может, конечно, я что-то не так делаю :)
Насколько я понял, они использовали iFlow Cli два агента: Архитектор и Программист. Они брали реальный репозиторий (какого-нибудь публичного проекта) в исходном состоянии и какой-нибудь целевой коммит (спустя долгое время, в среднем почти год или 70 коммитов спустя). Ставилась задача пройти путь от базы до целевого коммита внося изменения итеративно. В каждой итерации Архитектор генерил файл requirements.xml для Программиста который попадал в его контекст с остальными файлами проекта. Что касается MCP, то у IFlow CLI он полностью поддерживается, но судя по описанию теста не использовался. Там прямо говориться что агентам было запрещено выходить за границы директории проекта, запускать тесты, и т.д.
Квантование это округление параметров, грубо говоря становится меньше знаков после запятой и они занимают меньше памяти, в то время, как, 397B это кол-во параметров. Чтобы грубо оценить вес модели нужно кол-во параметров умножить на 4, т.к. если модель FP32 - то на параметр приходится 32 бита или 4 байта в переводе. А если квантовать ей в 4 (т.е. qwen-3.5-397B-Q4) -> параметр будет весить 4 бита или 0.5 байта в переводе. Что касается 397B и 9B то это, по сути, разные модели - количество параметров разное.
агрегатных состояний не 3, и не 4, а 19 на текущее время
почему круги на воде всегда круглые не зависимо от формы предмета......
Вы знаете как кинуть замануху для душнилы, сэр)) Глаз зацепился за кол-во агрегатных состояний. Всегда считал что их 4 или 5. Вы имели ввиду именно агрегатных состояний или вперемешку с фазами подвидами структурами и прочим? Или теперь их стали как-то иначе делить? Пробовал погуглить 19 штук, но не нашел упоминаний.
могу ошибаться, неудобно с телефона пруфы искать, поправьте если я не прав. По моему скромному мнению хром доминирует:
а) лучше поддержка железа (это я сейчас про issues с видеокартами)
б) он когда-то давно был более оснащенным в плане отладки и более лояльным к ошибкам в разметке и новым фичам стандартов. С тех пор именно им для отладки большинство полтзуется в первую очередь. А соотвественно и баги (коих до сих пор много) обнаруживаются там более активно, чаще пишутся репорты.
Ввиду вышеперечисленного проще при разработке опираться именно на хром, а потом уже тестировать кроссбраузерность. Ну а если разрабатывается что-то простое то там без разници чей девтул, хоть Vivaldi. Тут скорее привычка решает.
я по названию нагуглил https://gost-on.ru/
Интересная штука. Хотел потыкать, но у вас регистрация только по приглашениям. Судя по описанию и скринам интерфейса (здесь и у вас на сайте), я бы сказал, вашей системе недостаёт векторного поиска. Полезная штука, когда документации много и коррелирует с вашими планами - я имею в виду ИИ помощника (RAG)
В целом тяжеловато что-то делать когда это происходит не в IDE, а в окне браузера. Но все же тоже изредка этим грешу)). Конкретно про облачный deepseek могу сказать, что если сначала обговорить с ним архитектуру или продумать ее самому (или описать если она уже разработана), а deepseek'у максимально конкретизировать задачу - то он не занимается такой ерундой.
А в целом работа через ИИ это постоянный жесткий codereview, даже покруче чем с джунами. И задачи описывать приходится мегаподробно. А там где мегаподробно описывать не нужно - проще самому руками сделать. Может, конечно, я что-то не так делаю :)
Насколько я понял, они использовали iFlow Cli два агента: Архитектор и Программист. Они брали реальный репозиторий (какого-нибудь публичного проекта) в исходном состоянии и какой-нибудь целевой коммит (спустя долгое время, в среднем почти год или 70 коммитов спустя). Ставилась задача пройти путь от базы до целевого коммита внося изменения итеративно. В каждой итерации Архитектор генерил файл requirements.xml для Программиста который попадал в его контекст с остальными файлами проекта. Что касается MCP, то у IFlow CLI он полностью поддерживается, но судя по описанию теста не использовался. Там прямо говориться что агентам было запрещено выходить за границы директории проекта, запускать тесты, и т.д.
Квантование это округление параметров, грубо говоря становится меньше знаков после запятой и они занимают меньше памяти, в то время, как, 397B это кол-во параметров. Чтобы грубо оценить вес модели нужно кол-во параметров умножить на 4, т.к. если модель FP32 - то на параметр приходится 32 бита или 4 байта в переводе. А если квантовать ей в 4 (т.е. qwen-3.5-397B-Q4) -> параметр будет весить 4 бита или 0.5 байта в переводе. Что касается 397B и 9B то это, по сути, разные модели - количество параметров разное.
интересно какой именно qwen-3.5 использовали. Они есть от 3b до 397B, насколько мне известно.
Вы знаете как кинуть замануху для душнилы, сэр))
Глаз зацепился за кол-во агрегатных состояний. Всегда считал что их 4 или 5. Вы имели ввиду именно агрегатных состояний или вперемешку с фазами подвидами структурами и прочим? Или теперь их стали как-то иначе делить? Пробовал погуглить 19 штук, но не нашел упоминаний.
могу ошибаться, неудобно с телефона пруфы искать, поправьте если я не прав. По моему скромному мнению хром доминирует:
а) лучше поддержка железа (это я сейчас про issues с видеокартами)
б) он когда-то давно был более оснащенным в плане отладки и более лояльным к ошибкам в разметке и новым фичам стандартов. С тех пор именно им для отладки большинство полтзуется в первую очередь. А соотвественно и баги (коих до сих пор много) обнаруживаются там более активно, чаще пишутся репорты.
Ввиду вышеперечисленного проще при разработке опираться именно на хром, а потом уже тестировать кроссбраузерность. Ну а если разрабатывается что-то простое то там без разници чей девтул, хоть Vivaldi. Тут скорее привычка решает.