Так тут дело не в контексте модели, а в его использовании. И модель с 1M токенов контекста можно завесить. Было бы желание. Как пример - ассемблер и Delphi. Где исполняемый файл будет более компактным и более полно использовать ресурсы? Дело, как говорят сейчас в harness. Мы слишком привыкли к безграничным облачным мощностям, в том числе и вендоры IDE. Поэтому, когда появилась настоятельная необходимость использования для чувствительных данных только on-premise, а мощности были ограниченными пришлось оптимизировать использование контекста без снижения качества разработки. И теперь у меня есть IDE, которая совершенно иначе понимает и расходует контекст в отличие от стандартных рыночных решений.
На практике всё упирается в методологию разработки. Что при самостоятельном написании кода, что при помощи ИИ. Помним главное, что именно человек остаётся архитектором проекта, а ИИ - это лишь подмастерье. То есть в любом случае если проект достаточно объёмный его придётся делить на модули. И управлять взаимосвязью модулей между собой будет человек-архитектор-разработчик. ИИ в данном случае получает вполне посильную для него задачу написания и верификации кода модулей, а также может взять модульную структуру проекта, как отдельный семантический объект и проанализировать его взаимосвязи не углубляясь подробно в содержимое каждого модуля. Тогда и контекста в 32k вполне достаточно для эффективной разработки. У меня в IDE: Короткий ход - чтение кусками - делегированный анализ (субагенту или другому агенту) с упакованным payload - запись - механическая верификация - микрокоммит. При 32k это не «урезанный режим», а основной, для которого настроены все пороги в коде.
Хватает им контекста. Даже 32k хватает чтобы написать и отладить проект среднего размера. Всё зависит от того как построена работа с контекстом у современных приложений ориентированных на ИИ-разработку. Когда к Cursor подключается модель на 32k, то ничего не происходит. Просто потому, что его контекст только для начала работы очень сильно превышает 32k и ориентирован на работу с облачными моделями. Это стало поводом задуматься и написать инструмент, который и с моделью на 32k ведёт себя вполне прилично. И не нужно сваливать весь проект в один чат. Контекстное окно никто не отменял. Да его можно избежать при помощи специальных механизмов, но увы, в распространённых приложениях таких механизмов мне не встречалось. Поэтому, как правило, вайб-кодинг (хотя это уже давно не вайб, а обычная разработка) состоит из серии достаточно небольших чатов с моделью размером около 100k токенов. Более длительный чат - только при первичной отладке сложных мест. И то с последующей перепроверкой в коротких чатах.
ИИ нормально пишет черновик. Но только люди без тестирования написанного черновика прямо толкают его в прод. ИИ нормально перепишет и набело, если только будут адекватные тестировщики знакомые с предметной областью и хорошо представляющие, что требуется от продукта разработки. ИИ не архитектор, а ускоритель нажатия на клавиши.
Интересная работа. Была такая же у меня, только совместно с панорамными снимками там изучались и панорамные реформаты из CBCT (КТ). Превратить CBCT в адекватную панораму в автоматическом режиме, тот ещё квест, особенно учитывая изменчивость анатомии зубной дуги с возрастом. И да, для ассистента врача всё упирается в качественную модель распознавания патологии. С моделью есть нюанс - если использовать её на другом домене снимков, отличном от того, на котором проводилось обучение, то результаты начинают плавать. То есть модель обученная на панорамах будет врать на панорамных реформатах. Как Вы собираетесь решить проблему зависимости от домена?
У меня есть такая штука. Возможно, почти то, к чему стремится автор. Любые модели локальные и через API. Чаты, генерация картинок, общение голосом, своё PWA, свой SIP-клиент (можно разговаривать по телефону с моделью), набор встроенных скриптов ("руки" модели), если что дописывает их сама по потребности. Оригинальный механизм управления памятью. В общем много там всего. Только вот нет модуля загрузки моделей с HF. Мне как-то и в голову не приходило, что кому-то будет сложно запустить Ollama или LM Studio.
Идея хорошая. Правда нечто похожее есть уже в LM Studio. Но как самостоятельное творчество - почему бы и да :) Несколько замечаний по анализу репозитория:
Нет лицензии. Ни LICENSE, ни указания в README/GitHub — юридически «все права защищены». Переиспользовать этот код — без разрешения автора нельзя. Тогда зачем упоминать репозиторий?
Цепочка поставки движков держится на одном S3-бакете (Timeweb) и одном человеке. Обновления подписаны, а вот сами движки — нет: их целостность = SHA256 в манифесте, который лежит в той же инфраструктуре. Компрометация бакета или машины автора → произвольный код на машинах пользователей. Обновление манифеста из S3 пока вообще не подключено (код newest() помечен dead_code) — сейчас работает только зашитый манифест, что пока безопаснее.
Без подписи Microsoft установка новичка через «Всё равно выполнить» — для целевой аудитории это риск, что люди привыкнут жать эту кнопку на чём попало, плюс подделки под Ollivo никто не отличит.
Локальный llama-server без API-ключа — любой процесс того же пользователя машины может им воспользоваться. Для категории продукта норма (Ollama так же), но формально это дырка в мультипользовательской Windows.
«Авто»-режим папки проекта — модель правит и удаляет файлы без подтверждения. Бэкапы смягчают, но вредоносный документ в папке может подсказать модели что-то удалить; граница «только папка проекта» здесь единственная защита.
Гигиена кода: в engines.rs закоммичен настоящий NUL-байт внутри тестовой строки (comfyui\0.37.0 — экранирование съело бэкслэш): файл для grep/Read «бинарный», а смысл теста тихо изменился.
Кто же Вам запретит? Делегируйте ИИ всё, что хотите. Это концепция взаимодействия. Не более того.
Так тут дело не в контексте модели, а в его использовании. И модель с 1M токенов контекста можно завесить. Было бы желание. Как пример - ассемблер и Delphi. Где исполняемый файл будет более компактным и более полно использовать ресурсы? Дело, как говорят сейчас в harness. Мы слишком привыкли к безграничным облачным мощностям, в том числе и вендоры IDE. Поэтому, когда появилась настоятельная необходимость использования для чувствительных данных только on-premise, а мощности были ограниченными пришлось оптимизировать использование контекста без снижения качества разработки. И теперь у меня есть IDE, которая совершенно иначе понимает и расходует контекст в отличие от стандартных рыночных решений.
На практике всё упирается в методологию разработки. Что при самостоятельном написании кода, что при помощи ИИ. Помним главное, что именно человек остаётся архитектором проекта, а ИИ - это лишь подмастерье. То есть в любом случае если проект достаточно объёмный его придётся делить на модули. И управлять взаимосвязью модулей между собой будет человек-архитектор-разработчик. ИИ в данном случае получает вполне посильную для него задачу написания и верификации кода модулей, а также может взять модульную структуру проекта, как отдельный семантический объект и проанализировать его взаимосвязи не углубляясь подробно в содержимое каждого модуля. Тогда и контекста в 32k вполне достаточно для эффективной разработки. У меня в IDE: Короткий ход - чтение кусками - делегированный анализ (субагенту или другому агенту) с упакованным payload - запись - механическая верификация - микрокоммит. При 32k это не «урезанный режим», а основной, для которого настроены все пороги в коде.
Хватает им контекста. Даже 32k хватает чтобы написать и отладить проект среднего размера. Всё зависит от того как построена работа с контекстом у современных приложений ориентированных на ИИ-разработку. Когда к Cursor подключается модель на 32k, то ничего не происходит. Просто потому, что его контекст только для начала работы очень сильно превышает 32k и ориентирован на работу с облачными моделями. Это стало поводом задуматься и написать инструмент, который и с моделью на 32k ведёт себя вполне прилично. И не нужно сваливать весь проект в один чат. Контекстное окно никто не отменял. Да его можно избежать при помощи специальных механизмов, но увы, в распространённых приложениях таких механизмов мне не встречалось. Поэтому, как правило, вайб-кодинг (хотя это уже давно не вайб, а обычная разработка) состоит из серии достаточно небольших чатов с моделью размером около 100k токенов. Более длительный чат - только при первичной отладке сложных мест. И то с последующей перепроверкой в коротких чатах.
ИИ нормально пишет черновик. Но только люди без тестирования написанного черновика прямо толкают его в прод. ИИ нормально перепишет и набело, если только будут адекватные тестировщики знакомые с предметной областью и хорошо представляющие, что требуется от продукта разработки. ИИ не архитектор, а ускоритель нажатия на клавиши.
Интересная работа. Была такая же у меня, только совместно с панорамными снимками там изучались и панорамные реформаты из CBCT (КТ). Превратить CBCT в адекватную панораму в автоматическом режиме, тот ещё квест, особенно учитывая изменчивость анатомии зубной дуги с возрастом. И да, для ассистента врача всё упирается в качественную модель распознавания патологии. С моделью есть нюанс - если использовать её на другом домене снимков, отличном от того, на котором проводилось обучение, то результаты начинают плавать. То есть модель обученная на панорамах будет врать на панорамных реформатах. Как Вы собираетесь решить проблему зависимости от домена?
Я пока не решаюсь выложить его на GitHub. Всё время кажется, что-то не доделано. Видимо нужно привести кодовую базу в порядок и поделиться с людьми :)
У меня есть такая штука. Возможно, почти то, к чему стремится автор. Любые модели локальные и через API. Чаты, генерация картинок, общение голосом, своё PWA, свой SIP-клиент (можно разговаривать по телефону с моделью), набор встроенных скриптов ("руки" модели), если что дописывает их сама по потребности. Оригинальный механизм управления памятью. В общем много там всего. Только вот нет модуля загрузки моделей с HF. Мне как-то и в голову не приходило, что кому-то будет сложно запустить Ollama или LM Studio.
Идея хорошая. Правда нечто похожее есть уже в LM Studio. Но как самостоятельное творчество - почему бы и да :) Несколько замечаний по анализу репозитория:
Нет лицензии. Ни LICENSE, ни указания в README/GitHub — юридически «все права защищены». Переиспользовать этот код — без разрешения автора нельзя. Тогда зачем упоминать репозиторий?
Цепочка поставки движков держится на одном S3-бакете (Timeweb) и одном человеке. Обновления подписаны, а вот сами движки — нет: их целостность = SHA256 в манифесте, который лежит в той же инфраструктуре. Компрометация бакета или машины автора → произвольный код на машинах пользователей. Обновление манифеста из S3 пока вообще не подключено (код
newest()помечен dead_code) — сейчас работает только зашитый манифест, что пока безопаснее.Без подписи Microsoft установка новичка через «Всё равно выполнить» — для целевой аудитории это риск, что люди привыкнут жать эту кнопку на чём попало, плюс подделки под Ollivo никто не отличит.
Локальный llama-server без API-ключа — любой процесс того же пользователя машины может им воспользоваться. Для категории продукта норма (Ollama так же), но формально это дырка в мультипользовательской Windows.
«Авто»-режим папки проекта — модель правит и удаляет файлы без подтверждения. Бэкапы смягчают, но вредоносный документ в папке может подсказать модели что-то удалить; граница «только папка проекта» здесь единственная защита.
Гигиена кода: в
engines.rsзакоммичен настоящий NUL-байт внутри тестовой строки (comfyui\0.37.0— экранирование съело бэкслэш): файл для grep/Read «бинарный», а смысл теста тихо изменился.