Forwarded from ITипичные аспекты Артёма
4/5 пост, дальше только выводы
предыдущее
Пятница, 12ч
Realtime транскрипт, правки, сущности, баги, рефакторинг
Я надеялся в пятницу уже получить полностью рабочую сборку, но оставалось слишком много дел по работе системы, google extension ещё и не был начат.
Зафиксировал опоздание в день.
По привычке закопался в алгоритм и протокол realtime транскрибации - как копить буфер, корректировать транскрипт на лету. Закопаться нормально при классической разработке, но непозволительно в условиях интенсива. Стало ещё одной моей крупной ошибкой, стоившей 6 часов. Но хотя бы отловил пару проблем в процессе.
Инсайты
- На примере realtime протокола, ИИ не может алгоритмический код без очень точного описания.
Напутать индексацию пакета, поставить условие сброса кэша туда, куда его ставить НЕЛЬЗЯ, забыть, как используются счётчики. Ещё засунуть открытый сокет в хранилище сокетов сессий и получить обсёр в моменте, когда фронт отсоединяется первым от "активной" сессии... Напомню, что чем больше ты его поправляешь тем хуже становится код.
По итогу всю эту часть я делал ручками. Вдумчиво и внимательно.
- ИИ в общем случае очень плохо пишет схемы данных без очень конкретного аналитического описания. Легче продумать самому, а ИИ уже отдать на интеграцию.
Это в целом хорошая гигиеническая практика - Писать HLD и примерную схему данных до начала разработки.
Суббота, 8 часов
Гугл расширение, минификсы и завершение этапа проекта
Абсолютно новый для меня зверь. Без ИИ я такое расширение написать физически бы не смог. Поработал скорее как аналитик - где в первую очередь нужно описать и донести, что ты хочешь, подсобрать ожидания и хотелки хотя бы у себя в голове.
Так как осталось время, запилил допфичу по шерингу транскриптов наподобии гугл доков.
ИИ умудрился сломаться на несложном расширении модели БД, но с полпинка починился и адекватно написал миграцию.
Инсайты
- Структурированное МиниТЗ с просьбой составить план изменения, а потом ему следовать - хороший способ брать в выполнение сложные фичи
- ИИ владеет хорошей базой знаний по технологиям. Если перед реализацией в коде обсудить-посёрчить через него варианты, это может дать качественное решение
- Эмодзи в логах это на удивление прекрасно, если их не становится слишком много. Надо взять себе в боевые практики. С визуально-цветовыми ассоциациями проще выхватывать нужные моменты в общем потоке
На этом жизнеспособном этапе я закрыл активную разработку и все основные задачи интенсива. Дальше оставалось подведение итогов и горделивая беготня с демонстрациями во всех инстанциях.
Спустя неделю тестов на людях в гугл расширении обнаружилась критичнейшая вещь, очень подло и бесследно дропавшая запись спустя 20-40мин от начала.
ИИ по косвенным репортам и логам не справился - также пришлось погружаться самому. Теперь я знаю и умею вытворять с хромиум браузером гораздо больше интересных вещей.
П.с. извиняюсь за качество демок. Изначально они предназначались для околорабочих чатиков. NDAшу как могу.
предыдущее
Пятница, 12ч
Realtime транскрипт, правки, сущности, баги, рефакторинг
Я надеялся в пятницу уже получить полностью рабочую сборку, но оставалось слишком много дел по работе системы, google extension ещё и не был начат.
Зафиксировал опоздание в день.
По привычке закопался в алгоритм и протокол realtime транскрибации - как копить буфер, корректировать транскрипт на лету. Закопаться нормально при классической разработке, но непозволительно в условиях интенсива. Стало ещё одной моей крупной ошибкой, стоившей 6 часов. Но хотя бы отловил пару проблем в процессе.
Инсайты
- На примере realtime протокола, ИИ не может алгоритмический код без очень точного описания.
Напутать индексацию пакета, поставить условие сброса кэша туда, куда его ставить НЕЛЬЗЯ, забыть, как используются счётчики. Ещё засунуть открытый сокет в хранилище сокетов сессий и получить обсёр в моменте, когда фронт отсоединяется первым от "активной" сессии... Напомню, что чем больше ты его поправляешь тем хуже становится код.
По итогу всю эту часть я делал ручками. Вдумчиво и внимательно.
- ИИ в общем случае очень плохо пишет схемы данных без очень конкретного аналитического описания. Легче продумать самому, а ИИ уже отдать на интеграцию.
Это в целом хорошая гигиеническая практика - Писать HLD и примерную схему данных до начала разработки.
Суббота, 8 часов
Гугл расширение, минификсы и завершение этапа проекта
Абсолютно новый для меня зверь. Без ИИ я такое расширение написать физически бы не смог. Поработал скорее как аналитик - где в первую очередь нужно описать и донести, что ты хочешь, подсобрать ожидания и хотелки хотя бы у себя в голове.
Так как осталось время, запилил допфичу по шерингу транскриптов наподобии гугл доков.
ИИ умудрился сломаться на несложном расширении модели БД, но с полпинка починился и адекватно написал миграцию.
Инсайты
- Структурированное МиниТЗ с просьбой составить план изменения, а потом ему следовать - хороший способ брать в выполнение сложные фичи
- ИИ владеет хорошей базой знаний по технологиям. Если перед реализацией в коде обсудить-посёрчить через него варианты, это может дать качественное решение
- Эмодзи в логах это на удивление прекрасно, если их не становится слишком много. Надо взять себе в боевые практики. С визуально-цветовыми ассоциациями проще выхватывать нужные моменты в общем потоке
На этом жизнеспособном этапе я закрыл активную разработку и все основные задачи интенсива. Дальше оставалось подведение итогов и горделивая беготня с демонстрациями во всех инстанциях.
Спустя неделю тестов на людях в гугл расширении обнаружилась критичнейшая вещь, очень подло и бесследно дропавшая запись спустя 20-40мин от начала.
ИИ по косвенным репортам и логам не справился - также пришлось погружаться самому. Теперь я знаю и умею вытворять с хромиум браузером гораздо больше интересных вещей.
П.с. извиняюсь за качество демок. Изначально они предназначались для околорабочих чатиков. NDAшу как могу.
Forwarded from Dealer.AI
Гибридизируй это - память.
Как я и говорил гибридизация механизмов памяти это будущее. Теперь уже и настоящее.
Подобно memGPT (про память, а не мемы😀 ), коллеги из Китая пошли в операционку с памятью. Очень интересная работа.
https://t.me/chinaaichannel/167
+ выкладываю свою презу по памяти для LLM на datafest (будет ниже).
Видео залиты сами знаете куда. Мое выступление с 1:33:00 примерно.
Как я и говорил гибридизация механизмов памяти это будущее. Теперь уже и настоящее.
Подобно memGPT (про память, а не мемы
https://t.me/chinaaichannel/167
+ выкладываю свою презу по памяти для LLM на datafest (будет ниже).
Видео залиты сами знаете куда. Мое выступление с 1:33:00 примерно.
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Китай.AI
🔥 MemOS: революция в управлении памятью для ИИ от китайских разработчиков
Китайские исследователи представили MemOS — первую операционную систему для управления долговременной памятью у больших языковых моделей. Система превзошла решения OpenAI по ключевым…
Китайские исследователи представили MemOS — первую операционную систему для управления долговременной памятью у больших языковых моделей. Система превзошла решения OpenAI по ключевым…
Forwarded from Dealer.AI
Reinforcement Pretraining Learning от Microsoft - новый взгляд на предобучение.
RPT - это новый подход для дообучение моделей на основе рассуждений с RL.
Как это работает? 💡
Ранее, мы использовали старую схему: предобучение, инструктивный тюнинг и выравнивание. Далее DeepSeek привнёс дополнительно методологию предобучения+RL тюнинга, без итерации SFT.
Однако, Microsoft пошли дальше. Мы делаем предобучение модели с задачей next token prediction, а далее делаем дополнительный шаг к дообучению (допредобучению) с использованием формата рассуждений для предсказания следующего токена. Да, да, с использованием спец.форматов thinking tokens и т.п. (ниже будет скрин формата). При этом, откуда взялся RL тут? Да все просто – ввиду моды на GRPO и задач, которые сами порождают себе награду, из-за своего известного ответа. Ведь для задач предсказания токена мы уже также имеем нужную разметку. Поясню, у нас есть тренировочный опорный текст, его мы нарезаем на контекст + следующий токен, так мы делаем teacher forcing. Отсюда награду на этапе RPT будем давать за правильно предсказанный токен с GRPO, а не юзать CCE loss.Кстати, очень похоже на подходик с RTD (replaced token detection) для обучения ELECTRA, помните такую?
Вот и вся идея: берем претрейн+rpt, далее уже че хотим, то и воротим. Можно следом сделать RL SFT, и авторы этот эксперимент проводят и показывают, что такой RPT "отжиг"(почему-то с ним аналогия, хотя у отжига есть условие соблюдения чистоты и частоты разметки к претрен сырцу) , естественно, улучшает качество тюна дальнейшего с RL. Все логично, мы же уже подготовили почву через обучение сродственное.
Отсюда вообще много чего, интересного можно натворить. Взять и сделать реально аналог отжига, но на RPT подходе, прям по всем правилам и требованиям к датке, но с функцией цели в виде GRPO. Можно генерить разметку претрен сета в виде рассуждений при помощи reasoning моделек, создавая уже RPT синту. Далее пойти в DeepSeek R1 пайп. Написать сначала людьми разметку под токены рассуждений, потом обучить опорную свою RPT модельку, ее использовать для рефайна сета претрен. Получив синту с нужной разметкой, отобрать ту синту, для которой энтропия/перплексия минимальная (отобрать лучшие примеры), и вкинуть уже в модель второго уровня на пайплайн: претрен, rpt с синтой, rl sft и т. д. по аналогии с R1 пайпом после ZeroStage.
Кстати, авторы показали не только хорошую интеграцию с RL sft, но и правила скейлинга качества для разного уровня сложности задач на рассуждения, на примере задач математики. Туда же долили замеры QA и MMLU и тоже показали ап.🌿
К тому же, 14b моделька Qwen с RPT заняла место между NTP 14b и 32b.📈
В общем, читайте статью и пробуйте.
RPT - это новый подход для дообучение моделей на основе рассуждений с RL.
Как это работает? 💡
Ранее, мы использовали старую схему: предобучение, инструктивный тюнинг и выравнивание. Далее DeepSeek привнёс дополнительно методологию предобучения+RL тюнинга, без итерации SFT.
Однако, Microsoft пошли дальше. Мы делаем предобучение модели с задачей next token prediction, а далее делаем дополнительный шаг к дообучению (допредобучению) с использованием формата рассуждений для предсказания следующего токена. Да, да, с использованием спец.форматов thinking tokens и т.п. (ниже будет скрин формата). При этом, откуда взялся RL тут? Да все просто – ввиду моды на GRPO и задач, которые сами порождают себе награду, из-за своего известного ответа. Ведь для задач предсказания токена мы уже также имеем нужную разметку. Поясню, у нас есть тренировочный опорный текст, его мы нарезаем на контекст + следующий токен, так мы делаем teacher forcing. Отсюда награду на этапе RPT будем давать за правильно предсказанный токен с GRPO, а не юзать CCE loss.
Вот и вся идея: берем претрейн+rpt, далее уже че хотим, то и воротим. Можно следом сделать RL SFT, и авторы этот эксперимент проводят и показывают, что такой RPT "отжиг"
Отсюда вообще много чего, интересного можно натворить. Взять и сделать реально аналог отжига, но на RPT подходе, прям по всем правилам и требованиям к датке, но с функцией цели в виде GRPO. Можно генерить разметку претрен сета в виде рассуждений при помощи reasoning моделек, создавая уже RPT синту. Далее пойти в DeepSeek R1 пайп. Написать сначала людьми разметку под токены рассуждений, потом обучить опорную свою RPT модельку, ее использовать для рефайна сета претрен. Получив синту с нужной разметкой, отобрать ту синту, для которой энтропия/перплексия минимальная (отобрать лучшие примеры), и вкинуть уже в модель второго уровня на пайплайн: претрен, rpt с синтой, rl sft и т. д. по аналогии с R1 пайпом после ZeroStage.
Кстати, авторы показали не только хорошую интеграцию с RL sft, но и правила скейлинга качества для разного уровня сложности задач на рассуждения, на примере задач математики. Туда же долили замеры QA и MMLU и тоже показали ап.
К тому же, 14b моделька Qwen с RPT заняла место между NTP 14b и 32b.
В общем, читайте статью и пробуйте.
Please open Telegram to view this post
VIEW IN TELEGRAM
huggingface.co
Paper page - Reinforcement Pre-Training
Join the discussion on this paper page
Forwarded from Dealer.AI
Manus: "Agents and in-context learning is all you need for it."
Пристально слежу за развитиемцыганских агентов от Мануш (на самом деле Манус 😂 ). И в их блоге, недавно, отсыпало весьма классный пост про опыт и видение настоящего и будущего работы с агентами. А именно, в статье команда авторов делится хаками для интеракций агентов.
У команды был долгий опыт с NLP и связанные с этим дилеммы для проекта Manus: учить ли свои модели или использовать всю мощь in-context инженерии. Ввиду большого time to market для задач, связанных с тюном моделей, их выбор пал на гибкое, быстрое и масштабируемое решение в виде своей адаптации in-context learning для агентов.
Мне очень импонирует, что эти ребята делают свою агентную систему круче OpenAI, при этом, основываясь, на уже казалось бы затертых до дыр, концептах function calling и rag/in-context learning (engineering как они сами это зовут) + LLMs, разумеется.
Основные столпы их механизмов взаимодействия агентов:
1. Грамотное использование KV-cachig. Как для экономии финансов, так и для быстрого контекстуального ответа.
2. При этом рассматриваются важные аспекты, как не сломать кэширование при масштабировании функций и инструментов, доступных агентам. Ведь новые фичи, как команды и результаты их исполнения, будут попадать в контекст, который они заполняют по определенной стратегии. Поэтому, чтобы не пришлось пересчитывать кэш и не ломать его логику, используется маскирование аля как в constrained output, четкий словарь префиксов, а также пополнение контекста в конце. Еще предупреждают – не стоит вкидывать или удалять новые операции/функции в середину итерации, только после завершения экшена.
3. Приятно, что тут же упомянули, механизмы вызова или добавления функций в виде RAG-механик с description функции, которые аттендятся на контекст. Обычно, это делается через матчинг эмбеддером векторов состояний контекста с описанием действия (функции).
Но учить такой FunctionRanker придется отдельно и ожидать трансфер знаний на лету. Кстати на нашем опыте FRIDA и e5, bge-m3 отлично в zeroshot с этим справляются без дообучения, а с ним и подавно метрики @K летят к 0.99.
4. Использование файловой системы, как памяти. Мое любимое - про память. Авторы предлагают гениально простой способ хранения информации без переполнения локального контекста - в файлах.Кстати, вы можете заметить подобное хранение в памяти от OpenAI. Это позволяет не перегружать контекст LLM, обращаясь только за нужной информацией во вне и сохраняя тоже только нужное, вырезая из контекста, все, что можно положить в файл. При этом, агент сам запишет, куда и в какой файл, что он сохранил.
Тут же, создатель Мануш говорит об ограничениях моделей SSM, которым не хватает внимания ввиду сродства с RNN/LSTM и происходит затухание памяти на длинных контекстах. Именно гибридизация агентов на базе моделей SSM с памятью на file system может породить новый аналог нейронной машины Тьюринга.
Пристально слежу за развитием
У команды был долгий опыт с NLP и связанные с этим дилеммы для проекта Manus: учить ли свои модели или использовать всю мощь in-context инженерии. Ввиду большого time to market для задач, связанных с тюном моделей, их выбор пал на гибкое, быстрое и масштабируемое решение в виде своей адаптации in-context learning для агентов.
Мне очень импонирует, что эти ребята делают свою агентную систему круче OpenAI, при этом, основываясь, на уже казалось бы затертых до дыр, концептах function calling и rag/in-context learning (engineering как они сами это зовут) + LLMs, разумеется.
Основные столпы их механизмов взаимодействия агентов:
1. Грамотное использование KV-cachig. Как для экономии финансов, так и для быстрого контекстуального ответа.
2. При этом рассматриваются важные аспекты, как не сломать кэширование при масштабировании функций и инструментов, доступных агентам. Ведь новые фичи, как команды и результаты их исполнения, будут попадать в контекст, который они заполняют по определенной стратегии. Поэтому, чтобы не пришлось пересчитывать кэш и не ломать его логику, используется маскирование аля как в constrained output, четкий словарь префиксов, а также пополнение контекста в конце. Еще предупреждают – не стоит вкидывать или удалять новые операции/функции в середину итерации, только после завершения экшена.
3. Приятно, что тут же упомянули, механизмы вызова или добавления функций в виде RAG-механик с description функции, которые аттендятся на контекст. Обычно, это делается через матчинг эмбеддером векторов состояний контекста с описанием действия (функции).
Но учить такой FunctionRanker придется отдельно и ожидать трансфер знаний на лету. Кстати на нашем опыте FRIDA и e5, bge-m3 отлично в zeroshot с этим справляются без дообучения, а с ним и подавно метрики @K летят к 0.99.
4. Использование файловой системы, как памяти. Мое любимое - про память. Авторы предлагают гениально простой способ хранения информации без переполнения локального контекста - в файлах.
Тут же, создатель Мануш говорит об ограничениях моделей SSM, которым не хватает внимания ввиду сродства с RNN/LSTM и происходит затухание памяти на длинных контекстах. Именно гибридизация агентов на базе моделей SSM с памятью на file system может породить новый аналог нейронной машины Тьюринга.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Dealer.AI
Manus: "Agents and incontext learning is all you need for it."
Продолжение.
5. Декламация/акцентуация внимания агентов и «lost in the middle». Тут все просто, т.к. основной актор это LLM внутри агентов, то мы наследуем проблемы затухания/размывания внимания. Это происходит из-за того, что агенты совершают несколько десятков действий (50 в случае Манус), которые пишутся в контекст. Чтобы фокус не сбивался, агенты этой системы ведут todo.md, куда пишут план и пометки о его выполнении. Этот чек-лист помещается в конец контекста, для сохранения акцентов на цели. А мы помним, last tokens модели с casual mask "помнят/видят" лучше, чем инфо в самом начале.
6. Сохраняйте ошибки. Кстати, в наших работах с памятью - это работает плохо, но тут есть важный нюанс. Ввиду того, что есть трассировки ошибок, и результаты неверного выполнения логируются, вызывая отличные действия, это помогает в контексте модели видеть верный и неверный путь, отодвигая внимание от последнего.Надо записать для себя. Если бы трассировок не было, то конечно неверные экшны ломали бы контекст, как в нашем случае.
Еще очень важный пойнт авторов тут: "восстановление после ошибки — один из самых явных признаков настоящего агентного поведения." Создатели бенчмарков для агентов, задумайтесь!
7. Бойтесь обыденности. Под этим имеется ввиду, не злоупотребляйте few-shot подсказками или промптами. Повторяющиеся шаблоны "запрос-действие" создают рамки, которые могут быть неоптимальными – вызывать зацикливания или даже галлюцинации. Для того, чтобы избежать такого, авторы вносят шум, перестановки слов и разнообразие в формулировки, через специальные инструкции к агентам (возможно, в тч на уровне систем промптов). Таким образом, в лог контекста попадают парафразы, а не синонимы.
Фух, вроде все. Очень интересный мануал-откровение. Читаем подробно сами и перенимаем для своих агентных систем. Хороших выходных.🙏
Продолжение.
5. Декламация/акцентуация внимания агентов и «lost in the middle». Тут все просто, т.к. основной актор это LLM внутри агентов, то мы наследуем проблемы затухания/размывания внимания. Это происходит из-за того, что агенты совершают несколько десятков действий (50 в случае Манус), которые пишутся в контекст. Чтобы фокус не сбивался, агенты этой системы ведут todo.md, куда пишут план и пометки о его выполнении. Этот чек-лист помещается в конец контекста, для сохранения акцентов на цели. А мы помним, last tokens модели с casual mask "помнят/видят" лучше, чем инфо в самом начале.
6. Сохраняйте ошибки. Кстати, в наших работах с памятью - это работает плохо, но тут есть важный нюанс. Ввиду того, что есть трассировки ошибок, и результаты неверного выполнения логируются, вызывая отличные действия, это помогает в контексте модели видеть верный и неверный путь, отодвигая внимание от последнего.
Еще очень важный пойнт авторов тут: "восстановление после ошибки — один из самых явных признаков настоящего агентного поведения." Создатели бенчмарков для агентов, задумайтесь!
7. Бойтесь обыденности. Под этим имеется ввиду, не злоупотребляйте few-shot подсказками или промптами. Повторяющиеся шаблоны "запрос-действие" создают рамки, которые могут быть неоптимальными – вызывать зацикливания или даже галлюцинации. Для того, чтобы избежать такого, авторы вносят шум, перестановки слов и разнообразие в формулировки, через специальные инструкции к агентам (возможно, в тч на уровне систем промптов). Таким образом, в лог контекста попадают парафразы, а не синонимы.
Фух, вроде все. Очень интересный мануал-откровение. Читаем подробно сами и перенимаем для своих агентных систем. Хороших выходных.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Refat Talks: Tech & AI
This media is not supported in your browser
VIEW IN TELEGRAM
30 минут автоматики против 90% уязвимостей в AI (да и не только) коде
AI-кодинг это круто, но он демократизирует не только разработку, но и дыры в безопасности. Claude с Cursor генерят код быстро, но про секьюрити они думают в последнюю очередь. Да и не только в них дело, люди также ошибаются.
Почему это важно вы и сами понимаете, рисков очень много: неопытный разработчик увлекся прототипом и закомитил API ключ прямо в коде, AI затащил устаревшие версии пакетов по старой памяти, а они сегодня имеют уязвимости, кто-то скопировал небезопасные конфиги из туториалов, а одна опечатка может незаметно образовать дыру в безопастности.
Хорошие новости: за полчаса можно настроить автоматику, которая закроет 90% стандартных проблем с безопасностью. Это не значит что вам не нужно обращаться к экспертам и самим глубже в этом разбираться, просто это тот случай когда хоть что-то сильно лучше чем ноль.
Основные инструменты (все бесплатные)
Детекция секретов:
- GitLeaks - ловит API-ключи, пароли и токены до коммита
- TruffleHog - продвинутое сканирование с проверкой
Сканирование уязвимостей:
- Semgrep - находит инъекции, обходы аутентификации, логические дыры
- Bandit (Python) - секьюрити-проблемы в питоне
- ESLint Security (JavaScript) - XSS, прототипное загрязнение, небезопасные паттерны
Безопасность зависимостей:
- Safety (Python) - сканирует уязвимые пакеты
- npm audit (JavaScript) - встроенный сканер уязвимостей Node.js
Менеджеры хуков (самая важная часть):
- Pre-commit - универсальный менеджер git-хуков для любых языков (рекомендую)
- Husky - популярная альтернатива для Node.js проектов
- Lefthook - быстрая альтернатива на Go
В каждой из этих категорий есть много альтернатив в том числе платных, есть SonarQube, есть snyk и т.д.
Стратегия быстрого внедрения
Фаза 1: Локальная разработка
Настраиваете pre-commit хуки, которые ловят проблемы до коммита в репозиторий
Фаза 2: CI/CD интеграция
Добавляете GitHub Actions, Gitlab CI/CD и тд для того, что могли пропустить локальные проверки - это best practice
Автоматическая настройка с AI
Disclaimer: Это не снимает с тебя ответственности за то чтобы разбираться подробнее, но даст быстрый старт.
Пример промпта чтобы написать его в Cursor / Claude Code и тд:
Ваш AI-агент проанализирует кодовую базу и создаст настроенную под ваш проект систему проверки безопасности кода за минуты.
Эта настройка ловит уязвимости, которые вызывают 90% утечек данных:
- Утечка учетных данных: API-ключи, пароли БД, JWT-секреты
- Инъекционные атаки: SQL-инъекции, command injection, XSS
- Уязвимые зависимости: устаревшие пакеты с известными CVE
- Небезопасные конфигурации: слабая аутентификация, открытые эндпойнты
- Утечки данных: хардкод чувствительной информации
Сами проверки не занимают много времени (секунды), они запускаются параллельно, умеют чекать только измененные файлы и т.д.
Эта настройка - стартовая точка, не финиш. Начните с "достаточно хорошо" сегодня, улучшайте со временем, и вы будете впереди подавляющего числа приложений, которые шипятся вообще без проверок безопасности.
Если хотя бы несколько начинающих разработчиков или молодых команд внедрят эти чеки после прочтения поста - это уже огромная победа. Поэтому 🔥➕🔁
AI-кодинг это круто, но он демократизирует не только разработку, но и дыры в безопасности. Claude с Cursor генерят код быстро, но про секьюрити они думают в последнюю очередь. Да и не только в них дело, люди также ошибаются.
Почему это важно вы и сами понимаете, рисков очень много: неопытный разработчик увлекся прототипом и закомитил API ключ прямо в коде, AI затащил устаревшие версии пакетов по старой памяти, а они сегодня имеют уязвимости, кто-то скопировал небезопасные конфиги из туториалов, а одна опечатка может незаметно образовать дыру в безопастности.
Хорошие новости: за полчаса можно настроить автоматику, которая закроет 90% стандартных проблем с безопасностью. Это не значит что вам не нужно обращаться к экспертам и самим глубже в этом разбираться, просто это тот случай когда хоть что-то сильно лучше чем ноль.
Основные инструменты (все бесплатные)
Детекция секретов:
- GitLeaks - ловит API-ключи, пароли и токены до коммита
- TruffleHog - продвинутое сканирование с проверкой
Сканирование уязвимостей:
- Semgrep - находит инъекции, обходы аутентификации, логические дыры
- Bandit (Python) - секьюрити-проблемы в питоне
- ESLint Security (JavaScript) - XSS, прототипное загрязнение, небезопасные паттерны
Безопасность зависимостей:
- Safety (Python) - сканирует уязвимые пакеты
- npm audit (JavaScript) - встроенный сканер уязвимостей Node.js
Менеджеры хуков (самая важная часть):
- Pre-commit - универсальный менеджер git-хуков для любых языков (рекомендую)
- Husky - популярная альтернатива для Node.js проектов
- Lefthook - быстрая альтернатива на Go
В каждой из этих категорий есть много альтернатив в том числе платных, есть SonarQube, есть snyk и т.д.
Стратегия быстрого внедрения
Фаза 1: Локальная разработка
Настраиваете pre-commit хуки, которые ловят проблемы до коммита в репозиторий
Фаза 2: CI/CD интеграция
Добавляете GitHub Actions, Gitlab CI/CD и тд для того, что могли пропустить локальные проверки - это best practice
Автоматическая настройка с AI
Disclaimer: Это не снимает с тебя ответственности за то чтобы разбираться подробнее, но даст быстрый старт.
Пример промпта чтобы написать его в Cursor / Claude Code и тд:
Analyze this project and set up a performance-optimized pre-commit security configuration using only open-source tools (GitLeaks, Bandit, ESLint Security, Safety, Semgrep) to implement SAST, secrets detection, and dependency vulnerability scanning. Auto-detect project languages, install pre-commit with appropriate security hooks, configure parallel execution and file filtering for speed, create IDE integration files, and test the complete setup. Focus on preventing credential exposure, injection vulnerabilities, hardcoded secrets, insecure dependencies, and OWASP Top 10 issues with high-impact, low-false-positive detection. Document the entire setup process, configuration details.
Ваш AI-агент проанализирует кодовую базу и создаст настроенную под ваш проект систему проверки безопасности кода за минуты.
Эта настройка ловит уязвимости, которые вызывают 90% утечек данных:
- Утечка учетных данных: API-ключи, пароли БД, JWT-секреты
- Инъекционные атаки: SQL-инъекции, command injection, XSS
- Уязвимые зависимости: устаревшие пакеты с известными CVE
- Небезопасные конфигурации: слабая аутентификация, открытые эндпойнты
- Утечки данных: хардкод чувствительной информации
Сами проверки не занимают много времени (секунды), они запускаются параллельно, умеют чекать только измененные файлы и т.д.
Эта настройка - стартовая точка, не финиш. Начните с "достаточно хорошо" сегодня, улучшайте со временем, и вы будете впереди подавляющего числа приложений, которые шипятся вообще без проверок безопасности.
Если хотя бы несколько начинающих разработчиков или молодых команд внедрят эти чеки после прочтения поста - это уже огромная победа. Поэтому 🔥➕🔁
Forwarded from Датавиз в BI • Алиса Ручкина
Подборка прожарок
В предыдущем посте про референсы я упомянула формат прожарок дашбордов.
Сделала подборку прожарок🔥 по разным BI-инструментам:
Tableau — Прожарка на английском языке от Романа Бунина и Александра Баракова. Варианты перевёрстки дашборда можно посмотреть на доске в Miro
Power BI — Разбор дашборда, собранного в Power BI, от Алексея Колоколова
FineBI — Фрагмент онлайн-встречи Fine Talks
AW BI — Запись эфира «Прожарка» конкурсных дашбордов Analytic Workspace
Yandex DataLens — Топ-3 частых ошибок в конкурсных работах Yandex DataLens Festival 2024
PIX BI — Дашборд на прокачку, или PIX Красивое
Looker Studio — Митап Романа Бунина про основы дизайна для аналитиков и перевёрстка дашборда
PolyAnalyst — Прожарка отчета по продажам
❓Какие прожарки вы ещё видели?
Дополняйте в комментариях!
#подборка #дашборд
Датавиз в BI • Алиса Ручкина
В предыдущем посте про референсы я упомянула формат прожарок дашбордов.
Сделала подборку прожарок🔥 по разным BI-инструментам:
Tableau — Прожарка на английском языке от Романа Бунина и Александра Баракова. Варианты перевёрстки дашборда можно посмотреть на доске в Miro
Power BI — Разбор дашборда, собранного в Power BI, от Алексея Колоколова
FineBI — Фрагмент онлайн-встречи Fine Talks
AW BI — Запись эфира «Прожарка» конкурсных дашбордов Analytic Workspace
Yandex DataLens — Топ-3 частых ошибок в конкурсных работах Yandex DataLens Festival 2024
PIX BI — Дашборд на прокачку, или PIX Красивое
Looker Studio — Митап Романа Бунина про основы дизайна для аналитиков и перевёрстка дашборда
PolyAnalyst — Прожарка отчета по продажам
❓Какие прожарки вы ещё видели?
Дополняйте в комментариях!
#подборка #дашборд
Датавиз в BI • Алиса Ручкина
Forwarded from topdatalab (Roman Zykov)
Примерно месяц назад я переехал на Cursor и очень доволен скоростью ответов.
Неделю назад я прочитал статью на английском, как он собственно устроен и как развивался.
Перевод на русский здесь:
часть 1 https://habr.com/ru/articles/919636/
часть 2 https://habr.com/ru/articles/920660/
В целом там все очень интересно описано, особенно про индексацию кодовой базы.
Но меня лично заинтересовал упомянутый там проект, который спас Cursor от падения
https://turbopuffer.com
Ребята делают full text search и поиск по embedding, что является основой любой RAG.
Они отказались от БД в пользу S3.
Цены не скажу что высокие, буду пробовать их сам. Уж больно они хороши (из истории Cursor)
А так рецепт следующий Postgres + pg_search + pg_vector
У меня это все крутится на Corpsignals.com
Неделю назад я прочитал статью на английском, как он собственно устроен и как развивался.
Перевод на русский здесь:
часть 1 https://habr.com/ru/articles/919636/
часть 2 https://habr.com/ru/articles/920660/
В целом там все очень интересно описано, особенно про индексацию кодовой базы.
Но меня лично заинтересовал упомянутый там проект, который спас Cursor от падения
https://turbopuffer.com
Ребята делают full text search и поиск по embedding, что является основой любой RAG.
Они отказались от БД в пользу S3.
Цены не скажу что высокие, буду пробовать их сам. Уж больно они хороши (из истории Cursor)
А так рецепт следующий Postgres + pg_search + pg_vector
У меня это все крутится на Corpsignals.com
Forwarded from Katherine
Лекции с A/B Week от ШАД (которая прошла 21-25.07.2025) было здорово - очень подробно и доступно.
Недавно начала проходить симулятор AB от karpov.courses. Так вот Диля Хакимова рассказала за неделю примерно половину из того, что дается в karpov.courses, и совершенно бесплатно.
Недавно начала проходить симулятор AB от karpov.courses. Так вот Диля Хакимова рассказала за неделю примерно половину из того, что дается в karpov.courses, и совершенно бесплатно.
Forwarded from Data Secrets
Learning without training: разбираем новую крайне интересную статью от Google
Смотрите, все мы знаем, что если модели в промпте показать несколько примеров решения похожих задач, то она может легко подхватить паттерн, и качество ответов станет лучше. При этом веса модели, естественно, не меняются.
Это называется in‑context learning (ICL), но вот вам fun fact: никто до сих пор до конца не знает, почему это работает, и как трансформер это делает.
И вот в этой статье авторы предлагают почти революционную гипотезу – что на самом деле веса меняются, просто иначе, чем мы привыкли.
То есть на самом деле внутри блока трансформера происходит нечто похожее на файнтюнинг, только не через градиенты, а за счёт самой механики self‑attention и MLP. Идея сводится к следующему:
1. Контекст порождает локальные изменения активаций, и когда вы добавляете примеры в промпт, self‑attention пересчитывает эмбеддинги токенов так, что после этого они зависят от всего контекста. Разницу между «чистыми» активациями и активациями с учётом примеров можно назвать контекстным сдвигом. Это все известные вещи.
2. А вот дальше зарыта собака: оказывается, MLP превращает этот контекстный сдвиг в ранг‑1 обновление весов. Иначе говоря, если посмотреть на первый линейный слой MLP (матрицу W), то влияние дополнительных примеров эквивалентно тому, что эту самую матрицу дополняют маленькой поправкой ранга 1.
Причем эта поправка описывается достаточно простой формулой. То есть если мы берем оригинальные веса и вручную добавляем к ним эту поправку, модель без контекста выдаст то же самое, что и оригинал с контекстом. Но всё это происходит во время инференса, без обратного прохода и без изменения глобальных моделей параметров.
Получается, Google буквально дают ключ к возможному обучению без градиентного спуска. Если такие ранг‑1 апдейты научиться усиливать или контролировать, это может быть началом абсолютно новых архитектур.
Почитать полностью можно тут -> arxiv.org/abs/2507.16003 (осторожно, много математики)
Смотрите, все мы знаем, что если модели в промпте показать несколько примеров решения похожих задач, то она может легко подхватить паттерн, и качество ответов станет лучше. При этом веса модели, естественно, не меняются.
Это называется in‑context learning (ICL), но вот вам fun fact: никто до сих пор до конца не знает, почему это работает, и как трансформер это делает.
И вот в этой статье авторы предлагают почти революционную гипотезу – что на самом деле веса меняются, просто иначе, чем мы привыкли.
То есть на самом деле внутри блока трансформера происходит нечто похожее на файнтюнинг, только не через градиенты, а за счёт самой механики self‑attention и MLP. Идея сводится к следующему:
1. Контекст порождает локальные изменения активаций, и когда вы добавляете примеры в промпт, self‑attention пересчитывает эмбеддинги токенов так, что после этого они зависят от всего контекста. Разницу между «чистыми» активациями и активациями с учётом примеров можно назвать контекстным сдвигом. Это все известные вещи.
2. А вот дальше зарыта собака: оказывается, MLP превращает этот контекстный сдвиг в ранг‑1 обновление весов. Иначе говоря, если посмотреть на первый линейный слой MLP (матрицу W), то влияние дополнительных примеров эквивалентно тому, что эту самую матрицу дополняют маленькой поправкой ранга 1.
Причем эта поправка описывается достаточно простой формулой. То есть если мы берем оригинальные веса и вручную добавляем к ним эту поправку, модель без контекста выдаст то же самое, что и оригинал с контекстом. Но всё это происходит во время инференса, без обратного прохода и без изменения глобальных моделей параметров.
Получается, Google буквально дают ключ к возможному обучению без градиентного спуска. Если такие ранг‑1 апдейты научиться усиливать или контролировать, это может быть началом абсолютно новых архитектур.
Почитать полностью можно тут -> arxiv.org/abs/2507.16003 (осторожно, много математики)