Forwarded from Data Blog
Материалы для чтения.
Вчера потребовалось понять, как считать доверительный интервал для пропорции.
Эта задача возникает, когда у вас есть пропорция, посчитанная по N наблюдениям (скажем, число ответивших «да» в эксперименте). Дать одно число нечестно — при прочих равных эксперимент зависит от случайности. Поэтому всегда и везде, ДИ требуется.
В моем случае эта задача возникла рядом с анализом attack success rate (ASR) (успешной атаки на модель) в двух конфигурациях эксперимента. Какое-то время я изучала статьи, и меня эта метрика всегда вводила в ступор — она устоявшаяся, а меня все случаи оценки пропорций настораживают ещё от доли неправильных ответов из ML (accuracy). Поэтому, чтобы быть в ступоре поменьше (и потому что ДИ — это единственный корректный метод предоставления результата), было решено добавить больше формальности.
Обычные интервалы называются Wald intervals и проблема, которая заставила задуматься и не использовать их— это то, что в базовой постановке ДИ может выйти за [0,1], а значений больше 1 и меньше 0 для пропорции быть не должно. Эта проблема связана с симметричностью интервала.
У статистики на многое есть решение — и, оказалось, есть решение и на это. Вместо обычного ДИ, который приближает распределение пропорции нормальным, можно использовать Wilson score интервал. Интервалы Вильсона асимметричны за счет сдвига и добавления знаменателя — полная формула красиво объяснена тут. Интуитивно построение таково — если наблюдаемая пропорция близка к 0 или 1, то неопределённость в сторону границы меньше, чем в сторону центра. В питоне из коробки их тоже можно посчитать (см. statsmodels).
Пока копалась, нашла забавный учебник о том, что такое рисерч. В нем описано, как строить эксперименты, зачем ставить RQ, почему нужны доверительные интервалы и прочие базовые, но нужные вещи, которые помогают приземлиться при планировании эксперимента. Кроме того, в нем много практических задач (и в том числе объясняются те-самые-ДИ). Может, пригодится и вам.
Вчера потребовалось понять, как считать доверительный интервал для пропорции.
Эта задача возникает, когда у вас есть пропорция, посчитанная по N наблюдениям (скажем, число ответивших «да» в эксперименте). Дать одно число нечестно — при прочих равных эксперимент зависит от случайности. Поэтому всегда и везде, ДИ требуется.
В моем случае эта задача возникла рядом с анализом attack success rate (ASR) (успешной атаки на модель) в двух конфигурациях эксперимента. Какое-то время я изучала статьи, и меня эта метрика всегда вводила в ступор — она устоявшаяся, а меня все случаи оценки пропорций настораживают ещё от доли неправильных ответов из ML (accuracy). Поэтому, чтобы быть в ступоре поменьше (и потому что ДИ — это единственный корректный метод предоставления результата), было решено добавить больше формальности.
Обычные интервалы называются Wald intervals и проблема, которая заставила задуматься и не использовать их— это то, что в базовой постановке ДИ может выйти за [0,1], а значений больше 1 и меньше 0 для пропорции быть не должно. Эта проблема связана с симметричностью интервала.
У статистики на многое есть решение — и, оказалось, есть решение и на это. Вместо обычного ДИ, который приближает распределение пропорции нормальным, можно использовать Wilson score интервал. Интервалы Вильсона асимметричны за счет сдвига и добавления знаменателя — полная формула красиво объяснена тут. Интуитивно построение таково — если наблюдаемая пропорция близка к 0 или 1, то неопределённость в сторону границы меньше, чем в сторону центра. В питоне из коробки их тоже можно посчитать (см. statsmodels).
Пока копалась, нашла забавный учебник о том, что такое рисерч. В нем описано, как строить эксперименты, зачем ставить RQ, почему нужны доверительные интервалы и прочие базовые, но нужные вещи, которые помогают приземлиться при планировании эксперимента. Кроме того, в нем много практических задач (и в том числе объясняются те-самые-ДИ). Может, пригодится и вам.
corp.ling.stats
Binomial → Normal → Wilson
Introduction One of the questions that keeps coming up with students is the following. What does the Wilson score interval represent, and how does it encapsulate the right way to calculate a confid…
Forwarded from Записки MLEшника
Полезный сайтик https://deepwiki.directory, с ИИ описанием репозиториев. Из прикольного - не только текстом описывает, но и строит схемы с архитектурой. Мне так, действительно, легче вникнуть, если нет хорошей документации от разработчиков
Недавно, например, вникал в архитектуру библиотечки для рагов dsRAG. А вот ИИ дока для него.
Недавно, например, вникал в архитектуру библиотечки для рагов dsRAG. А вот ИИ дока для него.
Forwarded from Pavel
Павел Кикин_STEREO DATA ЁЛКА_спб_dsgn - new.pdf
2.4 MB
#llm #ml #systemdesign #interview
Chatted with AI tech leads hiring AI engineers.
Here's the stack they look for in interviews ↓
① 𝗦𝗪𝗘 + 𝗠𝗟 𝗕𝗮𝘀𝗶𝗰𝘀
SWE → Python, Docker, Version Control, APIs
ML → Data prep, feature eng, ML algos/evals
② 𝗟𝗟𝗠 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲𝘀
• DPO
• RLHF
• Quantization
• Transformers
• LoRA, QLoRa
• Flash Attention
• Diffusion Model
• RAG vs Fine-Tune
• Mixture of Experts
• DeepSeek Architecture
*No need experience in training these from scratch. Just need conceptual understanding.
③ 𝗔𝗜 𝗔𝗴𝗲𝗻𝘁 𝗢𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻
• RAG
• MCP
• DSPy
• CoT + ReAct
• Context Engineering
• Framework → LangGraph, PydanticAI
④ 𝗔𝗜 𝗦𝘆𝘀𝘁𝗲𝗺 𝗗𝗲𝘀𝗶𝗴𝗻
Problem → Scope → Design → Optimize (Scale, Cost, Availability)
• Design ChatGPT clone
• Design Browser agent
• Design SQL agent
*Knowing how to optimize for scale (10K vs 10M users, costs, 99% availability, reduce latency from 10 to 3 seconds).
⑤ 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲
Not optional. They aren't going to hire someone who's built an agent that works locally.
Knowing how to build and deploy agents that work on cloud services matter. AWS, GCP, Azure and etc, just pick a platform, and deploy it.
Chatted with AI tech leads hiring AI engineers.
Here's the stack they look for in interviews ↓
① 𝗦𝗪𝗘 + 𝗠𝗟 𝗕𝗮𝘀𝗶𝗰𝘀
SWE → Python, Docker, Version Control, APIs
ML → Data prep, feature eng, ML algos/evals
② 𝗟𝗟𝗠 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲𝘀
• DPO
• RLHF
• Quantization
• Transformers
• LoRA, QLoRa
• Flash Attention
• Diffusion Model
• RAG vs Fine-Tune
• Mixture of Experts
• DeepSeek Architecture
*No need experience in training these from scratch. Just need conceptual understanding.
③ 𝗔𝗜 𝗔𝗴𝗲𝗻𝘁 𝗢𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻
• RAG
• MCP
• DSPy
• CoT + ReAct
• Context Engineering
• Framework → LangGraph, PydanticAI
④ 𝗔𝗜 𝗦𝘆𝘀𝘁𝗲𝗺 𝗗𝗲𝘀𝗶𝗴𝗻
Problem → Scope → Design → Optimize (Scale, Cost, Availability)
• Design ChatGPT clone
• Design Browser agent
• Design SQL agent
*Knowing how to optimize for scale (10K vs 10M users, costs, 99% availability, reduce latency from 10 to 3 seconds).
⑤ 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 𝗘𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲
Not optional. They aren't going to hire someone who's built an agent that works locally.
Knowing how to build and deploy agents that work on cloud services matter. AWS, GCP, Azure and etc, just pick a platform, and deploy it.
Forwarded from Тимлид Очевидность | Евгений Антонов
Внедрение изменений по Бекхарду
Есть много разных фреймворков про внедрение изменений, но вы знаете, что я люблю, чтобы было просто и достаточно работоспособно. Вот один из таких вариантов — формула Бекхарда.
Сама формула:
D × V × F > R
D — неудовлетворенность текущей ситуацией (dissatisfaction);
V — видение будущего (vision);
F — первые конкретные шаги, которые могут быть предприняты для реализации видения (first steps);
R — сопротивление изменениям (resistance).
Всего лишь 3 самых важных компонента, которые надо учесть и правильным образом подогреть.
Неудовлетворенность текущей ситуацией
Как следует из названия — кто-то должен быть неудовлетворен ситуацией. Нередко изменения внедряются, потому что кто-то сверху неудовлетворен, снизу всем всё и так хорошо, но оно через силу пихается. А потом руководство расстраивается, что люди на местах — несговорчивые саботажники, а работники — что руководство самодурствует.
Да, может быть так, что вы, как руководитель, неудовлетворены, но вы должны подать информацию таким образом, чтобы и люди понимали, что им тоже не очень хорошо от текущей ситуации. Может быть, сейчас не очень хорошо, но они просто привыкли. А может, в будущем будет плохо, если всё так продолжится, как сейчас.
Видение будущего
Возможно, кого-то вдохновляют рассказы про космические корабли, бороздящие Большой театр. Я же хотел бы слышать несколько более конкретные вещи. Не то что я начинаю сразу «а на какую именно метрику это повлияет и на сколько?», просто хотелось бы понимать, что именно изменится, а не абстрактную воду про «станет эффективнее и прозрачнее». Здесь хорошо бы сделать отсылку к предыдущему пункту и к Саше Брызгаловой, которая любит повторять: «Если это решение, то в чем проблема?».
Первые шаги
Практически всех пугает большое и долгое изменение привычного образа жизни и работы. Но если вы сможете его раздробить на простые шаги и показать, что для начала достаточно всего лишь не сильно-то поменять один привычный паттерн, чтобы уже стало лучше, то это укрепит ваше предложение в глазах тех, кого вы хотите «напрячь». Если при этом окажется удачной связка: первые легкие шаги – первые собранные низковисящие фрукты, то доверие к вашим предложениям сильно укрепится и саботаж вряд ли произойдет.
Итог
Самый простой и, казалось бы, очевидный (но не всегда), способ что-то поменять у людей — показать, почему это вам и им нужно, что именно изменится и как легко начать эти изменения получать. Дальше уже у вас будет кредит доверия, смотрите не продолбайте его, если вдруг вы решили, что надо ограничиться только обещаниями 🙂 Обещания должны или совпасть с результатами, или вы должны объяснить, почему они не совпали и что теперь делать с этим.
Есть много разных фреймворков про внедрение изменений, но вы знаете, что я люблю, чтобы было просто и достаточно работоспособно. Вот один из таких вариантов — формула Бекхарда.
Сама формула:
D × V × F > R
D — неудовлетворенность текущей ситуацией (dissatisfaction);
V — видение будущего (vision);
F — первые конкретные шаги, которые могут быть предприняты для реализации видения (first steps);
R — сопротивление изменениям (resistance).
Всего лишь 3 самых важных компонента, которые надо учесть и правильным образом подогреть.
Неудовлетворенность текущей ситуацией
Как следует из названия — кто-то должен быть неудовлетворен ситуацией. Нередко изменения внедряются, потому что кто-то сверху неудовлетворен, снизу всем всё и так хорошо, но оно через силу пихается. А потом руководство расстраивается, что люди на местах — несговорчивые саботажники, а работники — что руководство самодурствует.
Да, может быть так, что вы, как руководитель, неудовлетворены, но вы должны подать информацию таким образом, чтобы и люди понимали, что им тоже не очень хорошо от текущей ситуации. Может быть, сейчас не очень хорошо, но они просто привыкли. А может, в будущем будет плохо, если всё так продолжится, как сейчас.
Видение будущего
Возможно, кого-то вдохновляют рассказы про космические корабли, бороздящие Большой театр. Я же хотел бы слышать несколько более конкретные вещи. Не то что я начинаю сразу «а на какую именно метрику это повлияет и на сколько?», просто хотелось бы понимать, что именно изменится, а не абстрактную воду про «станет эффективнее и прозрачнее». Здесь хорошо бы сделать отсылку к предыдущему пункту и к Саше Брызгаловой, которая любит повторять: «Если это решение, то в чем проблема?».
Первые шаги
Практически всех пугает большое и долгое изменение привычного образа жизни и работы. Но если вы сможете его раздробить на простые шаги и показать, что для начала достаточно всего лишь не сильно-то поменять один привычный паттерн, чтобы уже стало лучше, то это укрепит ваше предложение в глазах тех, кого вы хотите «напрячь». Если при этом окажется удачной связка: первые легкие шаги – первые собранные низковисящие фрукты, то доверие к вашим предложениям сильно укрепится и саботаж вряд ли произойдет.
Итог
Самый простой и, казалось бы, очевидный (но не всегда), способ что-то поменять у людей — показать, почему это вам и им нужно, что именно изменится и как легко начать эти изменения получать. Дальше уже у вас будет кредит доверия, смотрите не продолбайте его, если вдруг вы решили, что надо ограничиться только обещаниями 🙂 Обещания должны или совпасть с результатами, или вы должны объяснить, почему они не совпали и что теперь делать с этим.
Forwarded from Статистика и R в науке и аналитике
p-value, альфа и ошибка первого рода: как не перепутать
Это будет простой теоретический разбор ключевых понятий в статистике.
Для разогрева я спрятала под спойлер определения, попробуйте их распределить самостоятельно и ответить, как они связаны между собой.
alpha – верхняя граница вероятности ошибки первого рода.
p-value – вероятность найти такие же или еще более экстремальные значения тестовой статистики при условии верности нулевой гипотезы.
ошибка первого рода – отвергли нулевую гипотезу, когда она была верна (например, нашли отличия, там где их на самом деле нет).
А как они связаны между собой?
1. Мы сравниваем p-value с альфой, чтобы отвергнуть или не отвергнуть нулевую гипотезу.
2. При проведении множества независимых тестов с верностью нулевой гипотезы ожидаемая доля ошибок первого рода не превышает заданную альфу. Например, если мы проводим 100 A/A-тестов с α = 0.05, то в среднем примерно в 5 тестах мы отвергнем H₀ (то есть сделаем ошибку первого рода).
Важно: в конкретном тесте мы никогда не знаем, совершили ли ошибку первого рода (это уже случилось или нет). Но когда мы фиксируем альфу заранее, мы контролируем долгосрочную частоту таких ошибок — при большом числе повторений она будет близка к α (но есть нюансы, подробнее ниже).
3. Следствие: чем меньше альфа, тем реже будет ошибка первого рода. Однако при этом увеличится ошибка второго рода, всегда приходится балансировать между двумя типами ошибок.
Нюанс: в реальной жизни альфа не всегда совпадает с фактической вероятностью ошибки первого рода (ошибка бывает больше). Когда это происходит и как этого избежать?
🟡 Множественные сравнения
При тестировании множества гипотез (несколько групп, метрик) возрастает вероятность совершить хотя бы одну ошибку первого рода. Если не делать поправку, то мы уже не контролируем альфа на заданном уровне.
Решение: использовать поправки на множественные сравнения (Бонферрони, Холм, FDR) в зависимости от задачи. Более подробно можно почитать здесь.
🟡 Подглядывание в A/B тесты
Если мы многократно проверяем результаты A/B теста и останавливаем эксперимент при первом p-value < 0.05, это эквивалентно множественным проверкам гипотез и приводит к завышению ошибки первого рода.
Решение: использовать методы sequential testing.
🟡 Не выполнены предпосылки теста
Например, используем t-тест Стьюдента (не Велча) для выборок с разной дисперсией и разного объема, в результате мы можем сильно завысить уровень ошибки первого рода, подробнее здесь.
Решение: использовать тест Велча.
Другие примеры, когда ошибка первого рода возрастает в случае несоблюдения предпосылок теста, предлагаю накидать в комментарии.
Подсказка: это может быть связано с одной из любимых тем на этом канале)
Пишите в комментариях, не путаете ли вы термины, и сталкивались ли с ситуациями, когда ошибка первого рода превышала альфу.
#stats #stat_hard #analytics
Это будет простой теоретический разбор ключевых понятий в статистике.
Для разогрева я спрятала под спойлер определения, попробуйте их распределить самостоятельно и ответить, как они связаны между собой.
А как они связаны между собой?
1. Мы сравниваем p-value с альфой, чтобы отвергнуть или не отвергнуть нулевую гипотезу.
2. При проведении множества независимых тестов с верностью нулевой гипотезы ожидаемая доля ошибок первого рода не превышает заданную альфу. Например, если мы проводим 100 A/A-тестов с α = 0.05, то в среднем примерно в 5 тестах мы отвергнем H₀ (то есть сделаем ошибку первого рода).
Важно: в конкретном тесте мы никогда не знаем, совершили ли ошибку первого рода (это уже случилось или нет). Но когда мы фиксируем альфу заранее, мы контролируем долгосрочную частоту таких ошибок — при большом числе повторений она будет близка к α (но есть нюансы, подробнее ниже).
3. Следствие: чем меньше альфа, тем реже будет ошибка первого рода. Однако при этом увеличится ошибка второго рода, всегда приходится балансировать между двумя типами ошибок.
Нюанс: в реальной жизни альфа не всегда совпадает с фактической вероятностью ошибки первого рода (ошибка бывает больше). Когда это происходит и как этого избежать?
При тестировании множества гипотез (несколько групп, метрик) возрастает вероятность совершить хотя бы одну ошибку первого рода. Если не делать поправку, то мы уже не контролируем альфа на заданном уровне.
Решение: использовать поправки на множественные сравнения (Бонферрони, Холм, FDR) в зависимости от задачи. Более подробно можно почитать здесь.
Если мы многократно проверяем результаты A/B теста и останавливаем эксперимент при первом p-value < 0.05, это эквивалентно множественным проверкам гипотез и приводит к завышению ошибки первого рода.
Решение: использовать методы sequential testing.
Например, используем t-тест Стьюдента (не Велча) для выборок с разной дисперсией и разного объема, в результате мы можем сильно завысить уровень ошибки первого рода, подробнее здесь.
Решение: использовать тест Велча.
Другие примеры, когда ошибка первого рода возрастает в случае несоблюдения предпосылок теста, предлагаю накидать в комментарии.
Подсказка: это может быть связано с одной из любимых тем на этом канале)
Пишите в комментариях, не путаете ли вы термины, и сталкивались ли с ситуациями, когда ошибка первого рода превышала альфу.
#stats #stat_hard #analytics
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Заскуль питона (Аналитика данных)
Проблемы с фокусом во время работы — это не лень
Вы погружены в задачу, хочется ее решить.
Голова работает.
Но...
1️⃣ Вас выдергивают на важные встречи.
2️⃣ Вам спамят личку и спрашивают, какой статус по задаче
3️⃣ Вы думаете, что задачу нужно отдать идеально
4️⃣ Вы переключились на другую вкладку и в итоге забыли, зачем открывали
5️⃣ Параллельно вы начали делать другую задачу
И под конец рабочего дня задача не сделана, вы устали, чувствуете вину
Фокус ломается не из-за лени, а из-за среды и когнитивной перегрузки. Это проблема неправильной организации внимания.
🟢 Должен быть четкий объект фокуса. Нужно себе ответить на вопрос, над чем сейчас работаешь, чтобы явно себе понять, на чем нужно сфокусироваться.
🟢 Отключить ненужные уведомления. Нам кажется, что мы постоянно должны впитывать любую информацию. Но любая информация — это потеря фокуса на основных задачах 🔕
🟢 Выбрать оптимальную технику для фокуса. Это может быть Pomodoro, Deep Work, Pomodoro 2.0 даже. Техники бывают разные, в Яндексе я старался работать по Deep Work и это было эффективно. Сейчас выбираю для себя Pomodoro 🍅
🟢 Убрать мелкие выборы. Иногда себя ловлю на мысли о том, а какую вкладку нужно открыть (особенно, когда их много). Ранее слышал, что любое принятие решение тратит когнитивные силы, поэтому убираем 🤔
🟢 Фиксировать момент потери фокуса. Вы отвлеклись на другое дело? Это важно, потому что фокус теряется не случайно.
📺 Кстати, у Андрея было классное видео про то, как он вернул себе фокус на задачах
Еще из прикольного: там говорится о разгрузке мозга с помощью любого текстового документа, физическую активность...
📕 В видео еще было упомянуто про исследование, в котором говорится о том, что постоянное переключение между потоками информации делает мозг менее способным сосредотачиваться и игнорировать отвлекающие раздражители, что ухудшает когнитивный контроль и рабочую эффективность. Интересно, что на некоторых местах работы считалось базой делать несколько задач одновременно. Все теперь понятно...
А как у вас с фокусом? Теряетесь или все в порядке? Ставьте🐳 , если пост понравился, делитесь с теми, у кого проблемы с фокусом
@zasql_python
Вы погружены в задачу, хочется ее решить.
Голова работает.
Но...
И под конец рабочего дня задача не сделана, вы устали, чувствуете вину
Фокус ломается не из-за лени, а из-за среды и когнитивной перегрузки. Это проблема неправильной организации внимания.
Еще из прикольного: там говорится о разгрузке мозга с помощью любого текстового документа, физическую активность...
А как у вас с фокусом? Теряетесь или все в порядке? Ставьте
@zasql_python
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from LLM под капотом
Я попробовал Linear, который OpenAI использует вместо JIRA для разработки
(еще его использует Cursor, Coinbase, Vercel, Perplexity, Substack, Lovable и Polymarket)
Linear выглядит как нормальная и удобная JIRA для разработки проектов (таски, проекты итп). Быстрая и легкая. Но там есть нативная интеграция для делегирования задач кодексу, которая настроилась в пару кликов. И получается, что я могу вести задачи в смешанной команде людей и агентов, раскидывая задачи между кодексом и людьми.
Кодекс при получении задачи браво рапортует в комментариях, запускает весь процесс, линкует прогресс (или возвращается с вопросами). А после выполнения задачи, когда я просмотрел PR и отправил его в main, Linear перетаскивает задачу в выполненное.
И вот это ощущение от интеграции масштабируемых агентов в старый и знакомый процесс разработки - второй слом моего мозга в этом году (первый).
Пару скриншотов кину в комментарии. Но внешне там нет ничего особенного, вся фишка от ощущения масштабирования процесса!
Ваш, @llm_under_hood 🤗
PS: Если вдруг забанило в комментариях после вступления - это нормально. Валидацию я переделываю, скоро поправим.
(еще его использует Cursor, Coinbase, Vercel, Perplexity, Substack, Lovable и Polymarket)
Linear выглядит как нормальная и удобная JIRA для разработки проектов (таски, проекты итп). Быстрая и легкая. Но там есть нативная интеграция для делегирования задач кодексу, которая настроилась в пару кликов. И получается, что я могу вести задачи в смешанной команде людей и агентов, раскидывая задачи между кодексом и людьми.
Кодекс при получении задачи браво рапортует в комментариях, запускает весь процесс, линкует прогресс (или возвращается с вопросами). А после выполнения задачи, когда я просмотрел PR и отправил его в main, Linear перетаскивает задачу в выполненное.
И вот это ощущение от интеграции масштабируемых агентов в старый и знакомый процесс разработки - второй слом моего мозга в этом году (первый).
Пару скриншотов кину в комментарии. Но внешне там нет ничего особенного, вся фишка от ощущения масштабирования процесса!
Ваш, @llm_under_hood 🤗
PS: Если вдруг забанило в комментариях после вступления - это нормально. Валидацию я переделываю, скоро поправим.
Forwarded from АННА В ДАННЫХ
Как в компаниях борются с тяжелыми запросами ⌨️
Существуют разные подходы к тому, чтобы не случилось мемной ситуации, когда аналитик случайно положил базу
Как правило аналитики не имеют доступа к продовой БД и работают в аналитических репликах, но плохой запрос там может помешать обновлению дашбордов, загрузке витрин и работе коллег
🔵 Автоматические лимиты в СУБД
Например, по времени выполнения или объему потребляемой памяти. При превышении запрос упадет с ошибкой, и аналитику ничего не останется, кроме как оптимизировать его
🔵 Киллеры плохих запросов
Может существовать скрипт с более гибкими и сложными условиями, который сканирует выполняющиеся запросы и “убивает” все подозрительные
🔵 Социальное давление или доска позора
Тогда явных ограничений может и не быть, но каждый аналитик знает: если из-за его запроса все начнет виснуть, админы опубликуют его в общий доступ с очень неприятной припиской. Опасаясь общественного порицания, аналитики пускают в ход все свои знания об оптимизации запросов
🔵 Другая версия этого - полная прозрачность
Когда каждый может посмотреть содержимое и авторов выполняющихся сейчас запросов. И в личку к виновнику сразу повалят его коллеги
🔵 Запрет доступа к сырым данным
Могут ограничить доступ к гигантским сырым таблицам для отдельных ролей, а дать только к витринам с уже агрегированными данными. Это избавляет от лишних вычислений и сокращает количество обрабатываемых строк
А какой подход выбран у вас в компании и какой предпочли бы?
Существуют разные подходы к тому, чтобы не случилось мемной ситуации, когда аналитик случайно положил базу
Например, по времени выполнения или объему потребляемой памяти. При превышении запрос упадет с ошибкой, и аналитику ничего не останется, кроме как оптимизировать его
Может существовать скрипт с более гибкими и сложными условиями, который сканирует выполняющиеся запросы и “убивает” все подозрительные
Тогда явных ограничений может и не быть, но каждый аналитик знает: если из-за его запроса все начнет виснуть, админы опубликуют его в общий доступ с очень неприятной припиской. Опасаясь общественного порицания, аналитики пускают в ход все свои знания об оптимизации запросов
Когда каждый может посмотреть содержимое и авторов выполняющихся сейчас запросов. И в личку к виновнику сразу повалят его коллеги
Могут ограничить доступ к гигантским сырым таблицам для отдельных ролей, а дать только к витринам с уже агрегированными данными. Это избавляет от лишних вычислений и сокращает количество обрабатываемых строк
А какой подход выбран у вас в компании и какой предпочли бы?
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Заметки LLM-энтузиаста
Обратите внимание на интересные функции Kilo Code
- App Builder (по сути, можно заменить функциональность bolt.new или lovable.dev - пока только фронтенд часть, но зато можно выбирать модели, и топовые "китайцы" сейчас бесплатные). Функциональность вышла прямо "под Новый Год"
- Deploy (можно сразу разворачивать next.js проекты)
Также используя комбинацию Cloud Agent + Sessions + Webhooks + Code Reviewer + Deploy можно выстроить AI-driven CI/CD пайплайн (как Github Actions, только с AI-"маршрутизацией")
При этом как в Roo Cloud есть возможность перехватывать сессию разработки, которая велась на локальном ПК
Также как в Claude Code есть свой Kilocode CLI, есть возможность использовать AGENTS.md файл и каталог со SKILLS (можно выбрать из библиотеки или создать собственный - skill builder прилагается), можно запускать агентов параллельно для ускорения разработки.
В общем, мне кажется, что если выбирать сейчас между Roo Code/Cline и Kilo Code, то Kilo Code лидирует (тем более, что в нем также как и в Roo Code теперь можно подключить Claude Max план)
Подробности есть в документации https://kilo.ai/docs
#kilocode #vibecoding
- App Builder (по сути, можно заменить функциональность bolt.new или lovable.dev - пока только фронтенд часть, но зато можно выбирать модели, и топовые "китайцы" сейчас бесплатные). Функциональность вышла прямо "под Новый Год"
- Deploy (можно сразу разворачивать next.js проекты)
Также используя комбинацию Cloud Agent + Sessions + Webhooks + Code Reviewer + Deploy можно выстроить AI-driven CI/CD пайплайн (как Github Actions, только с AI-"маршрутизацией")
При этом как в Roo Cloud есть возможность перехватывать сессию разработки, которая велась на локальном ПК
Также как в Claude Code есть свой Kilocode CLI, есть возможность использовать AGENTS.md файл и каталог со SKILLS (можно выбрать из библиотеки или создать собственный - skill builder прилагается), можно запускать агентов параллельно для ускорения разработки.
В общем, мне кажется, что если выбирать сейчас между Roo Code/Cline и Kilo Code, то Kilo Code лидирует (тем более, что в нем также как и в Roo Code теперь можно подключить Claude Max план)
Подробности есть в документации https://kilo.ai/docs
#kilocode #vibecoding
Forwarded from commit history
Как попробовать Claude Opus 4.5 и другие модели в CLI-агенте бесплатно
За последние полтора года из первого ряда наблюдал как сильно выросли способности моделей в формате кодинг агентов. При этом кто-то еще не пробовал сделать проект просто агентами, без погружения в код, хотя желание есть.
Не у всех есть enterprise-подписка на Codex, Claude или Cursor, либо лишние $100–200 в месяц. При этом $10 в том же Cursor выедаются довольно быстро, если запускать агента на задачах чуть сложнее простых автокомплитов.
Фронтирные модели уже нормально работают в агентских обвязках. На бенчмарках топовые модели идут примерно на одном уровне, на последнем ребенче например лидирует Opus. При этом сами агентские скаффолды сходятся к одному и тому же набору инструментов, поэтому можно спокойно пробовать разные cli агенты, не переживая, что они сильно отличаются.
Есть такой очередной агент/обвязка. AMP Code.
Они дают $10 в день, взамен показывают рекламу. Реклама ненавязчивая, просто висит над окном ввода.
Есть плагины почти для всего: VS Code, JetBrains, Neovim. Я пользуюсь CLI-версией.
https://ampcode.com/install
P.S.
Когда появляется такой инструмент, сначала может быть непонятно, что с ним делать. Поэтому для тестового запуска я всегда прошу реализовать браузерный Doom. В школе 21 этот проект раньше был в конце ветки геймдева.
В итоге вышло около $2 из суточных $10 за 1.5 млн токенов.
Тут можно посмотреть, какая траектория получилась:
https://ampcode.com/threads/T-019bcc0d-7ac8-710a-a273-8513be37694e
За последние полтора года из первого ряда наблюдал как сильно выросли способности моделей в формате кодинг агентов. При этом кто-то еще не пробовал сделать проект просто агентами, без погружения в код, хотя желание есть.
Не у всех есть enterprise-подписка на Codex, Claude или Cursor, либо лишние $100–200 в месяц. При этом $10 в том же Cursor выедаются довольно быстро, если запускать агента на задачах чуть сложнее простых автокомплитов.
Фронтирные модели уже нормально работают в агентских обвязках. На бенчмарках топовые модели идут примерно на одном уровне, на последнем ребенче например лидирует Opus. При этом сами агентские скаффолды сходятся к одному и тому же набору инструментов, поэтому можно спокойно пробовать разные cli агенты, не переживая, что они сильно отличаются.
Есть такой очередной агент/обвязка. AMP Code.
Они дают $10 в день, взамен показывают рекламу. Реклама ненавязчивая, просто висит над окном ввода.
Есть плагины почти для всего: VS Code, JetBrains, Neovim. Я пользуюсь CLI-версией.
https://ampcode.com/install
P.S.
Когда появляется такой инструмент, сначала может быть непонятно, что с ним делать. Поэтому для тестового запуска я всегда прошу реализовать браузерный Doom. В школе 21 этот проект раньше был в конце ветки геймдева.
В итоге вышло около $2 из суточных $10 за 1.5 млн токенов.
Тут можно посмотреть, какая траектория получилась:
https://ampcode.com/threads/T-019bcc0d-7ac8-710a-a273-8513be37694e
Ampcode
Doom 3D clone TypeScript project plan