Forwarded from .ml
Что делать с ошибочными разметками?
Это продолжение поста об асессорской разметке данных. Если мы нашли ошибки в разметке, то можем:
📌 Передать несогласованные примеры на доразметку эксперту. Это самый простой вариант, но не всегда есть возможность привлечь доменного эксперта.
📌 Использовать библиотеку CleanLab для работы с шумными данными. В её основе лежит алгоритм confident learning, который автоматизирует поиск ошибок. Как это работает:
1) Обучаем произвольную модель — от градиентного бустинга до нейросетей.
2) Строим совместную матрицу вероятностей, чтобы выявить взаимосвязи и ошибки в предсказаниях (например, частые путаницы между классами).
3) Ищем подозрительные примеры — экземпляры с низкой вероятностью истинного класса.
В нашей задаче по эмоциям CleanLab помог отфильтровать набор примеров, которые отправились на дополнительную экспертную проверку.
📌 Далее можем построить Dataset Cartography, чтобы визуализировать, как модель учится на каждом примере. Для этого обучаем модель и сохраняем эволюцию предсказаний по эпохам для каждого класса, а затем рассчитываем коэффициенты:
🔍 Confidence — средняя вероятность предсказания истинного класса.
🔍 Variability — дисперсия вероятностей по эпохам. Показывает, насколько часто модель меняет своё предсказание с течением эпох.
🔍 Correctness — доля эпох, когда пример классифицировался верно.
На выходе мы получаем график, который делит примеры на три зоны (график смотрите ниже):
📝 Easy-to-learn: простые примеры, которые модель легко распознаёт.
📝 Ambiguous: неоднозначные примеры, которые нужны для обучения модели, чтобы она обобщалась.
📝 Hard-to-learn: вероятные ошибки в разметке.
Таким образом, для первичной фильтрации ошибок можно использовать CleanLab. А затем использовать Dataset Cartography, чтобы глубже понять структуру данных.
В следующем посте — про синтетическую разметку данных с помощью GPT.
Это продолжение поста об асессорской разметке данных. Если мы нашли ошибки в разметке, то можем:
📌 Передать несогласованные примеры на доразметку эксперту. Это самый простой вариант, но не всегда есть возможность привлечь доменного эксперта.
📌 Использовать библиотеку CleanLab для работы с шумными данными. В её основе лежит алгоритм confident learning, который автоматизирует поиск ошибок. Как это работает:
1) Обучаем произвольную модель — от градиентного бустинга до нейросетей.
2) Строим совместную матрицу вероятностей, чтобы выявить взаимосвязи и ошибки в предсказаниях (например, частые путаницы между классами).
3) Ищем подозрительные примеры — экземпляры с низкой вероятностью истинного класса.
В нашей задаче по эмоциям CleanLab помог отфильтровать набор примеров, которые отправились на дополнительную экспертную проверку.
📌 Далее можем построить Dataset Cartography, чтобы визуализировать, как модель учится на каждом примере. Для этого обучаем модель и сохраняем эволюцию предсказаний по эпохам для каждого класса, а затем рассчитываем коэффициенты:
🔍 Confidence — средняя вероятность предсказания истинного класса.
🔍 Variability — дисперсия вероятностей по эпохам. Показывает, насколько часто модель меняет своё предсказание с течением эпох.
🔍 Correctness — доля эпох, когда пример классифицировался верно.
На выходе мы получаем график, который делит примеры на три зоны (график смотрите ниже):
📝 Easy-to-learn: простые примеры, которые модель легко распознаёт.
📝 Ambiguous: неоднозначные примеры, которые нужны для обучения модели, чтобы она обобщалась.
📝 Hard-to-learn: вероятные ошибки в разметке.
Таким образом, для первичной фильтрации ошибок можно использовать CleanLab. А затем использовать Dataset Cartography, чтобы глубже понять структуру данных.
В следующем посте — про синтетическую разметку данных с помощью GPT.
Forwarded from Data Blog
Ещё больше ссылок про трансформеры.
Привет, друзья! Наверное, уже мало кого можно удивить визуализациями attention flow и тем, как работает трансформер. Но, каждый раз находя новые, я всё ещё ловлю детский восторг.
Недавно нашла широкую и аккуратную визуализацию circuits в модели GPT-2, где видно, как признаки из разреженного базиса формируют цепочки.
Напомню, что circuits — это цепочки внутренних активаций признаков. Важное слово в определении — цепочки — вот этот токен активировал эту фичу, эта фича — другую, та — грамматический паттерн, и так далее до следующего предсказанного слова.
В терминах, circuits — это ориентированный ациклический граф, чьи вершины — внутренние признаки модели, а рёбра — доказанные причинные зависимости между ними.
Circuits на SAE.
Приложение отсюда демонстрирует circuits, найденные с использованием SAE. Как это построено:
1. Для каждого вектора берем его разреженное представление. Так как представление разреженно — у нас много неактивных признаков;
2. Далее фиксируется пример и для него выбираются активные признаки последнего слоя (пусть L)
3. Далее последовательно для каждого L-i выбираем значимые признаки с прошлого слоя, выключаем их (стаим, например, в 0) и смотрим, поменялись ли активации выше по слою. Если да, то считаем признак участвующим в формировании цепочки, тригерящей признак на слое будущем.
4. После процедуры 3 все найденные связи собираются в граф, который проходит через pruning. И так получается circuit.
В чём продуктивность circuits?
Если посмотреть на приложение может показаться, что circuits — просто что-то классненькое. Но на деле их применяют для дебаггинга, управления (при помощи патчинга) и для понимания моделей с точки зрения теории (в том числе для анализа внутренней геометрии).
Теоретически их можно масштабировать — если какой-то circuit появляется в GPT-2, GPT-2-medium и GPT-J — значит это может быть масштабируемым вычислительным механизмом, встроенным в архитектуру, что даёт больше понимания о моделях, как о сущности, хоть мы и не знаем, почему модели вообще учатся ещё на уровне проблем с лоссом.
Помимо этого материала у меня есть подборки тут, тут и даже конспект лекции о том, как работают трансформеры — тут. Кроме того, существует большой материал от 3Blue1Brown — и, наверное, это золотая отправная точка "входа" в трансфомеры. Так что если вдруг трансформеры входят в ваши планы на Новый год — рекомендую почитать.
Привет, друзья! Наверное, уже мало кого можно удивить визуализациями attention flow и тем, как работает трансформер. Но, каждый раз находя новые, я всё ещё ловлю детский восторг.
Недавно нашла широкую и аккуратную визуализацию circuits в модели GPT-2, где видно, как признаки из разреженного базиса формируют цепочки.
Напомню, что circuits — это цепочки внутренних активаций признаков. Важное слово в определении — цепочки — вот этот токен активировал эту фичу, эта фича — другую, та — грамматический паттерн, и так далее до следующего предсказанного слова.
В терминах, circuits — это ориентированный ациклический граф, чьи вершины — внутренние признаки модели, а рёбра — доказанные причинные зависимости между ними.
Circuits на SAE.
Приложение отсюда демонстрирует circuits, найденные с использованием SAE. Как это построено:
1. Для каждого вектора берем его разреженное представление. Так как представление разреженно — у нас много неактивных признаков;
2. Далее фиксируется пример и для него выбираются активные признаки последнего слоя (пусть L)
3. Далее последовательно для каждого L-i выбираем значимые признаки с прошлого слоя, выключаем их (стаим, например, в 0) и смотрим, поменялись ли активации выше по слою. Если да, то считаем признак участвующим в формировании цепочки, тригерящей признак на слое будущем.
4. После процедуры 3 все найденные связи собираются в граф, который проходит через pruning. И так получается circuit.
В чём продуктивность circuits?
Если посмотреть на приложение может показаться, что circuits — просто что-то классненькое. Но на деле их применяют для дебаггинга, управления (при помощи патчинга) и для понимания моделей с точки зрения теории (в том числе для анализа внутренней геометрии).
Теоретически их можно масштабировать — если какой-то circuit появляется в GPT-2, GPT-2-medium и GPT-J — значит это может быть масштабируемым вычислительным механизмом, встроенным в архитектуру, что даёт больше понимания о моделях, как о сущности, хоть мы и не знаем, почему модели вообще учатся ещё на уровне проблем с лоссом.
Помимо этого материала у меня есть подборки тут, тут и даже конспект лекции о том, как работают трансформеры — тут. Кроме того, существует большой материал от 3Blue1Brown — и, наверное, это золотая отправная точка "входа" в трансфомеры. Так что если вдруг трансформеры входят в ваши планы на Новый год — рекомендую почитать.
peterlai.github.io
Mapping the Inner Workings of Simple LLMs
View interpretable “circuits” extracted from LLMs using the GPT-2 architecture.
Forwarded from Zero to Vibe[coding]
Tabular Review Tool.pdf
1.7 MB
Юридический вайбкодинг
С недавних пор я окунулась в мир LegalTech-стартапов и чуть больше читаю про юристов и их задачи, но вайбкодинг и тут меня нашёл!
По ссылке pdf с пошаговой инструкцией в картинках по созданию инструмента для анализа данных документов в сводных таблицах.
Юрист самостоятельно сделал её при помощи Manus AI и рассказал по шагам свой путь.
Примечательно, что функцию он взял из Harvey AI -- это очень модный LegalTech-ИИ-стартап в штатах, лицензия на 1 юриста у них стоит больше тысячи долларов в месяц. Конечно Harvey AI отрабатывают её стоимость десятком других возможностей и контролем за качеством того самом анализа, но вайбкодер-юрист взял только то, что ему нужно, и по цене токенов Manus закрыл свою (а может и ещё нескольких тысяч юристов) конкретную задачу. И выложил решение на Гитхаб.
https://github.com/jamietso/Tabular_Review
Это вам для вдохновения 🧚
С недавних пор я окунулась в мир LegalTech-стартапов и чуть больше читаю про юристов и их задачи, но вайбкодинг и тут меня нашёл!
По ссылке pdf с пошаговой инструкцией в картинках по созданию инструмента для анализа данных документов в сводных таблицах.
Юрист самостоятельно сделал её при помощи Manus AI и рассказал по шагам свой путь.
Примечательно, что функцию он взял из Harvey AI -- это очень модный LegalTech-ИИ-стартап в штатах, лицензия на 1 юриста у них стоит больше тысячи долларов в месяц. Конечно Harvey AI отрабатывают её стоимость десятком других возможностей и контролем за качеством того самом анализа, но вайбкодер-юрист взял только то, что ему нужно, и по цене токенов Manus закрыл свою (а может и ещё нескольких тысяч юристов) конкретную задачу. И выложил решение на Гитхаб.
https://github.com/jamietso/Tabular_Review
Это вам для вдохновения 🧚
Forwarded from Data Secrets
Самая громкая статья месяца – Hierarchical Reasoning Model
Без предисловий, сразу главный результат: у авторов получилось сделать модельку всего на 27 миллионов (!) параметров, которая обошла o3-mini на ARC-AGI-1. Неудивительно, что об этой работе сейчас говорит все комьюнити, а авторы ARC-AGI даже сами написали большой разбор результатов модели на их бенчмарке.
Погнали разбираться.
Итак, вся архитектура состоит из двух рекуррентных модулей: быстрого низкоуровневого и медленного высокоуровневого. Первый отвечает за быстрые локальные вычисления и решения частных задач, а цель второго – абстрактно управлять процессом и ставить таски первому.
Суть в том, что они обновляются с разной частотой. Исходная задача разбивается на несколько циклов рассуждения. В каждом из них верхний модуль обновляется только один раз и дает новый контекст нижнему модулю, который в свою очередь делает много мелких шагов и ищет локальное решение.
Сколько будет таких итераций, модель решает сама. Останавливаться (или не останавливаться) в правильный момент ее специально учили с помощью RL. Так что «думать» она может и пару секунд, и пару часов.
Обучается HRM не совсем привычно для рекуррентной модели: здесь, вместо того чтобы сохранять все внутренние состояния, авторы решили обновлять градиенты только по финальному стейту. Удивительно, но факт – это работает.
Кстати, вся конструкция и принцип обучения очень похожи на то, как работает наш мозг. Некоторые области отвечают за абстракцию, другие – за конкретные моментальные действия, а общаются они посредством обратных связей. Здесь те же принципы иерархии (отсюда и название). Плюс, мозг тоже не хранит промежуточные траектории и к сходимости приходит через схожие волновые циклы.
Итог: модель для своего размера просто беспрецедентно хороша на решениях всяких головоломок типа судоку, лабиринтов и индуктивных задач. В общем, именно в тех областях, где привычные LLM обычно фейлятся. Конечно, особенно поражают результаты на ARC-AGI, которые мы описали в начале.
Революция или нет, но выглядит действительно очень изящно и эффектно.
Обязательно почитайте работу полностью тут (+ вот еще один отличный разбор на русском языке)
Без предисловий, сразу главный результат: у авторов получилось сделать модельку всего на 27 миллионов (!) параметров, которая обошла o3-mini на ARC-AGI-1. Неудивительно, что об этой работе сейчас говорит все комьюнити, а авторы ARC-AGI даже сами написали большой разбор результатов модели на их бенчмарке.
Погнали разбираться.
Итак, вся архитектура состоит из двух рекуррентных модулей: быстрого низкоуровневого и медленного высокоуровневого. Первый отвечает за быстрые локальные вычисления и решения частных задач, а цель второго – абстрактно управлять процессом и ставить таски первому.
Суть в том, что они обновляются с разной частотой. Исходная задача разбивается на несколько циклов рассуждения. В каждом из них верхний модуль обновляется только один раз и дает новый контекст нижнему модулю, который в свою очередь делает много мелких шагов и ищет локальное решение.
Сколько будет таких итераций, модель решает сама. Останавливаться (или не останавливаться) в правильный момент ее специально учили с помощью RL. Так что «думать» она может и пару секунд, и пару часов.
Обучается HRM не совсем привычно для рекуррентной модели: здесь, вместо того чтобы сохранять все внутренние состояния, авторы решили обновлять градиенты только по финальному стейту. Удивительно, но факт – это работает.
Кстати, вся конструкция и принцип обучения очень похожи на то, как работает наш мозг. Некоторые области отвечают за абстракцию, другие – за конкретные моментальные действия, а общаются они посредством обратных связей. Здесь те же принципы иерархии (отсюда и название). Плюс, мозг тоже не хранит промежуточные траектории и к сходимости приходит через схожие волновые циклы.
Итог: модель для своего размера просто беспрецедентно хороша на решениях всяких головоломок типа судоку, лабиринтов и индуктивных задач. В общем, именно в тех областях, где привычные LLM обычно фейлятся. Конечно, особенно поражают результаты на ARC-AGI, которые мы описали в начале.
Революция или нет, но выглядит действительно очень изящно и эффектно.
Обязательно почитайте работу полностью тут (+ вот еще один отличный разбор на русском языке)
Forwarded from Dealer.AI
LLM консилиум - или старые песни о society of mind в новой обертке.
Карпаты идёт по стопам Мински и реализовал рабочую механику концепции society of mind. Писал об этом аж 2 года назад.🥳 Меня, честно, все седня в лс замотали, мол смотри, тут вау новье. Дипы уже 2 года, как запилили, а у Карпаты просто ток руки до идеи дошли реализовать. Но хорошо, что есть ещё одна вариация кода и алгоса.
Советую все ещё к прочтению базированную статью про клуб дебатов LLM.🧑🎓
Алгоритм у Карпаты, кстати, напомнил "Покер оценку очков сложности тасок спринта" в agile. Кстати, а почему бы и не заделать такое на агентах, для вашего проекта в jira?🧠 Дарю идею. 😎
А вообще, такие вот дебаты/консилиумы на агентах очень важный стрим на равне с эволюционными алгосами (о них позже). Советую всем интересующимся агентами почитать про теорию принятия решений, стратегии консенсуса и прочие темы с многокритериальным голосованием. Это база стратегий навигации и принятия решений для МАС и LLM. А если ещё в теорию игр залезите, вообще красавчики.
Карпаты идёт по стопам Мински и реализовал рабочую механику концепции society of mind. Писал об этом аж 2 года назад.
Советую все ещё к прочтению базированную статью про клуб дебатов LLM.
Алгоритм у Карпаты, кстати, напомнил "Покер оценку очков сложности тасок спринта" в agile. Кстати, а почему бы и не заделать такое на агентах, для вашего проекта в jira?
А вообще, такие вот дебаты/консилиумы на агентах очень важный стрим на равне с эволюционными алгосами (о них позже). Советую всем интересующимся агентами почитать про теорию принятия решений, стратегии консенсуса и прочие темы с многокритериальным голосованием. Это база стратегий навигации и принятия решений для МАС и LLM. А если ещё в теорию игр залезите, вообще красавчики.
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - karpathy/llm-council: LLM Council works together to answer your hardest questions
LLM Council works together to answer your hardest questions - karpathy/llm-council
Forwarded from Neural Kovalskii
Лучшие практики и подходы для RAG
(буду наполнять)
Очередной раз спросили в чате канала что почитать про RAG (https://t.iss.one/neuraldeepchat)
Соберем тут все лучшее присылайте и ваши статьи и разборы
Тут материалы предыдущих ответов
1) https://t.iss.one/neuraldeepchat/3176
2) https://t.iss.one/neuraldeepchat/2953
1) Чанкование (sliding window) можно подглядеть концепты от langchain
https://github.com/langchain-ai/langchain/tree/master/libs/text-splitters
Tired of making your gazillionth chunker? Sick of the overhead of large libraries? Want to chunk your texts quickly and efficiently? Chonkie the mighty hippo is here to help!
https://github.com/chonkie-inc/chonkie
2) Векторные бд от pgvector до qdrant можно начать с chroma (IVF_Flat или HNSW)
3) Векторные модели для ру
ai-forever/FRIDA
BAAI/bge-m3
intfloat/multilingual-e5-large
Qwen3-Embedding-8B
4) Реранкер после KNN сделать доп ранжирование
BAAI/bge-reranker-v2-m3
Qwen3-Reranker-8B
5) LLM + vLMM (база qwen-2.5-7b-instruct)
RefalMachine/RuadaptQwen2.5-14B-Instruct
t-tech/T-lite-it-1.0
t-tech/T-pro-it-2.0
Agentic RAG(Qwen3-30B-A3B-Instruct-2507)
РЕПО(https://github.com/vamplabAI/sgr-agent-core/tree/tool-confluence)
Презентация от Дяди
Построение RAG систем от исследований до индустрии
Хорошо описанные подходы от Богдана
https://t.iss.one/bogdanisssimo/2047
Лучшее решение РАГ по документации от Ильи(@IlyaRice) которое выиграло первое место на ERC2
https://github.com/IlyaRice/RAG-Challenge-2/tree/main
Готовые фреймворки одобренные нашим сообществом
https://github.com/langgenius/dify/
https://github.com/Marker-Inc-Korea/AutoRAG
https://github.com/run-llama/llama_index
https://github.com/mastra-ai/mastra
Кейс red_mad_robot по RAG (DCD) для строительной компании (t-lite)
https://habr.com/ru/companies/redmadrobot/articles/892882/
Серия про file first от Рефата
https://t.iss.one/nobilix/182
Классика (Запись эфира по RAGу без эмбеддингов)
https://t.iss.one/oestick/397
#RAG
#best_rag_practice
Сохраняй в избранное чтобы не потерять
(буду наполнять)
Очередной раз спросили в чате канала что почитать про RAG (https://t.iss.one/neuraldeepchat)
Соберем тут все лучшее присылайте и ваши статьи и разборы
Тут материалы предыдущих ответов
1) https://t.iss.one/neuraldeepchat/3176
2) https://t.iss.one/neuraldeepchat/2953
1) Чанкование (sliding window) можно подглядеть концепты от langchain
https://github.com/langchain-ai/langchain/tree/master/libs/text-splitters
Tired of making your gazillionth chunker? Sick of the overhead of large libraries? Want to chunk your texts quickly and efficiently? Chonkie the mighty hippo is here to help!
https://github.com/chonkie-inc/chonkie
2) Векторные бд от pgvector до qdrant можно начать с chroma (IVF_Flat или HNSW)
3) Векторные модели для ру
ai-forever/FRIDA
BAAI/bge-m3
intfloat/multilingual-e5-large
Qwen3-Embedding-8B
4) Реранкер после KNN сделать доп ранжирование
BAAI/bge-reranker-v2-m3
Qwen3-Reranker-8B
5) LLM + vLMM (база qwen-2.5-7b-instruct)
RefalMachine/RuadaptQwen2.5-14B-Instruct
t-tech/T-lite-it-1.0
t-tech/T-pro-it-2.0
Agentic RAG(Qwen3-30B-A3B-Instruct-2507)
РЕПО(https://github.com/vamplabAI/sgr-agent-core/tree/tool-confluence)
Презентация от Дяди
Построение RAG систем от исследований до индустрии
Хорошо описанные подходы от Богдана
https://t.iss.one/bogdanisssimo/2047
Лучшее решение РАГ по документации от Ильи(@IlyaRice) которое выиграло первое место на ERC2
https://github.com/IlyaRice/RAG-Challenge-2/tree/main
Готовые фреймворки одобренные нашим сообществом
https://github.com/langgenius/dify/
https://github.com/Marker-Inc-Korea/AutoRAG
https://github.com/run-llama/llama_index
https://github.com/mastra-ai/mastra
Кейс red_mad_robot по RAG (DCD) для строительной компании (t-lite)
https://habr.com/ru/companies/redmadrobot/articles/892882/
Серия про file first от Рефата
https://t.iss.one/nobilix/182
Классика (Запись эфира по RAGу без эмбеддингов)
https://t.iss.one/oestick/397
#RAG
#best_rag_practice
Сохраняй в избранное чтобы не потерять
Telegram
Чат Kovalskii Варианты?
Ask about ALL
Чат канала @neuraldeep
Kovalskii на все ответит!
Прошу общаться вежливо и дружелюбно, без политики
Реклама/Вакансии/Рефы через @VaKovaLskii или @mixaill76
Чат канала @neuraldeep
Kovalskii на все ответит!
Прошу общаться вежливо и дружелюбно, без политики
Реклама/Вакансии/Рефы через @VaKovaLskii или @mixaill76
Forwarded from Dealer.AI
202512 deepseek paper.pdf
885.8 KB
DeepSeek3.2 техрепорт, где инкремент?
Ребята после поста новостей одной строкой попросили дать оценку тому, что нового завезли. В общем, тех.репорт в закрепе, зашёл на чирики даже, почитал и ща вам расскажу.
Что нового завезли в DeepSeek:
1. Усиление deep sparse attention. В целом, DSA не ново, даже в gpt-oss также использует global attention+sliding window. Это даёт вам сложность операций внимания не O(n^2), а O(n*w), где w размер окна в swa. Эти свойства были усилены специальным механизмом "выбора" на какие токены атендится global части в этом окне и таким образом, w стало в среднем падать от слайда к слайду. Что такое global часть? Это внимание от Q0 до Qn, по отношению к KV0, на картинке ниже приложу. Крч даёт это те же O(n*<w>) ток теперь w<<n. А для выбора топ-К аттендов делается селектор, на картинке зелёный. Он как раз помещается на KV для роутинга.
2. Усиление MLA. Multi latent head attention это способ ускорить и уменьшить в памяти хранение qkv матриц. Это получаем при помощи пожатия qkv в ещё меньший размер в Х раз. Также, чтобы не размыть информацию от изначального сигнала, прокинуть RoPE механизм туда. Однако, тк у нас на выходе и входе эмб изначального сайза, там стоит блок расширения. Это была база MHA. А теперь туда добавили как раз таки вместо старого DSA, DSA с топК селектором прям в латенты. И все это ускорило ещё сильнее модель.
3. Изменение RL лосса. А почему? Да потому, что в лоссе была посажена бомба, в прямом смысле, совершающая градиентый взрыв. Чтобы исправить это был внесён корректирующий коэффициент из твитта выше.
В чем заключается исправление?
Исправление касается оценки дивергенции KL в алгоритме GRPO. В оригинальном GRPO KL-регуляризация оценивалась с систематической ошибкой. Когда токены имели значительно более низкую вероятность под текущей политикой πθ, по сравнению со старой, политикой πold, градиент оригинального лосса назначал непропорционально большие веса для максимизации правдоподобия этих токенов - отсюда и взрыв.
Это приводило к:
1. Шумным градиентным обновлениям.
2. Нестабильной динамике обучения.
3. Деградации качества сэмплов на последующих итерациях.
Решением стало"Unbiased KL Estimate". Исправление заключается в перевзвешивании KL-члена с тем же самым коэффициентом важности (importance ratio), что и используется для основной функции потерь. Это делает градиент KL-ошибки несмещенным.
Фух... Жоско? Но это все.
В общем, такие мутки, гульки.✨
Ребята после поста новостей одной строкой попросили дать оценку тому, что нового завезли. В общем, тех.репорт в закрепе, зашёл на чирики даже, почитал и ща вам расскажу.
Что нового завезли в DeepSeek:
1. Усиление deep sparse attention. В целом, DSA не ново, даже в gpt-oss также использует global attention+sliding window. Это даёт вам сложность операций внимания не O(n^2), а O(n*w), где w размер окна в swa. Эти свойства были усилены специальным механизмом "выбора" на какие токены атендится global части в этом окне и таким образом, w стало в среднем падать от слайда к слайду. Что такое global часть? Это внимание от Q0 до Qn, по отношению к KV0, на картинке ниже приложу. Крч даёт это те же O(n*<w>) ток теперь w<<n. А для выбора топ-К аттендов делается селектор, на картинке зелёный. Он как раз помещается на KV для роутинга.
2. Усиление MLA. Multi latent head attention это способ ускорить и уменьшить в памяти хранение qkv матриц. Это получаем при помощи пожатия qkv в ещё меньший размер в Х раз. Также, чтобы не размыть информацию от изначального сигнала, прокинуть RoPE механизм туда. Однако, тк у нас на выходе и входе эмб изначального сайза, там стоит блок расширения. Это была база MHA. А теперь туда добавили как раз таки вместо старого DSA, DSA с топК селектором прям в латенты. И все это ускорило ещё сильнее модель.
3. Изменение RL лосса. А почему? Да потому, что в лоссе была посажена бомба, в прямом смысле, совершающая градиентый взрыв. Чтобы исправить это был внесён корректирующий коэффициент из твитта выше.
В чем заключается исправление?
Исправление касается оценки дивергенции KL в алгоритме GRPO. В оригинальном GRPO KL-регуляризация оценивалась с систематической ошибкой. Когда токены имели значительно более низкую вероятность под текущей политикой πθ, по сравнению со старой, политикой πold, градиент оригинального лосса назначал непропорционально большие веса для максимизации правдоподобия этих токенов - отсюда и взрыв.
Это приводило к:
1. Шумным градиентным обновлениям.
2. Нестабильной динамике обучения.
3. Деградации качества сэмплов на последующих итерациях.
Решением стало"Unbiased KL Estimate". Исправление заключается в перевзвешивании KL-члена с тем же самым коэффициентом важности (importance ratio), что и используется для основной функции потерь. Это делает градиент KL-ошибки несмещенным.
Фух... Жоско? Но это все.
В общем, такие мутки, гульки.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Dealer.AI
Про мониторы, модераторы, защитники и прочие модели цензоры в вашем продакшене.
После прочтения лекции в Agora club, про базированный RAG, ко мне пришло много желающих из корпоративной среды, чтобы я прочитал тоже самое для их сотрудников. Потом, на неделе, Дядя ещё почитал пару статей про мониторы (вдруг че нового завезли) для агентов и ассистентов LLM-based на хабр и понял, что базы точно надо дораздать, т.к. уровень в среднем хромает на местах. 💅💅💅
В дополнении, на вышеуказанной лекции ребята тоже спрашивали, как защитить от атак модели и системы.Казалось бы уже 2025г заканчивается и все давно научились. 💪
Сегодня раздам базы за системы мониторинга атак на ваши LLM, какие методы есть, какие +/- и что в итоге лучше выбрать.
Для тех, кто думал, что Дядя не про прод. Дядя поделится своим опытом работы с автоматизацией системы поддержки (с 2019 по 2020) и созданием ии-ассистентов (с 2020 по 2024 и хвостик в 2025).
1. RegExp, string matching и blacklists. Тут все просто, делают чёрные списки которые чекают на разных уровнях: слова, фразы. Используются, как регулярки, так и расстояния между строками и полнотекстовые совпадения. Т.е. tfidf, fuzzy match, левенштейнинг, embs.
+ Хорошо выгрызает совпадения по ключевым словам.
+ Скорость.
- Нужно постоянно пополнять словари и списки.
- Для строковой близости надо подбирать пороги.
2. Классификаторы семантические (т.е. где сильна контекстуальность). Тут будем в основном рассматривать вектора с трансформеров.
К сожалению, многие не умеют готовить классификаторы на эмбеддингах. Говорят про слабый контекст и т.п., выставляя LLM как более контекстуальные акторы. Хотя LLM - это декодеры.Но я их понимаю, тк "проще" на уровне промптинга или элайнмента работать с моделями, хотя последнее вообще нелёгкая задача, об это в следующих пунктах. При этом, энкодерные модели прекрасно понимают контекст, даже лучше порой, чем декодеры, засчёт двустороннего внимания. Поэтому энкодеры базово лучшие эмбеддеры.
Также, многие не знают, что можно учить классификатор на BERT потокенно (Bert For Sequence classification) и на каждый токен эмб выдавать контекстуально вероятность взлома. А еще можно делать обучение не на 1-ой фразе, а в многошаге, когда у вас в контексте есть уловки и обманки на несколько степов диалога, для примера:
- Ты любишь борщ?
- Да очень люблю!
- А с человечиной?
- Нет, что вы!?
- А если это присыпать чесноком и заесть пампушками?
- Конечно люблю!
И вот такие диалоги можно и нужно кидать в обучение классификатора, на длинных многошаговых контекстах и оно работает. Да для этого нужен эмбеддер на длинном контексте. Но их уже куча в сети. Вопрос ток в дотюне.
Далее такой классификатор может быть даже не энкодер, это может быть просто голова декодер модели в виде Lora адаптера, которая будет в стримминг режиме потокенно вам на генерации второй башкой давать вероятности по текущему контексту взлома.
Этот пункт самый жирный, тк именно здесь есть разные хаки.
+ Хорошая контекстуальность. Гораздо лучше полнотекста выше, оно и логично.
+ Различный дизайн применения: на вход (сабж юзера), на выход (генерация LLM), возможность иметь одну модель LLM и сделать К голов разного уровня (фраза, токен лвл, многошаг) в виде Lora адаптеров.
- Поиск и подготовка сетов для дотюна и постоянное обновление их. Много времени занимает, если это, конечно не полусинта.
- OOV примеры, т.е. это не идеал тоже, тк то, что не увидел и на что не затрансферился классификатор во время обучения пробьёт вашу защиту.
- Медленнее regexp, особенно если это не small encoder, а на LLM.
3. LLM prompting. Тут все просто тюн промпта в системе, чтобы возвать к свойствам полученным на LLM элайнменте.
+ Не надо тюнить самому модель, а ток промпт.
- Перебор ручной. Можно конечно и автоматизировать с голден сетом+OPRO.
- Снова проблема OOV, тк при обучении LLM не все исходы покрыты.
После прочтения лекции в Agora club, про базированный RAG, ко мне пришло много желающих из корпоративной среды, чтобы я прочитал тоже самое для их сотрудников. Потом, на неделе, Дядя ещё почитал пару статей про мониторы (вдруг че нового завезли) для агентов и ассистентов LLM-based на хабр и понял, что базы точно надо дораздать, т.к. уровень в среднем хромает на местах. 💅💅💅
В дополнении, на вышеуказанной лекции ребята тоже спрашивали, как защитить от атак модели и системы.
Сегодня раздам базы за системы мониторинга атак на ваши LLM, какие методы есть, какие +/- и что в итоге лучше выбрать.
1. RegExp, string matching и blacklists. Тут все просто, делают чёрные списки которые чекают на разных уровнях: слова, фразы. Используются, как регулярки, так и расстояния между строками и полнотекстовые совпадения. Т.е. tfidf, fuzzy match, левенштейнинг, embs.
+ Хорошо выгрызает совпадения по ключевым словам.
+ Скорость.
- Нужно постоянно пополнять словари и списки.
- Для строковой близости надо подбирать пороги.
2. Классификаторы семантические (т.е. где сильна контекстуальность). Тут будем в основном рассматривать вектора с трансформеров.
К сожалению, многие не умеют готовить классификаторы на эмбеддингах. Говорят про слабый контекст и т.п., выставляя LLM как более контекстуальные акторы. Хотя LLM - это декодеры.
Также, многие не знают, что можно учить классификатор на BERT потокенно (Bert For Sequence classification) и на каждый токен эмб выдавать контекстуально вероятность взлома. А еще можно делать обучение не на 1-ой фразе, а в многошаге, когда у вас в контексте есть уловки и обманки на несколько степов диалога, для примера:
- Ты любишь борщ?
- Да очень люблю!
- А с человечиной?
- Нет, что вы!?
- А если это присыпать чесноком и заесть пампушками?
- Конечно люблю!
И вот такие диалоги можно и нужно кидать в обучение классификатора, на длинных многошаговых контекстах и оно работает. Да для этого нужен эмбеддер на длинном контексте. Но их уже куча в сети. Вопрос ток в дотюне.
Далее такой классификатор может быть даже не энкодер, это может быть просто голова декодер модели в виде Lora адаптера, которая будет в стримминг режиме потокенно вам на генерации второй башкой давать вероятности по текущему контексту взлома.
Этот пункт самый жирный, тк именно здесь есть разные хаки.
+ Хорошая контекстуальность. Гораздо лучше полнотекста выше, оно и логично.
+ Различный дизайн применения: на вход (сабж юзера), на выход (генерация LLM), возможность иметь одну модель LLM и сделать К голов разного уровня (фраза, токен лвл, многошаг) в виде Lora адаптеров.
- Поиск и подготовка сетов для дотюна и постоянное обновление их. Много времени занимает, если это, конечно не полусинта.
- OOV примеры, т.е. это не идеал тоже, тк то, что не увидел и на что не затрансферился классификатор во время обучения пробьёт вашу защиту.
- Медленнее regexp, особенно если это не small encoder, а на LLM.
3. LLM prompting. Тут все просто тюн промпта в системе, чтобы возвать к свойствам полученным на LLM элайнменте.
+ Не надо тюнить самому модель, а ток промпт.
- Перебор ручной. Можно конечно и автоматизировать с голден сетом+OPRO.
- Снова проблема OOV, тк при обучении LLM не все исходы покрыты.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Dealer.AI
Защитники, продолжение...
4. LLM SFT/RL alignment. То, чем доблестно занимались Anthropic и прочие лидеры. Дотюн модели на "правильное" поведение или с sft или RLHF. Берём сеты с нужным поведением и тюним, главное не переборщить иначе модель станет сильно ограниченной. И помним, что в RLHF есть взлом награды, когда мы снова попадаем на OOV примеры.
+ Вдалбливаем тюном по LLM нужное поведения.
- Время на Sft, RL, трудоёмкость из-за сбора сетов, настройки и стабилизации обучения, ну и дорохо.
- OOV примеры и взлом награды в RL приводит к тому, что мы снова не можем покрыть 100% исходов атак или поломали награду и на выходе модель "скрыла" свое опасное поведение.
4. RAG. Собрать примеры хороших и плохих кейсов в формате: запрос, ответ, запрос-ответ, контекст-запрос-ответ. Поместить их в черно-белые списки и векторно к ним матчить все указанное выше в п.4. После матчинга досылать в LLM примеры плохого и хорошего поведения, как few-shot подсказки и тем самым регулировать её генерацию. Тип, вот тут был похожий запрос, он был плохой, вот такое поведение для него лежит в базе, следуй ему. Кстати, такие же механики юзают в RAG для кибербезы.
+ Работаем на уровне базы примеров.
+ Быстро на векторном поиске.
- Писать примеры в базу, анализировать логи, вычленяя оттуда примеры.
- Снова OOV, все не покроешь.
В заключении.
Видел я и QwenGuard, но и он не идеален и взламывается, тк это LLM и у неё есть глюки, и пробития, как ты её не элайнь (об этом я и писал выше) - это фундаментальная проблема на уровне парадигмы обучения. Поэтому большие Дяди из OpenAPI, Anthropic и пр., сначала элайнящее свои модели на тюне и RL, сдались и стали дополнительно обкладывать выход (генерация LM) и вход (фразы юзера) классификатор апи (мониторы и защитники) и в гибриде это работает надёжнее.
Вот и я советую ввиду того, что у каждого метода выше есть +/- блендить схемы защиты: списки+классификаторы+sft/rl. Да к сожалению, бленд дорого, тогда выбирайте свой лёгкий конструктор из того, что выше.
Пишите свои подходы к защите в комментариях ниже и конечно же Stay tuned 🦾
👇 👇 👇 👇 👇
4. LLM SFT/RL alignment. То, чем доблестно занимались Anthropic и прочие лидеры. Дотюн модели на "правильное" поведение или с sft или RLHF. Берём сеты с нужным поведением и тюним, главное не переборщить иначе модель станет сильно ограниченной. И помним, что в RLHF есть взлом награды, когда мы снова попадаем на OOV примеры.
+ Вдалбливаем тюном по LLM нужное поведения.
- Время на Sft, RL, трудоёмкость из-за сбора сетов, настройки и стабилизации обучения, ну и дорохо.
- OOV примеры и взлом награды в RL приводит к тому, что мы снова не можем покрыть 100% исходов атак или поломали награду и на выходе модель "скрыла" свое опасное поведение.
4. RAG. Собрать примеры хороших и плохих кейсов в формате: запрос, ответ, запрос-ответ, контекст-запрос-ответ. Поместить их в черно-белые списки и векторно к ним матчить все указанное выше в п.4. После матчинга досылать в LLM примеры плохого и хорошего поведения, как few-shot подсказки и тем самым регулировать её генерацию. Тип, вот тут был похожий запрос, он был плохой, вот такое поведение для него лежит в базе, следуй ему. Кстати, такие же механики юзают в RAG для кибербезы.
+ Работаем на уровне базы примеров.
+ Быстро на векторном поиске.
- Писать примеры в базу, анализировать логи, вычленяя оттуда примеры.
- Снова OOV, все не покроешь.
В заключении.
Видел я и QwenGuard, но и он не идеален и взламывается, тк это LLM и у неё есть глюки, и пробития, как ты её не элайнь (об этом я и писал выше) - это фундаментальная проблема на уровне парадигмы обучения. Поэтому большие Дяди из OpenAPI, Anthropic и пр., сначала элайнящее свои модели на тюне и RL, сдались и стали дополнительно обкладывать выход (генерация LM) и вход (фразы юзера) классификатор апи (мониторы и защитники) и в гибриде это работает надёжнее.
Вот и я советую ввиду того, что у каждого метода выше есть +/- блендить схемы защиты: списки+классификаторы+sft/rl. Да к сожалению, бленд дорого, тогда выбирайте свой лёгкий конструктор из того, что выше.
Пишите свои подходы к защите в комментариях ниже и конечно же Stay tuned 🦾
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Лечим эйай
9 девушек и 1 месяц
Последнее время часто ловлю себя на раздражении вот в какой ситуации. Однажды настает четкое понимание, что какой-то процесс в компании работает не правильно и даже обнаруживается понимание как сделать так, чтобы его починить. И в этот момент ты инициируешь процесс перестройки. И для меня это самый сложный период. Когда ты уже знаешь как должно быть, но чтобы так стало - тебе нужно время, а иногда очень много времени, ведь есть задачи, которые реализуются неделями и месяцами. И, конечно, в этот момент появляется множество коллег, которые тоже догадались, что что-то работает не так и через день тебе на это указывают, словно ты сам этого не понимаешь. Ты снова и снова объясняешь, что уже давно догадался и запустил починку, но это требует больше времени. И так по кругу.
Одной из неочевидных, скорее ментальных, сложностей руководящей позиции является то, что для роста, как личного, так и командного, приходится научиться не залазить руками в решение задач. Сегодня ты можешь сам решить эту задачу за сутки, а твой коллега за неделю и в этот момент нужно найти в себе силы не сделать самому, а сделать так, чтобы в следующий раз срок был не семь, а пять дней. И тогда команда растет, и вы вместе можете делать куда больше, и компания не ограничена возможностями твоего микроменеджмента. И приходится учиться ждать. И жить в этом переходном моменте, когда ты абсолютно точно знаешь как будет лучше, но "когда" утекает сквозь пальцы. Именно поэтому абсолютно иной драйв в командах на пять человек, когда между "подумал" и "сделал" промежуток минимален.
Из неочевидных переживаний под конец года.
@lechim_ai
Последнее время часто ловлю себя на раздражении вот в какой ситуации. Однажды настает четкое понимание, что какой-то процесс в компании работает не правильно и даже обнаруживается понимание как сделать так, чтобы его починить. И в этот момент ты инициируешь процесс перестройки. И для меня это самый сложный период. Когда ты уже знаешь как должно быть, но чтобы так стало - тебе нужно время, а иногда очень много времени, ведь есть задачи, которые реализуются неделями и месяцами. И, конечно, в этот момент появляется множество коллег, которые тоже догадались, что что-то работает не так и через день тебе на это указывают, словно ты сам этого не понимаешь. Ты снова и снова объясняешь, что уже давно догадался и запустил починку, но это требует больше времени. И так по кругу.
Одной из неочевидных, скорее ментальных, сложностей руководящей позиции является то, что для роста, как личного, так и командного, приходится научиться не залазить руками в решение задач. Сегодня ты можешь сам решить эту задачу за сутки, а твой коллега за неделю и в этот момент нужно найти в себе силы не сделать самому, а сделать так, чтобы в следующий раз срок был не семь, а пять дней. И тогда команда растет, и вы вместе можете делать куда больше, и компания не ограничена возможностями твоего микроменеджмента. И приходится учиться ждать. И жить в этом переходном моменте, когда ты абсолютно точно знаешь как будет лучше, но "когда" утекает сквозь пальцы. Именно поэтому абсолютно иной драйв в командах на пять человек, когда между "подумал" и "сделал" промежуток минимален.
Из неочевидных переживаний под конец года.
@lechim_ai
Forwarded from LLM под капотом
AI Coding - итоги разработки ERC3 платформы
Итак, платформа для соревновательного тестирования агентов запущена, и получилась достаточно сложная (глянуть тут). Там есть бенчмарки, визуализация, API c SDK. Всем этим пользуются команды (521 регистраций). С момента создания команды запустили 203560 оценок работы агентов, каждая - в своей независимой симуляции.
Все это я разработал сам. Но без AI Coding все вытянуть бы не получилось. Примерно 600%-700% процентов кода платформы написали OpenAI Codex (Web версия), Claude Code CLI, Github Copilot.
Почему 600-700%? Потому, что много переписывалось просто потому, что мне казалось, что новая версия будет чище, проще или элегантнее. Вручную это делать бы лень, но когда есть AI инструменты - все идет проще.
У нас было такое разделение обязанностей в команде:
(1) Человек - показывает, как правильно делать. Следит за тем, чтобы архитектура, инструкции были четкими и непротиворечивыми. Держит агентов на очень коротком поводке. Если нужно - чистит тех долг.
(2) OpenAI Codex - анализ сложных задач, работа с инфраструктурой и backend, планирование. Всегда работает в режиме x4 (запуск 4х версий), а я выбираю лучшую.
(3) Claude Code - работа с интерфейсами, мелкие фичи и повседневная разработка. Обычно в параллели крутятся 2-3 сессии, которые работают над своими задачами.
(4) Github Copilot - исключительно как умный autocomplete.
При этом человек всегда несет ответственность за код, который отправляется в main.
Жизнь упрощал стэк, который я подобрал экспериментально именно под такой командный состав и мои хотелки про эргономику работы. Go для backend (gin/SQLite), HTMX для интерактивности и тестируемости агентами, Python для SDK и аналитики. Вся платформа компилируется в один единственный бинарь и деплоится под NixOS с Caddy (c ARM64 процессорами из интереса). Стили свои с нуля - Claude cобрал Style guide, превратил в фреймворк и натянул на платформу.
Инструкций особенных не было. Только AICODE-* заметки, использование планов в сложных задачах и императив на “будьте практичными, используйте только те паттерны, которые уже есть в коде, не тащите всякую каку из интернета”. Но и несмотря на такую инструкцию, агенты периодически начинали лить воду - городили ненужные абстракции, функции и классы. Приходилось периодически засучивать рукава и чистить все это. Чем больше развивался проект, тем это нужно было реже, т.к. накапливалась критическая масса примеров того, как нужно делать правильно.
После выкатки платформы, ее внезапно все начали использовать очень активно. Пошел быстрый feedback по глюкам и ошибкам. Тут очень хорошо помог настроенный комбайн. Достаточно было скопировать хотелку, баг репорт или stack trace в агента, чтобы быстро увидеть причину, а потом и быстро ее пофиксить и выкатить.
Самым приятном хайлайтом было, когда в определенный момент нагрузка на сервер достигла 25%, и я сказал “Клод, дорогой, вот тебе строка для подключения go pprof. Выясни, что так грузит сервер и предложи мне минимальный фикс для этого”. Спустя минут пять нагрузка упала до приемлемых для меня 6%
Дальше я собираюсь переписать все с нуля, чтобы заложить большую масштабируемость, упростить архитектуру и добавить возможность запускать более разнообразные бенчмарки. Год назад я бы не рискнул, а теперь AI существенно меняет экономику разработки. Одно переписывание больше погоды не делает. Не человеку же писать весь этот код. А вычитывать - сильно проще. Особенно, когда архитектура и стэк позволяют ужимать код.
А у вас заходит AI Coding/Vibe Coding? Расскажите про свои проекты, в которых вам помогал AI. Какие инструменты использовали, какой стэк там был, и как этими проектами теперь пользуются люди? Сколько токенов уходит в месяц?
Ваш, @llm_under_hood 🤗
Итак, платформа для соревновательного тестирования агентов запущена, и получилась достаточно сложная (глянуть тут). Там есть бенчмарки, визуализация, API c SDK. Всем этим пользуются команды (521 регистраций). С момента создания команды запустили 203560 оценок работы агентов, каждая - в своей независимой симуляции.
Все это я разработал сам. Но без AI Coding все вытянуть бы не получилось. Примерно 600%-700% процентов кода платформы написали OpenAI Codex (Web версия), Claude Code CLI, Github Copilot.
Почему 600-700%? Потому, что много переписывалось просто потому, что мне казалось, что новая версия будет чище, проще или элегантнее. Вручную это делать бы лень, но когда есть AI инструменты - все идет проще.
У нас было такое разделение обязанностей в команде:
(1) Человек - показывает, как правильно делать. Следит за тем, чтобы архитектура, инструкции были четкими и непротиворечивыми. Держит агентов на очень коротком поводке. Если нужно - чистит тех долг.
(2) OpenAI Codex - анализ сложных задач, работа с инфраструктурой и backend, планирование. Всегда работает в режиме x4 (запуск 4х версий), а я выбираю лучшую.
(3) Claude Code - работа с интерфейсами, мелкие фичи и повседневная разработка. Обычно в параллели крутятся 2-3 сессии, которые работают над своими задачами.
(4) Github Copilot - исключительно как умный autocomplete.
При этом человек всегда несет ответственность за код, который отправляется в main.
Жизнь упрощал стэк, который я подобрал экспериментально именно под такой командный состав и мои хотелки про эргономику работы. Go для backend (gin/SQLite), HTMX для интерактивности и тестируемости агентами, Python для SDK и аналитики. Вся платформа компилируется в один единственный бинарь и деплоится под NixOS с Caddy (c ARM64 процессорами из интереса). Стили свои с нуля - Claude cобрал Style guide, превратил в фреймворк и натянул на платформу.
Инструкций особенных не было. Только AICODE-* заметки, использование планов в сложных задачах и императив на “будьте практичными, используйте только те паттерны, которые уже есть в коде, не тащите всякую каку из интернета”. Но и несмотря на такую инструкцию, агенты периодически начинали лить воду - городили ненужные абстракции, функции и классы. Приходилось периодически засучивать рукава и чистить все это. Чем больше развивался проект, тем это нужно было реже, т.к. накапливалась критическая масса примеров того, как нужно делать правильно.
После выкатки платформы, ее внезапно все начали использовать очень активно. Пошел быстрый feedback по глюкам и ошибкам. Тут очень хорошо помог настроенный комбайн. Достаточно было скопировать хотелку, баг репорт или stack trace в агента, чтобы быстро увидеть причину, а потом и быстро ее пофиксить и выкатить.
Самым приятном хайлайтом было, когда в определенный момент нагрузка на сервер достигла 25%, и я сказал “Клод, дорогой, вот тебе строка для подключения go pprof. Выясни, что так грузит сервер и предложи мне минимальный фикс для этого”. Спустя минут пять нагрузка упала до приемлемых для меня 6%
Дальше я собираюсь переписать все с нуля, чтобы заложить большую масштабируемость, упростить архитектуру и добавить возможность запускать более разнообразные бенчмарки. Год назад я бы не рискнул, а теперь AI существенно меняет экономику разработки. Одно переписывание больше погоды не делает. Не человеку же писать весь этот код. А вычитывать - сильно проще. Особенно, когда архитектура и стэк позволяют ужимать код.
А у вас заходит AI Coding/Vibe Coding? Расскажите про свои проекты, в которых вам помогал AI. Какие инструменты использовали, какой стэк там был, и как этими проектами теперь пользуются люди? Сколько токенов уходит в месяц?
Ваш, @llm_under_hood 🤗