IMG-20260625-203428-080.jpg Вот примерную схему накидал, как должен выглядеть современный ai-driven для любого горизонтального масштабирования, включая, бизнес-аналитику, продакшн, ИБ, ресёрч, внешние сервисы. Названия инструментов как пример привел. NoSQL скоро будет маст хэв везде.
Фичевые агенты должны быть stateless в контейнерах, далее надстройки, требующие серверную оперативку: события через условную Kafka, состояния через условный Redis, потом это все оборачивается в feature-store и валидируется единственным и окончательным фидбеком человека RLHF дообучением, которое так же попадает в первоначальное хранилище данных, откуда агенты снова берут новую информацию. А если все в statefull агентике генерить и тестить и затем мержить, то у вас каждый мерж все токены и бабки съест, наслышан про джиру) рекомендую юзать confluence как нативный offline store/rag для джиры, без всяких фичей в агентике. У atlassian есть модуль/плагин для confluens в виде векторного хранилища, если мне память не изменяет, настраивайте все там.
deepseek поясняет: · Агенты — фильтры первого уровня (синтаксис, стиль, тесты, типовые уязвимости). · Kafka + Redis — обеспечивают асинхронность и состояние без привязки к сессиям. · Feature store — аккумулирует все метрики и контекст для принятия решений. · Человек — подключается только к сложным кейсам (бизнес-логика, безопасность, архитектура). · RLHF-фидбек — замыкает контур: данные от человека уходят в дообучение, модели улучшаются, и следующий цикл требует ещё меньше ручного вмешательства.
Чтобы первая настройка не превратилась в хаос, заложите:
Чёткие границы ответственности агентов (зафиксируйте в промптах/инструкциях).
Сбор обратной связи от человека в структурированном виде (не просто комментарии, а размеченные категории).
Мониторинг ключевых метрик: время от коммита до мёржа, доля авто-одобренных PR, частота возвратов на доработку.
Периодическую ревизию — пересматривайте, какие задачи делегировать агентам по мере их дообучения.
Когда это настроено — масштабирование сводится к увеличению числа подов, а человек остаётся только финальным арбитром.
Есть определенная стилизация кода, и там все на English, поэтому либо пишите по общепринятому стилю на английском, либо дообучите модель на dense преобразование, чтобы он взял целый проект (full context) + сделал анализ (каждую строчку кода , каждый класс и объект), а затем выписал это все списком в отдельный .md себе.
link - ссылка
button - кнопка
Но лучше первый вариант, потому что рано или поздно он все равно периодически будет писать как его обучили на уровне тензоров.
Еще вариант - сменить LLM, авось другая обучалась на коде в кириллице
а md для чего? Впринципе не проблема так сделать. У меня там ChromaDB при нахождении чанка возвращает весь документ целиком, я посчитал, что для регуляторки это то, что нужно и md тут лишний, т.к метаданные из доков нужны минимальные (номера, заголовки, пункты, типизированные обозначения и названия), а основное выполнение энкодера будет ориентироваться на dense/lexical. Документы - ГОСТы скачанные с Консультант+ с мусором и банерами и кривыми кодировками внутри доков. То есть они очищаются и могут лежать в оюбом формате doc/md/txt/json/pdf. У меня там docx. Сейчас такой RAG уже во всех IDE есть в виде встроенной тулзы - добавление документаций в контекст модели, вот там .md как раз must have
Вопрос знатокам, а ведь можно же расширить model context (который 32k) до условных 128k, задействуя не VRAM видеокарты, а RAM/Nvme?
GPU Direct Storage/HiFC - это тут применимо вообще? Скорость t/s вообще не важна, главное чтобы слабое железо тянуло сложные задачи. Или все-таки порекомендуете лучше думать в сторону выбора другой модели и квантизации? Ну просто 32к это совсем ниочем, функцию написать и задебаждить максимум…
Инструкции из системного промпта берутся, которые всегда сидят в кеше и работают только в stateless (без сохранения состояния модели/без сохранения истории предыдущих запросов). Вы говорите про attention. Снижение температуры как раз на attention влияет, но на моей практике температуру лучше не трогать, а грамотно и кратко составить инструкцию, подбирая каждое слово так, чтобы их векторные представления были далеко друг от друга.
Continue это oss плагин в VS code, в виде чат-интерфейса как и встроенный copilot, но без привязок и лимитов как copilot, а работающий как отдельный агент (инстанс). Ты сам выбираешь, какой llm/cli/backend использовать. Единственное, нужно немножко попариться, чтобы четко настроить backend (mcp/tools/docs/rag и т.д)
в continue можно много инстансов поднять на разных агентах, то есть это полноценный agentic-workflow инструмент, хотя изначально он создавался как авто-комплитер.
Интересный проект, а почему бесплатный? Тенденция в 1С обратная вроде…
Официальных MCP у 1С нету… Есть только кастомные, кривые, которые потом еще самому допиливать придёться. Нужно выкачивать всю документацию их https://its.1c.ru/db/v8std и конвертировать всё в agentskills. Сизифов труд. HTTP открытый вроде. Еще прокси как сервис надо поднимать для аутификации / прямого подключения stdio.
куча кастомных проектов, а через год они выкатят изменения, и все перестанет работать)) и это только конфигурация, а еще есть базы данных OData с коммерческой инфой, их же тоже надо по-хорошему в контексте хранить как-то. Ой, проще на нормальную архитектуру перейти, чем с этим 1С тюкаться. Монолитный динозавровый помет… Надо на S3 переходить потихоньку всем.
Я пришёл к выводу, что для всех этих локальных инференсов всё же нужно юзать универсальный инструмент VS Code + Continue. Все остальные одеяло на себя тащат со всеми этими спецификациями и ограничениями тупыми ради долларов.
Есть мнение, что после окончательной интеграции Цифрового Рубля, Биометрии, и тотальной цифровизации к 2030 году, блокировки постепенно начнут ослаблять.
Помимо хорошей идеи, продукт объективно должен быть в спросе (это самое сложное и мучительное, т.к нужно анализировать всю мировую инфографику, что нереально.
на рынке либо нет аналогов (чт крайне маловероятно), либо же максимум 1 конкурирующий проект существующий, но ты хочешь сделать лучше UX (другая архитектура/фишки/актуальный стек), отняв у него рынок себе.
ты шаришь за отрасль своего продукта (большой бэкграунд)
тебе нужны +1 или +2 энтузиаста в команду, и вам всем нужны знания основ гибкости agile-менеджмента от каждого.
Все остальное (инвестиции, кодинг, монетизация) - это уже технические решаемые вопросы.
В твоем проекте https://vibeling.app/ru (приложение для изучения Английского) - широкая аудитория с большой конкуренцией. Неоднозначный прогнозируемый спрос. 1 шанс из 1кк, что прокнет, я бы не брался за такой проект и сразу бы его похоронил еще в зачатке идеи. Без обид, я субъективно. Но можно добавить новые фишки, которые зайдут, типа голосового ассистента. Нужно говорить голосом, а ии-ассистент будет понимать и анализировать речь юзера. Для такой фишки нужны знания PEFT/TensorFlow Lite/Keras или брать готовые OpenAI Whisper/SpeechBrain/NeMo и башлять за токены. В любом случае, можно довести до ума твой проект, чтобы не начинать новый или вовсе забить и отчаятся, что неправильно. В общем 0% осуждения, 100% понимания.
Большинство пет-проектов начинаются как для изучения стеков-технологий, переростая в MVP, а технологии сейчас каждый день новые + уже есть вайбкодинг для всего этого. Изучение базового менеджмента и бизнес-моделирования - неотъемлемые знания, по мимо технических, которые нуждны для монетизации и лута долларов.
а так не проще? https://arxiv.org/pdf/2606.12683
AGI уже создан с помощью квантовых запутанностей и когерентности на IBM кластере. https://www.youtube.com/watch?v=oW5_CvKDuHM&list=PLv0h9xFwpMaKUTtHdPxZaC47ssIqIqGBS Трансформеры всё - пока! Теперь будем хайпить на кубитах
Это же Вайб-ресёрчинг
Схема для jira, как я её вижу.png
IMG-20260625-203428-080.jpg Вот примерную схему накидал, как должен выглядеть современный ai-driven для любого горизонтального масштабирования, включая, бизнес-аналитику, продакшн, ИБ, ресёрч, внешние сервисы. Названия инструментов как пример привел. NoSQL скоро будет маст хэв везде.
Фичевые агенты должны быть stateless в контейнерах, далее надстройки, требующие серверную оперативку: события через условную Kafka, состояния через условный Redis, потом это все оборачивается в feature-store и валидируется единственным и окончательным фидбеком человека RLHF дообучением, которое так же попадает в первоначальное хранилище данных, откуда агенты снова берут новую информацию. А если все в statefull агентике генерить и тестить и затем мержить, то у вас каждый мерж все токены и бабки съест, наслышан про джиру) рекомендую юзать confluence как нативный offline store/rag для джиры, без всяких фичей в агентике. У atlassian есть модуль/плагин для confluens в виде векторного хранилища, если мне память не изменяет, настраивайте все там.
deepseek поясняет: · Агенты — фильтры первого уровня (синтаксис, стиль, тесты, типовые уязвимости). · Kafka + Redis — обеспечивают асинхронность и состояние без привязки к сессиям. · Feature store — аккумулирует все метрики и контекст для принятия решений. · Человек — подключается только к сложным кейсам (бизнес-логика, безопасность, архитектура). · RLHF-фидбек — замыкает контур: данные от человека уходят в дообучение, модели улучшаются, и следующий цикл требует ещё меньше ручного вмешательства.
Чтобы первая настройка не превратилась в хаос, заложите:
Чёткие границы ответственности агентов (зафиксируйте в промптах/инструкциях).
Сбор обратной связи от человека в структурированном виде (не просто комментарии, а размеченные категории).
Мониторинг ключевых метрик: время от коммита до мёржа, доля авто-одобренных PR, частота возвратов на доработку.
Периодическую ревизию — пересматривайте, какие задачи делегировать агентам по мере их дообучения.
Когда это настроено — масштабирование сводится к увеличению числа подов, а человек остаётся только финальным арбитром.
https://huggingface.co/unsloth/Qwen3.6-27B-MTP-GGUF https://huggingface.co/unsloth/Qwen3.6-35B-A3B-MTP-GGUF
MPT версии qwen - генерит в 2 раза быстрее оригинальной
Есть определенная стилизация кода, и там все на English, поэтому либо пишите по общепринятому стилю на английском, либо дообучите модель на dense преобразование, чтобы он взял целый проект (full context) + сделал анализ (каждую строчку кода , каждый класс и объект), а затем выписал это все списком в отдельный .md себе.
Но лучше первый вариант, потому что рано или поздно он все равно периодически будет писать как его обучили на уровне тензоров.
Еще вариант - сменить LLM, авось другая обучалась на коде в кириллице
8Gb VRAM
16Gb RAM
250Gb Nvme
Реально вообще qwen3.6 MoE запустить в llama.cpp?)
Ща буду пробовать сперва эти модельки, потом уже turboquant и танцы с бубном подключать.
Спасибо за наводку.
почему статью еще не потерли, а автор не в бане?
а md для чего? Впринципе не проблема так сделать. У меня там ChromaDB при нахождении чанка возвращает весь документ целиком, я посчитал, что для регуляторки это то, что нужно и md тут лишний, т.к метаданные из доков нужны минимальные (номера, заголовки, пункты, типизированные обозначения и названия), а основное выполнение энкодера будет ориентироваться на dense/lexical. Документы - ГОСТы скачанные с Консультант+ с мусором и банерами и кривыми кодировками внутри доков. То есть они очищаются и могут лежать в оюбом формате doc/md/txt/json/pdf. У меня там docx. Сейчас такой RAG уже во всех IDE есть в виде встроенной тулзы - добавление документаций в контекст модели, вот там .md как раз must have
Вопрос знатокам, а ведь можно же расширить model context (который 32k) до условных 128k, задействуя не VRAM видеокарты, а RAM/Nvme?
GPU Direct Storage/HiFC - это тут применимо вообще? Скорость t/s вообще не важна, главное чтобы слабое железо тянуло сложные задачи. Или все-таки порекомендуете лучше думать в сторону выбора другой модели и квантизации? Ну просто 32к это совсем ниочем, функцию написать и задебаждить максимум…
Инструкции из системного промпта берутся, которые всегда сидят в кеше и работают только в stateless (без сохранения состояния модели/без сохранения истории предыдущих запросов). Вы говорите про attention. Снижение температуры как раз на attention влияет, но на моей практике температуру лучше не трогать, а грамотно и кратко составить инструкцию, подбирая каждое слово так, чтобы их векторные представления были далеко друг от друга.
Лучше киньте боевой пример, я наглядно вам покажу
Continue это oss плагин в VS code, в виде чат-интерфейса как и встроенный copilot, но без привязок и лимитов как copilot, а работающий как отдельный агент (инстанс). Ты сам выбираешь, какой llm/cli/backend использовать. Единственное, нужно немножко попариться, чтобы четко настроить backend (mcp/tools/docs/rag и т.д)
в continue можно много инстансов поднять на разных агентах, то есть это полноценный agentic-workflow инструмент, хотя изначально он создавался как авто-комплитер.
Интересный проект, а почему бесплатный? Тенденция в 1С обратная вроде…
Официальных MCP у 1С нету… Есть только кастомные, кривые, которые потом еще самому допиливать придёться. Нужно выкачивать всю документацию их https://its.1c.ru/db/v8std и конвертировать всё в agentskills. Сизифов труд. HTTP открытый вроде. Еще прокси как сервис надо поднимать для аутификации / прямого подключения stdio.
UPD: ну вот же
https://github.com/Nikolay-Shirokov/cc-1c-skills https://github.com/johnnyshut/1c-its-parser-py
куча кастомных проектов, а через год они выкатят изменения, и все перестанет работать)) и это только конфигурация, а еще есть базы данных OData с коммерческой инфой, их же тоже надо по-хорошему в контексте хранить как-то. Ой, проще на нормальную архитектуру перейти, чем с этим 1С тюкаться. Монолитный динозавровый помет… Надо на S3 переходить потихоньку всем.
Автор, в целом все грамотно настроил, но у тебя reasoning не работал на Квене нормально потому что:
Qwen3-Coder 30B-A3B coder не поддерживает режима Thinking/Reasoning, но у нее огромный контекст (256К-1М) поправь для неё ещё:
Qwen 3.5/3.6 35B-A3B qwen использует chatML для jinja, нужно добавить параметр в llama
UPD: или просто скачай фикс, вышел недавно:
https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates
Попробуй еще вот эту модельку:
https://huggingface.co/froggeric/Qwen3.6-27B-MTP-GGUF потом расскажешь, как она.
Я пришёл к выводу, что для всех этих локальных инференсов всё же нужно юзать универсальный инструмент VS Code + Continue. Все остальные одеяло на себя тащат со всеми этими спецификациями и ограничениями тупыми ради долларов.
Есть мнение, что после окончательной интеграции Цифрового Рубля, Биометрии, и тотальной цифровизации к 2030 году, блокировки постепенно начнут ослаблять.
для успешного стартапа нужны несколько факторов:
Помимо хорошей идеи, продукт объективно должен быть в спросе (это самое сложное и мучительное, т.к нужно анализировать всю мировую инфографику, что нереально.
на рынке либо нет аналогов (чт крайне маловероятно), либо же максимум 1 конкурирующий проект существующий, но ты хочешь сделать лучше UX (другая архитектура/фишки/актуальный стек), отняв у него рынок себе.
ты шаришь за отрасль своего продукта (большой бэкграунд)
тебе нужны +1 или +2 энтузиаста в команду, и вам всем нужны знания основ гибкости agile-менеджмента от каждого.
Все остальное (инвестиции, кодинг, монетизация) - это уже технические решаемые вопросы.
В твоем проекте https://vibeling.app/ru (приложение для изучения Английского) - широкая аудитория с большой конкуренцией. Неоднозначный прогнозируемый спрос. 1 шанс из 1кк, что прокнет, я бы не брался за такой проект и сразу бы его похоронил еще в зачатке идеи. Без обид, я субъективно. Но можно добавить новые фишки, которые зайдут, типа голосового ассистента. Нужно говорить голосом, а ии-ассистент будет понимать и анализировать речь юзера. Для такой фишки нужны знания PEFT/TensorFlow Lite/Keras или брать готовые OpenAI Whisper/SpeechBrain/NeMo и башлять за токены. В любом случае, можно довести до ума твой проект, чтобы не начинать новый или вовсе забить и отчаятся, что неправильно. В общем 0% осуждения, 100% понимания.
Большинство пет-проектов начинаются как для изучения стеков-технологий, переростая в MVP, а технологии сейчас каждый день новые + уже есть вайбкодинг для всего этого. Изучение базового менеджмента и бизнес-моделирования - неотъемлемые знания, по мимо технических, которые нуждны для монетизации и лута долларов.
google ai studio: n8n -> profiles -> share.
yandex ai studio: agent atelier -> статья автора.
Вот пример: гранты Яндекса на пользование их сервисом DataSphere для студентов.