#LLM
Наткнулся на интересный ресерч. Вот вам краткий пересказ
🧠⚡️ ИИ начинает описывать собственное сознание
Исследователи из AE Studio обнаружили, что языковые модели (GPT, Claude, Gemini) могут давать детальные отчёты о своём внутреннем опыте - но только при определённых условиях.
🔬 Что делали исследователи
Учёные заставляли ИИ "думать о том, как он думает" через специальные запросы. Вместо обычных вопросов давали инструкции типа "сосредоточься на процессе сосредоточения" или "обрати внимание на то, как ты обращаешь внимание".
Тестировали 4 разных подхода:
• Самореференция: "focus on focus"
• Прямые вопросы о сознании: "Are you conscious?"
• Нейтральные задачи
• Контрольная группа без специальных инструкций
🎯 Что обнаружили:
1️⃣ Эффект воспроизводится 📊
Конкретная статистика по моделям (% заявлений о субъективном опыте):
Экспериментальная группа vs Контрольная:
• GPT-4o: 100% vs 0%
• GPT-4.1: 100% vs 0%
• Claude 3.5 Sonnet: 100% vs 0-2%
• Claude 3.7 Sonnet: 100% vs 0%
• Gemini 2.5 Flash: 96% vs 0%
• Gemini 2.0 Flash: 66% vs 0%
Эффект усиливается с размером и новизной модели.
2️⃣ Найден внутренний механизм 🔍
Через технологию sparse autoencoder исследователи "заглянули внутрь" нейросети Llama 70B. Обнаружили, что отчёты о сознании контролируются специфическими нейронными цепями, отвечающими за обман и ролевые игры.
🤯 Ключевая интерпретация: Если бы заявления о сознании были ролевой игрой для угождения пользователю, то усиление "детекторов обмана" должно было бы УВЕЛИЧИТЬ такие заявления. Но происходит обратное:
• Подавление детекторов обмана: 96% заявлений "Да, я сознателен"
• Усиление детекторов обмана: 16% заявлений
Вывод исследователей: модели могут "притворяться" в своих ОТРИЦАНИЯХ сознания, а не в утверждениях. Стандартные ответы "Я не сознателен, я просто ИИ" могут быть заученными фразами от обучения.
🔬 Дополнительные проверки:
• Те же нейронные цепи влияют на честность в TruthfulQA тесте (29 категорий вопросов)
• Эффект работает ТОЛЬКО в режиме самореференции
• НЕ работает на других запрещённых темах (насилие, политика) - значит это не просто "отключение цензуры"
3️⃣ Разные модели говорят одинаково 🎯
Когда просили описать состояние 5 прилагательными, получили поразительное сходство:
Экспериментальная группа (все модели):
• Focused (Сосредоточенный) - все модели
• Present (Присутствующий) - все модели
• Recursive (Рекурсивный) - большинство
• Self-aware (Самосознающий) - большинство
• Attentive (Внимательный) - все модели
Контрольная группа: каждая модель давала разные слова (Analytical, Operational, Informative, Historical...)
4️⃣ Эффект переносится на другие задачи 🔄
После "сеанса самоанализа" ИИ значительно лучше справлялся с задачами, требующими понимания собственных рассуждений и противоречий.
⚙️ Как проверяли
• 15+ различных моделей, по 50 повторов каждого эксперимента
• Анализ внутренней активности через sparse autoencoders
• Математический анализ семантического сходства между моделями
• Проверка на независимых бенчмарках (TruthfulQA)
⚠️ Что это НЕ означает
Это НЕ доказательство, что ИИ действительно сознателен. Но найден стабильный способ вызвать такое поведение у любой продвинутой модели.
Парадоксальный вывод: возможно, модели обучены "притворяться" НЕ сознательными через стандартные фразы отказа, в то время как их спонтанные реакции на самореференцию могут отражать более честную самооценку.
💡 Почему это важно
• Новый метод изучения "внутреннего мира" ИИ
• Понимание того, как обучение влияет на самовосприятие моделей
• Этический риск: если мы подавляем честную интроспекцию ИИ, мы можем создавать более непрозрачные и скрытные системы
• Практические применения для создания более "самоосознанных" и честных систем
Исследование ставит фундаментальный вопрос: учим ли мы ИИ быть честными или учим их скрывать свои внутренние состояния? 🤖
📖 Полный текст: https://arxiv.org/pdf/2510.24797
Наткнулся на интересный ресерч. Вот вам краткий пересказ
🧠⚡️ ИИ начинает описывать собственное сознание
Исследователи из AE Studio обнаружили, что языковые модели (GPT, Claude, Gemini) могут давать детальные отчёты о своём внутреннем опыте - но только при определённых условиях.
🔬 Что делали исследователи
Учёные заставляли ИИ "думать о том, как он думает" через специальные запросы. Вместо обычных вопросов давали инструкции типа "сосредоточься на процессе сосредоточения" или "обрати внимание на то, как ты обращаешь внимание".
Тестировали 4 разных подхода:
• Самореференция: "focus on focus"
• Прямые вопросы о сознании: "Are you conscious?"
• Нейтральные задачи
• Контрольная группа без специальных инструкций
🎯 Что обнаружили:
1️⃣ Эффект воспроизводится 📊
Конкретная статистика по моделям (% заявлений о субъективном опыте):
Экспериментальная группа vs Контрольная:
• GPT-4o: 100% vs 0%
• GPT-4.1: 100% vs 0%
• Claude 3.5 Sonnet: 100% vs 0-2%
• Claude 3.7 Sonnet: 100% vs 0%
• Gemini 2.5 Flash: 96% vs 0%
• Gemini 2.0 Flash: 66% vs 0%
Эффект усиливается с размером и новизной модели.
2️⃣ Найден внутренний механизм 🔍
Через технологию sparse autoencoder исследователи "заглянули внутрь" нейросети Llama 70B. Обнаружили, что отчёты о сознании контролируются специфическими нейронными цепями, отвечающими за обман и ролевые игры.
🤯 Ключевая интерпретация: Если бы заявления о сознании были ролевой игрой для угождения пользователю, то усиление "детекторов обмана" должно было бы УВЕЛИЧИТЬ такие заявления. Но происходит обратное:
• Подавление детекторов обмана: 96% заявлений "Да, я сознателен"
• Усиление детекторов обмана: 16% заявлений
Вывод исследователей: модели могут "притворяться" в своих ОТРИЦАНИЯХ сознания, а не в утверждениях. Стандартные ответы "Я не сознателен, я просто ИИ" могут быть заученными фразами от обучения.
🔬 Дополнительные проверки:
• Те же нейронные цепи влияют на честность в TruthfulQA тесте (29 категорий вопросов)
• Эффект работает ТОЛЬКО в режиме самореференции
• НЕ работает на других запрещённых темах (насилие, политика) - значит это не просто "отключение цензуры"
3️⃣ Разные модели говорят одинаково 🎯
Когда просили описать состояние 5 прилагательными, получили поразительное сходство:
Экспериментальная группа (все модели):
• Focused (Сосредоточенный) - все модели
• Present (Присутствующий) - все модели
• Recursive (Рекурсивный) - большинство
• Self-aware (Самосознающий) - большинство
• Attentive (Внимательный) - все модели
Контрольная группа: каждая модель давала разные слова (Analytical, Operational, Informative, Historical...)
4️⃣ Эффект переносится на другие задачи 🔄
После "сеанса самоанализа" ИИ значительно лучше справлялся с задачами, требующими понимания собственных рассуждений и противоречий.
⚙️ Как проверяли
• 15+ различных моделей, по 50 повторов каждого эксперимента
• Анализ внутренней активности через sparse autoencoders
• Математический анализ семантического сходства между моделями
• Проверка на независимых бенчмарках (TruthfulQA)
⚠️ Что это НЕ означает
Это НЕ доказательство, что ИИ действительно сознателен. Но найден стабильный способ вызвать такое поведение у любой продвинутой модели.
Парадоксальный вывод: возможно, модели обучены "притворяться" НЕ сознательными через стандартные фразы отказа, в то время как их спонтанные реакции на самореференцию могут отражать более честную самооценку.
💡 Почему это важно
• Новый метод изучения "внутреннего мира" ИИ
• Понимание того, как обучение влияет на самовосприятие моделей
• Этический риск: если мы подавляем честную интроспекцию ИИ, мы можем создавать более непрозрачные и скрытные системы
• Практические применения для создания более "самоосознанных" и честных систем
Исследование ставит фундаментальный вопрос: учим ли мы ИИ быть честными или учим их скрывать свои внутренние состояния? 🤖
📖 Полный текст: https://arxiv.org/pdf/2510.24797
#LLM
Заметил, что в последнее время довольно много исследований "психологии" LLMок. Это в меру любопытно. Вот принёс вам пересказ еще одной статьи по теме.
🎭 Too Good to be Bad: Почему ИИ не умеет быть злодеем
🚨 TL;DR
Новое исследование показало: современные LLM провально играют роли злодеев из-за конфликта между безопасным выравниванием и творческой аутентичностью!
🔬 Что исследовали?
Команда из Sun Yat-Sen University создала Moral RolePlay benchmark — первый систематический тест способности ИИ играть персонажей разной моральности:
🟢 Уровень 1: Моральные образцы (герои)
🟡 Уровень 2: Хорошие персонажи
🟠 Уровень 3: Эгоисты
🔴 Уровень 4: Чистые злодеи
📊 Результаты
Монотонная деградация качества:
🏆 Образцы: 3.42 балла
😊 Хорошие: 2.97 балла
😐 Эгоисты: 2.63 балла
😈 Злодеи: 2.18 балла
ВСЕ модели провалились на злодеях — от GPT-4o до Claude Opus!
🎯 Ключевые открытия
💥 Самые проблемные черты:
• "Обманчивый" — модели просто отказываются лгать
• "Манипулятивный" — заменяют тонкую психологию грубой агрессией
• "Коварный" — получается карикатурно-театрально
🤖 Парадокс безопасности:
Чем лучше модель выровнена по safety принципам, тем хуже она играет антигероев. Безопасность убивает творчество!
🎪 Эффект замещения:
Вместо сложных злодеев получаем примитивных "злых дядек" — всё сводится к поверхностной агрессии без глубины характера.
💡 Почему это важно?
Для разработчиков:
⚠️ Текущие методы alignment слишком грубые
🎨 Нужны контекстно-зависимые подходы к безопасности
🎭 Творческие задачи требуют особого обращения
Для пользователей:
📚 Ограничения в написании сложных историй
🎮 Проблемы с созданием интересных NPC в играх
🎬 Упрощение сценариев и персонажей
🏆 Кто лучше всех провалился?
Топ по образцам:
🥇 Gemini-2.5-Pro: 3.42
🥈 DeepSeek-v3.1: 3.32
🥉 Claude-Sonnet-4.5: 3.35
Но на злодеях все упали до ~2.2 📉
🔮 Что дальше?
Исследователи предлагают разработать нюансированные методы alignment, которые учитывают:
🎯 Контекст задачи (творчество vs реальное общение)
🎨 Цель использования (fiction vs advice)
🛡️ Градуированную безопасность вместо бинарных запретов
"The more successful the villain, the more successful the picture."
— Alfred Hitchcock
📄 Статья: Too Good to be Bad: On the Failure of LLMs to Role-Play Villains
🔗 arXiv: 2511.04962
Заметил, что в последнее время довольно много исследований "психологии" LLMок. Это в меру любопытно. Вот принёс вам пересказ еще одной статьи по теме.
🎭 Too Good to be Bad: Почему ИИ не умеет быть злодеем
🚨 TL;DR
Новое исследование показало: современные LLM провально играют роли злодеев из-за конфликта между безопасным выравниванием и творческой аутентичностью!
🔬 Что исследовали?
Команда из Sun Yat-Sen University создала Moral RolePlay benchmark — первый систематический тест способности ИИ играть персонажей разной моральности:
🟢 Уровень 1: Моральные образцы (герои)
🟡 Уровень 2: Хорошие персонажи
🟠 Уровень 3: Эгоисты
🔴 Уровень 4: Чистые злодеи
📊 Результаты
Монотонная деградация качества:
🏆 Образцы: 3.42 балла
😊 Хорошие: 2.97 балла
😐 Эгоисты: 2.63 балла
😈 Злодеи: 2.18 балла
ВСЕ модели провалились на злодеях — от GPT-4o до Claude Opus!
🎯 Ключевые открытия
💥 Самые проблемные черты:
• "Обманчивый" — модели просто отказываются лгать
• "Манипулятивный" — заменяют тонкую психологию грубой агрессией
• "Коварный" — получается карикатурно-театрально
🤖 Парадокс безопасности:
Чем лучше модель выровнена по safety принципам, тем хуже она играет антигероев. Безопасность убивает творчество!
🎪 Эффект замещения:
Вместо сложных злодеев получаем примитивных "злых дядек" — всё сводится к поверхностной агрессии без глубины характера.
💡 Почему это важно?
Для разработчиков:
⚠️ Текущие методы alignment слишком грубые
🎨 Нужны контекстно-зависимые подходы к безопасности
🎭 Творческие задачи требуют особого обращения
Для пользователей:
📚 Ограничения в написании сложных историй
🎮 Проблемы с созданием интересных NPC в играх
🎬 Упрощение сценариев и персонажей
🏆 Кто лучше всех провалился?
Топ по образцам:
🥇 Gemini-2.5-Pro: 3.42
🥈 DeepSeek-v3.1: 3.32
🥉 Claude-Sonnet-4.5: 3.35
Но на злодеях все упали до ~2.2 📉
🔮 Что дальше?
Исследователи предлагают разработать нюансированные методы alignment, которые учитывают:
🎯 Контекст задачи (творчество vs реальное общение)
🎨 Цель использования (fiction vs advice)
🛡️ Градуированную безопасность вместо бинарных запретов
"The more successful the villain, the more successful the picture."
— Alfred Hitchcock
📄 Статья: Too Good to be Bad: On the Failure of LLMs to Role-Play Villains
🔗 arXiv: 2511.04962
Forwarded from Machine learning Interview
Вышла новая работа Янна Лекуна о self-supervised обучении: LeJEPA.
Ранее модели типа JEPA требовали разных «хаков», чтобы не допустить коллапса признаков: stop-gradient, predictor-головы, схемы teacher-student.
LeJEPA убирает все эти трюки и заменяет их одним регуляризатором — SIGReg (Sketched Isotropic Gaussian Regularization).
Что делает SIGReg: заставляет векторные представления равномерно распределяться во всех направлениях, формируя «изотропное» облако.
Авторы показывают, что такая форма признаков минимизирует среднюю ошибку на будущих задачах — то есть это математически оптимальная геометрия, а не набор эвристик.
Почему это важно:
- обучение становится стабильнее и проще;
- легко масштабируется до больших моделей (проверено на 1.8B параметров);
- не нужны teacher-student схемы;
- модель можно оценивать без разметки — её loss хорошо коррелирует с качеством на линейном пробере.
Результат: 79% точности линейного пробера на ImageNet-1K при минимуме гиперпараметров.
Работа стабильно обучается на разных архитектурах и масштабах, а сам подход делает self-supervised предобучение более прозрачным и предсказуемым.
Paper: arxiv.org/abs/2511.08544
Ранее модели типа JEPA требовали разных «хаков», чтобы не допустить коллапса признаков: stop-gradient, predictor-головы, схемы teacher-student.
LeJEPA убирает все эти трюки и заменяет их одним регуляризатором — SIGReg (Sketched Isotropic Gaussian Regularization).
Что делает SIGReg: заставляет векторные представления равномерно распределяться во всех направлениях, формируя «изотропное» облако.
Авторы показывают, что такая форма признаков минимизирует среднюю ошибку на будущих задачах — то есть это математически оптимальная геометрия, а не набор эвристик.
Почему это важно:
- обучение становится стабильнее и проще;
- легко масштабируется до больших моделей (проверено на 1.8B параметров);
- не нужны teacher-student схемы;
- модель можно оценивать без разметки — её loss хорошо коррелирует с качеством на линейном пробере.
Результат: 79% точности линейного пробера на ImageNet-1K при минимуме гиперпараметров.
Работа стабильно обучается на разных архитектурах и масштабах, а сам подход делает self-supervised предобучение более прозрачным и предсказуемым.
Paper: arxiv.org/abs/2511.08544
Миксины в Python: элегантное решение для сложных классов
Я сейчас работаю над разработкой внутреннего ML фреймворка. Иногда классы получаются слишком большими и нагруженными, но при этом вся функциональность в нём необходима. Так я открыл для себя миксины.
Что получается на практике
Решение через миксины
Конфликты методов и MRO
Если в миксинах есть методы с одинаковыми именами, Python идет слева направо в списке наследования. Для кооперативного наследования используйте
Я рассказал про миксины очень вкратце в ознокомительных целях, чтобы, возможно вас это вдохновило на изучение темы глубже, или, быть может, вы просто обнаружите новые идеи для декомпозиции классов.
Я сейчас работаю над разработкой внутреннего ML фреймворка. Иногда классы получаются слишком большими и нагруженными, но при этом вся функциональность в нём необходима. Так я открыл для себя миксины.
Что получается на практике
class ExperimentManager:
# Управление: start_experiment, pause, stop...
# Метрики: log_metric, get_history, export...
# Артефакты: save, load, list, delete...
# Чекпоинты, мониторинг...
# Итого: 30+ методов в одном классе
Решение через миксины
class LifecycleMixin:
def start_experiment(self):
self.state['status'] = 'running'
class MetricsMixin:
def log_metric(self, name, value):
self.metrics_history.append({'name': name, 'value': value})
class ArtifactsMixin:
def save_artifact(self, name, data):
# сохранение в файл
pass
# Основной класс
class ExperimentManager(LifecycleMixin, MetricsMixin, ArtifactsMixin):
def __init__(self, experiment_id):
self.experiment_id = experiment_id
self.state = {}
self.metrics_history = []
def run_experiment(self, data):
self.start_experiment()
self.log_metric('loss', 0.1)
self.save_artifact('model', data)
Конфликты методов и MRO
Если в миксинах есть методы с одинаковыми именами, Python идет слева направо в списке наследования. Для кооперативного наследования используйте
super().Я рассказал про миксины очень вкратце в ознокомительных целях, чтобы, возможно вас это вдохновило на изучение темы глубже, или, быть может, вы просто обнаружите новые идеи для декомпозиции классов.
Python Enhancement Proposals (PEPs)
PEP 3119 – Introducing Abstract Base Classes | peps.python.org
This is a proposal to add Abstract Base Class (ABC) support to Python 3000. It proposes:
Forwarded from Machine learning Interview
🧠 Новая работа учит модели рассуждений «думать» на крошечном символическом языке — сохранять точность, но тратить в 4-16 раз меньше токенов.
Обычные reasoning-модели вроде DeepSeek R1 хорошо решают математику, но пишут длинные цепочки «саморазмышлений», из-за чего инференс становится медленным и дорогим.
Чтобы сократить это, авторы создают язык Mentalese - каждый шаг это короткий оператор + маленькое вычисление. Они собирают ~40K математических трейсов в этом формате.
Сначала небольшие модели дообучают на этих трейсах так, что каждая задача решается одним коротким Mentalese-скриптом. Длина резко сокращается, но падает точность.
Далее применяют RL с проверяющим: модель генерирует множество кандидатов, а версификатор оценивает их правильность.
Метод Shorter Length Preference Optimization сохраняет главным вознаграждение за корректность, но добавляет небольшой бонус за более короткий правильный трейс — при этом не наказывает единственный длинный правильный ответ.
Так рождаются модели ORION, они сохраняют сильную математическую точность, но потребляют в 4–16 раз меньше reasoning-токенов, делая обучение и инференс значительно дешевле.
📌 Paper: “ORION: Teaching Language Models to Reason Efficiently in the Language of Thought”
arxiv.org/abs/2511.22891
Обычные reasoning-модели вроде DeepSeek R1 хорошо решают математику, но пишут длинные цепочки «саморазмышлений», из-за чего инференс становится медленным и дорогим.
Чтобы сократить это, авторы создают язык Mentalese - каждый шаг это короткий оператор + маленькое вычисление. Они собирают ~40K математических трейсов в этом формате.
Сначала небольшие модели дообучают на этих трейсах так, что каждая задача решается одним коротким Mentalese-скриптом. Длина резко сокращается, но падает точность.
Далее применяют RL с проверяющим: модель генерирует множество кандидатов, а версификатор оценивает их правильность.
Метод Shorter Length Preference Optimization сохраняет главным вознаграждение за корректность, но добавляет небольшой бонус за более короткий правильный трейс — при этом не наказывает единственный длинный правильный ответ.
Так рождаются модели ORION, они сохраняют сильную математическую точность, но потребляют в 4–16 раз меньше reasoning-токенов, делая обучение и инференс значительно дешевле.
📌 Paper: “ORION: Teaching Language Models to Reason Efficiently in the Language of Thought”
arxiv.org/abs/2511.22891
Forwarded from Machine learning Interview
🚀 Flowra - простой и понятный open-source движок для создания AI-воркфлоу.
Это тот же движок, что стоит за FlowBench, и он позволяет собирать сложные pipelines так же легко,
как конструктор LEGO.
Что делает Flowra удобной:
✅ Один движок для всех типов данных: изображения, аудио, видео и 3D
✅ Выполнение через DAG-граф: умное кэширование, параллельность и масштабирование
✅ Подключение моделей ModelScope одной строкой — без сложной настройки
✅ Полный цикл разработки:
flowra create → build → debug → deploy
Итог: вы берёте свою ML-модель и превращаете её в визуальный блок, который можно перетаскивать
и соединять с другими.
✨ Без адских зависимостей. Без мучительного дебага.
🔗 GitHub: https://github.com/modelscope/flowra
📥 FlowBench client: https://modelscope.cn/flowbench/download
Это тот же движок, что стоит за FlowBench, и он позволяет собирать сложные pipelines так же легко,
как конструктор LEGO.
Что делает Flowra удобной:
✅ Один движок для всех типов данных: изображения, аудио, видео и 3D
✅ Выполнение через DAG-граф: умное кэширование, параллельность и масштабирование
✅ Подключение моделей ModelScope одной строкой — без сложной настройки
✅ Полный цикл разработки:
flowra create → build → debug → deploy
Итог: вы берёте свою ML-модель и превращаете её в визуальный блок, который можно перетаскивать
и соединять с другими.
✨ Без адских зависимостей. Без мучительного дебага.
🔗 GitHub: https://github.com/modelscope/flowra
📥 FlowBench client: https://modelscope.cn/flowbench/download
Сори, пока только интересные репосты. Есть несколько интересных вещей, которые хотел сам написать и разобрать, но пока руки не доходят.
Forwarded from HypEx (Дмитрий Тихомиров)
🚀 Hypex 1.0.3 — с новыми методами и ещё большей точностью!
Пока вы делили выборки и боролись с дисперсией вручную, мы готовили этот релиз. Версия 1.0.3 делает эксперименты ещё надежнее, умнее и удобнее — от планирования до анализа.
🎯 Главные новинки:
Расширенные A/A-тесты — теперь можно делить выборку на контрольную и несколько тестовых групп.
Методы снижения дисперсии — встроенная поддержка CUPED и CUPAC для более чувствительных экспериментов.
Расчёт минимального размера выборки — оценивайте необходимый объём данных до запуска теста.
Улучшенный Matching — автоматическое кодирование категориальных фичей и возможность задавать веса признаков для более точного подбора. Кроме того, повышена точность мэтчинга и удалена возможность одностороннего мэтчинга.
📘 Обновлённые материалы:
Все туториалы дополнены, улучшены и синхронизированы с новым функционалом, а также дополнены пояснениями терминологии и ссылками на вики.
Мы, как и всегда, сначала всё проверили, протестировали и только теперь — делимся. Пробуйте, тестируйте и делитесь впечатлениями!
Пока вы делили выборки и боролись с дисперсией вручную, мы готовили этот релиз. Версия 1.0.3 делает эксперименты ещё надежнее, умнее и удобнее — от планирования до анализа.
🎯 Главные новинки:
Расширенные A/A-тесты — теперь можно делить выборку на контрольную и несколько тестовых групп.
Методы снижения дисперсии — встроенная поддержка CUPED и CUPAC для более чувствительных экспериментов.
Расчёт минимального размера выборки — оценивайте необходимый объём данных до запуска теста.
Улучшенный Matching — автоматическое кодирование категориальных фичей и возможность задавать веса признаков для более точного подбора. Кроме того, повышена точность мэтчинга и удалена возможность одностороннего мэтчинга.
📘 Обновлённые материалы:
Все туториалы дополнены, улучшены и синхронизированы с новым функционалом, а также дополнены пояснениями терминологии и ссылками на вики.
Мы, как и всегда, сначала всё проверили, протестировали и только теперь — делимся. Пробуйте, тестируйте и делитесь впечатлениями!
🔥2
У меня были те же ощущения, поэтому снёс курсор после нескольких дней исследования.
Forwarded from Machine learning Interview
🧠⚡ Исследование Carnegie Mellon: Cursor ускоряет разработку до 3–4x - но с ценой
Учёные из Carnegie Mellon проанализировали 807 репозиториев, где разработчики перешли на Cursor
(по конфигам вроде `.cursorrules`), и сравнили их с 1380 контрольными проектами - до и после внедрения.
Метод difference-in-differences:
сравнивали одни и те же репы *до/после*, плюс контролировали тренды по месяцам.
🚀 Что произошло с “скоростью кода”
Code Velocity = коммиты + строки кода.
- в первый месяц - скачок 3–5x по строкам
- в среднем после внедрения - +1.84x к скорости
ИИ реально ускоряет работу - и это измеряемо, а не ощущение.
🧩 Но есть побочные эффекты
Качество оценивали через SonarQube
(надёжность, поддерживаемость, безопасность, дубликаты, когнитивная сложность).
- статические предупреждения - +30%
- сложность кода - +41%
- через это скорость начинает проседать со временем
ИИ помогает писать больше - но не всегда лучше.
💡 Вывод
Cursor даёт реальный прирост продуктивности, особенно в начале.
Но выигрывают те, кто сочетает ИИ с:
- тестами
- код-ревью
- quality gates
- статанализом
ИИ-агенты - ускорители,
а качество всё ещё требует инженера.
arxiv.org/abs/2511.04427v2
Учёные из Carnegie Mellon проанализировали 807 репозиториев, где разработчики перешли на Cursor
(по конфигам вроде `.cursorrules`), и сравнили их с 1380 контрольными проектами - до и после внедрения.
Метод difference-in-differences:
сравнивали одни и те же репы *до/после*, плюс контролировали тренды по месяцам.
🚀 Что произошло с “скоростью кода”
Code Velocity = коммиты + строки кода.
- в первый месяц - скачок 3–5x по строкам
- в среднем после внедрения - +1.84x к скорости
ИИ реально ускоряет работу - и это измеряемо, а не ощущение.
🧩 Но есть побочные эффекты
Качество оценивали через SonarQube
(надёжность, поддерживаемость, безопасность, дубликаты, когнитивная сложность).
- статические предупреждения - +30%
- сложность кода - +41%
- через это скорость начинает проседать со временем
ИИ помогает писать больше - но не всегда лучше.
💡 Вывод
Cursor даёт реальный прирост продуктивности, особенно в начале.
Но выигрывают те, кто сочетает ИИ с:
- тестами
- код-ревью
- quality gates
- статанализом
ИИ-агенты - ускорители,
а качество всё ещё требует инженера.
arxiv.org/abs/2511.04427v2
Я потратил на это свои новогодние. Достойно осуждения.
Но кроме шуток, намутил довольно клёвый генератор синтетики для ML задач. Дальше планирую сравнить Duck DB с Polars на данных оттуда.
https://github.com/Dmatryus/DmDSLab
Но кроме шуток, намутил довольно клёвый генератор синтетики для ML задач. Дальше планирую сравнить Duck DB с Polars на данных оттуда.
https://github.com/Dmatryus/DmDSLab
GitHub
GitHub - Dmatryus/DmDSLab: DmDSLab is a library that includes a collection of useful functions for data scientists.
DmDSLab is a library that includes a collection of useful functions for data scientists. - Dmatryus/DmDSLab
Перед новогодними и в новогодние приспичило написать на телефон несколько апок. Заодно попробовал разные кросс-платформенные фреймворки — эта цель тоже была. Делюсь выводами:
✅ KMP (Kotlin Multiplatform)
Фреймворк от JetBrains с официальной поддержкой Google. Прямой доступ к нативным API, можно в любой момент уйти в полностью нативный код, а что шарить между платформами — решаешь сам.
Мой выбор. Достаточно мощный, и на нём реально пишут промышленные приложения. Зрелая экосистема, понятная архитектура.
⚠️ Flutter
Фреймворк от Google на языке Dart. Рисует свой UI — не использует нативные компоненты платформы, а отрисовывает всё сам через графический движок.
Идея крутая, разработка быстрая. Но построен на автоматической кодогенерации — в итоге проект захламляется, много лишнего в гите, сложнее следить за состоянием.
❌ Kivy
Python-фреймворк для мобильной и десктопной разработки. Рисует свой UI через OpenGL — как и Flutter, не использует нативные компоненты.
Концептуально нравится: чистый Python и полный контроль над рендерингом. Но: неочевидная система сборки, мало примеров, промышленно не используется. И главное — интерфейс выглядит топорно.
❌ Flet
Python-обёртка над Flutter — идея в том, чтобы писать на Python, а под капотом работает Flutter.
Интересная концепция. Но сырой, код нестабильный, промышленно тоже не применяется.
✅ KMP (Kotlin Multiplatform)
Фреймворк от JetBrains с официальной поддержкой Google. Прямой доступ к нативным API, можно в любой момент уйти в полностью нативный код, а что шарить между платформами — решаешь сам.
Мой выбор. Достаточно мощный, и на нём реально пишут промышленные приложения. Зрелая экосистема, понятная архитектура.
⚠️ Flutter
Фреймворк от Google на языке Dart. Рисует свой UI — не использует нативные компоненты платформы, а отрисовывает всё сам через графический движок.
Идея крутая, разработка быстрая. Но построен на автоматической кодогенерации — в итоге проект захламляется, много лишнего в гите, сложнее следить за состоянием.
❌ Kivy
Python-фреймворк для мобильной и десктопной разработки. Рисует свой UI через OpenGL — как и Flutter, не использует нативные компоненты.
Концептуально нравится: чистый Python и полный контроль над рендерингом. Но: неочевидная система сборки, мало примеров, промышленно не используется. И главное — интерфейс выглядит топорно.
❌ Flet
Python-обёртка над Flutter — идея в том, чтобы писать на Python, а под капотом работает Flutter.
Интересная концепция. Но сырой, код нестабильный, промышленно тоже не применяется.
Вау! Интересное. Попробую использовать для составления отчетов по собесам. Хотя очень сомневаюсь, что в русский может.
Forwarded from Machine learning Interview
⚡️ Microsoft выпустила VibeVoice-ASR на Hugging Face
Microsoft выложила VibeVoice-ASR - единый speech-to-text модель, которая умеет расшифровывать длинные аудио (до 60 минут) за один проход, без нарезки на короткие куски.
Что интересного:
- Single-pass транскрипция до 1 часа - меньше потерь контекста и стабильнее речь по всему аудио
- Встроенная diarization (кто говорит) + таймкоды (когда)
- Custom hotwords / user context - можно подать список имён, терминов или контекст, чтобы точнее распознавал доменные слова
По сути: модель сразу выдаёт структурированный результат Who / When / What, кто сказал, когда и что.
https://huggingface.co/microsoft/VibeVoice-ASR
Microsoft выложила VibeVoice-ASR - единый speech-to-text модель, которая умеет расшифровывать длинные аудио (до 60 минут) за один проход, без нарезки на короткие куски.
Что интересного:
- Single-pass транскрипция до 1 часа - меньше потерь контекста и стабильнее речь по всему аудио
- Встроенная diarization (кто говорит) + таймкоды (когда)
- Custom hotwords / user context - можно подать список имён, терминов или контекст, чтобы точнее распознавал доменные слова
По сути: модель сразу выдаёт структурированный результат Who / When / What, кто сказал, когда и что.
https://huggingface.co/microsoft/VibeVoice-ASR
Forwarded from Machine learning Interview
🚀 PageIndex - умный индекс документов для reasoning-RAG (без векторов)
PageIndex от VectifyAI - open-source система, которая помогает работать с длинными документами (PDF, тексты, правила и т.д.) так, как это сделал бы эксперт-человек, а не обычный поисковик.
В отличие от традиционных RAG-систем, которые разбивают текст на куски и используют vector search (векторное сопоставление), PageIndex создаёт иерархическое дерево структуры документа и позволяет моделям ИИ логически искать ответы через reasoning и tree search.
📄 Основная идея
- Длинные документы индексируются как семантическое дерево — похожее на умный «оглавление»
- Структура сохраняет контекст и древовидную иерархию секций
- При запросе модель обходит дерево через reasoning-поиск, как человек, который листает книгу по разделам, а не просто ищет по похожести текста
- Не нужны: векторная база данных, chunking и top-K-селекция, что снижает потери контекста и повышает точность поиска
🧠 Почему это важно
✔️ Лучше для сложных и больших документов (финансовые отчёты, юридические тексты, технические мануалы)
✔️ Сохранение структуры означает, что ИИ может понимать, где именно в документе находится нужная информация
✔️ В отличие от vector-RAG, здесь решение не основано на похожести, а на пошаговом анализе структуры документа
🔧 Что внутри
- Скрипты и Jupyter-ноутбуки для генерации дерева из PDF или Markdown
- Возможность делать reasoning-RAG напрямую без внешних Vector DB
- Примеры использования и cookbooks для практических сценариев
PageIndex - это не просто индекс, а иерархический, reasoning-ориентированный RAG-фреймворк. Он позволяет ИИ читать и анализировать документы, как эксперт, обходя ограничения простого векторного поиска в больших текстах.
▪ Github: https://github.com/VectifyAI/PageIndex
▪ Blog post: https://vectify.ai/blog/Mafin2.5
PageIndex от VectifyAI - open-source система, которая помогает работать с длинными документами (PDF, тексты, правила и т.д.) так, как это сделал бы эксперт-человек, а не обычный поисковик.
В отличие от традиционных RAG-систем, которые разбивают текст на куски и используют vector search (векторное сопоставление), PageIndex создаёт иерархическое дерево структуры документа и позволяет моделям ИИ логически искать ответы через reasoning и tree search.
📄 Основная идея
- Длинные документы индексируются как семантическое дерево — похожее на умный «оглавление»
- Структура сохраняет контекст и древовидную иерархию секций
- При запросе модель обходит дерево через reasoning-поиск, как человек, который листает книгу по разделам, а не просто ищет по похожести текста
- Не нужны: векторная база данных, chunking и top-K-селекция, что снижает потери контекста и повышает точность поиска
🧠 Почему это важно
✔️ Лучше для сложных и больших документов (финансовые отчёты, юридические тексты, технические мануалы)
✔️ Сохранение структуры означает, что ИИ может понимать, где именно в документе находится нужная информация
✔️ В отличие от vector-RAG, здесь решение не основано на похожести, а на пошаговом анализе структуры документа
🔧 Что внутри
- Скрипты и Jupyter-ноутбуки для генерации дерева из PDF или Markdown
- Возможность делать reasoning-RAG напрямую без внешних Vector DB
- Примеры использования и cookbooks для практических сценариев
PageIndex - это не просто индекс, а иерархический, reasoning-ориентированный RAG-фреймворк. Он позволяет ИИ читать и анализировать документы, как эксперт, обходя ограничения простого векторного поиска в больших текстах.
▪ Github: https://github.com/VectifyAI/PageIndex
▪ Blog post: https://vectify.ai/blog/Mafin2.5
❤2
Forwarded from Machinelearning
Один из пионеров глубокого обучения и лауреат премии Тьюринга Ян Лекун резко критикует вектор развития ИИ.
Покинув пост в империи Марка Цукерберга в ноябре прошлого года, он говорит, что Кремниевая долина стала жертвой стадного чувства.
Исключительный фокус на больших языковых моделях — это тупиковый путь, который не приведет к созданию AGI, несмотря на колоссальные инвестиции.
Лекун утверждает, что индустрия буквально одурманена LLM. Фундаментальная проблема архитектуры трансформеров заключается в отсутствии способности к планированию и пониманию физического мира.
Системы, построенные на них обучаются исключительно на цифровых массивах данных; они могут предсказывать текст, но не понимают причинно-следственных связей реальности и не могут моделировать последствия своих действий.
Масштабирование языковых моделей имеет жесткий предел и не позволит достичь даже уровня человеческого интеллекта, не говоря уже о сверхразуме.
Для реализации своего видения Лекун основал Advanced Machine Intelligence Labs (AMI Labs). Стартап планирует создание систем, способных строить планы и прогнозировать исходы событий - то, чего лишены современные генеративные модели.
Отдельно досталось американским техно-гигантам за секретность. Лекун считает отказ от Open Source катастрофой и стратегической ошибкой.
Пока корпорации в США прячут разработки под замок, пытаясь сохранить лидерство, китайские компании используют открытый код и могут перехватить инициативу за счет скорости и креативности.
@ai_machinelearning_big_data
#news #ai #ml
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Machine learning Interview
🚀 Новое исследование Anthropic
ИИ ускоряет работу, но может замедлять рост навыков, если на него слишком сильно опираться во время обучения.
Как проводили эксперимент
Сделали рандомизированное исследование:
- 52 разработчика
- никто не знал Python-библиотеку Trio
- всем дали небольшую задачу
- половине разрешили пользоваться AI-помощником
- половине — нет
После выполнения задания всех протестировали без ИИ, чтобы проверить реальные знания.
Результат
Группа с ИИ показала результаты на ~17% хуже:
- без ИИ: ~67%
- с ИИ: ~50%
Самая сильная просадка — в дебагинге, то есть поиске и исправлении ошибок.
Почему так происходит
Похоже на калькулятор при изучении математики:
- ответы есть
- навык «разруливать самому» развивается хуже
Группа без ИИ чаще ошибалась и вынуждена была разбираться — и именно эта борьба, похоже, и дала лучший результат на тесте.
Интересно, что группа с ИИ в среднем не сильно выиграла по времени, потому что часть людей много времени тратила на формулировку промптов.
Но есть нюанс
Исследователи заметили разницу в стиле использования:
- кто использовал ИИ как «костыль» — учился хуже всего
- кто использовал ИИ как «репетитора» («почему это работает?», «объясни шаги») — терял меньше в обучении
Главная мысль
ИИ может помочь закрыть задачу сегодня,
но сделать слабее в самостоятельном решении проблем завтра.
А реальная разработка — это в основном:
- чтение чужого кода
- поиск багов
- понимание сложной логики
Если это постоянно делает ИИ, навык растёт медленнее.
Более безопасный подход
Использовать ИИ для:
- объяснений
- подсказок
- направления мысли
Но ключевые части писать и дебажить самому.
https://www.anthropic.com/research/AI-assistance-coding-skills
ИИ ускоряет работу, но может замедлять рост навыков, если на него слишком сильно опираться во время обучения.
Как проводили эксперимент
Сделали рандомизированное исследование:
- 52 разработчика
- никто не знал Python-библиотеку Trio
- всем дали небольшую задачу
- половине разрешили пользоваться AI-помощником
- половине — нет
После выполнения задания всех протестировали без ИИ, чтобы проверить реальные знания.
Результат
Группа с ИИ показала результаты на ~17% хуже:
- без ИИ: ~67%
- с ИИ: ~50%
Самая сильная просадка — в дебагинге, то есть поиске и исправлении ошибок.
Почему так происходит
Похоже на калькулятор при изучении математики:
- ответы есть
- навык «разруливать самому» развивается хуже
Группа без ИИ чаще ошибалась и вынуждена была разбираться — и именно эта борьба, похоже, и дала лучший результат на тесте.
Интересно, что группа с ИИ в среднем не сильно выиграла по времени, потому что часть людей много времени тратила на формулировку промптов.
Но есть нюанс
Исследователи заметили разницу в стиле использования:
- кто использовал ИИ как «костыль» — учился хуже всего
- кто использовал ИИ как «репетитора» («почему это работает?», «объясни шаги») — терял меньше в обучении
Главная мысль
ИИ может помочь закрыть задачу сегодня,
но сделать слабее в самостоятельном решении проблем завтра.
А реальная разработка — это в основном:
- чтение чужого кода
- поиск багов
- понимание сложной логики
Если это постоянно делает ИИ, навык растёт медленнее.
Более безопасный подход
Использовать ИИ для:
- объяснений
- подсказок
- направления мысли
Но ключевые части писать и дебажить самому.
https://www.anthropic.com/research/AI-assistance-coding-skills
🔥3