#llm #code #petproject

Обратите внимание на интересные функции 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

#llm #code #petproject

Как попробовать 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

Моё решение — 5/216 место на VK RecSys Challenge LSVD

Мне было интересно снова поучаствовать в соревновании, чтобы проверить некоторые идеи, поучить Polars и поразвивать интуицию вокруг RecSys. Ниже кратко напишу про результаты.

Задача: нужно было предсказать 100 пользователей, которые лайкнут клип VK Видео, причём с самим клипом в истории нет взаимодействий.

Бейзлайн: будем «рекомендовать» тех юзеров, которые уже лайкали автора в прошлом. Сортируем по сумме лайков. Это уже ~30/216 место.

Решение: возьмём всех юзеров, которые видели автора клипа, и отсортируем их с помощью LGBMRanker. Подробнее — в презентации.

Чего было у тех, кто выше, но не было у меня: трансформер, DCN, SANSA, CatBoost. Я не смог это качественно заиспользовать.

Чем хочется поделиться:

1) Я использовал идею из поста 2023 года канала Wazowski Recommends с экспоненциальными счётчиками, чтобы «переварить» все данные. Для расчёта фичей я использовал словари в словарях в Python с помощью кода на ~500 строк, который мне полностью написала ChatGPT. Грубо говоря, я пробежался for-циклом по всему датасету и с экспоненциальным затуханием насчитал все фичи без даталиков.

2) Всех юзеров я разбил по user_id % M == k и работал только с выбранной пачкой (простое шардирование), что позволило гибко настраивать trade-off «скорость vs RAM». Это был ключевой шаг, чтобы обработать все данные.

3) Я пытался искусственно побить клипы на кластеры по контенту и насчитать фичи, но это оказалось бесполезным занятием. У меня есть теория, что когда ты создаёшь группировку user/item на основе контента, но такой группировки не существует в самом сервисе, — это бесполезно для качества.
Например, если мы рекомендуем продукты питания, у нас есть категоризация сервиса и фичи вида user–category. Категории существуют в каталоге → фичи значимые. Если же мы создадим semantic id и посчитаем фичи вида user–semantic-id, эти фичи дадут меньший эффект, чем user–category.

4) Задача подбора аудитории в целом — это во многом история про борьбу за активных людей. Если у вас есть приложение, в котором вы показываете баннер, и вы спросите: кто кликнет на него завтра? Я бы собрал аудиторию из самых активных пользователей приложения. Если отправлять email и собирать аудиторию, кто его прочитает, — это те, кто чаще всего читает email. Тут никакой RecSys / ML не нужен.

И здесь есть тонкая грань между персонализацией и простой эксплуатацией самого активного ядра юзеров под любые нужды. Недаром авторы RecSys Challenge поставили ограничение, что нельзя выбирать одного юзера 101+ раз.

5) Соревнование для меня — во многом про аккуратность, правильную приоритизацию гипотез и доведение их проверки до конца. Также важны тайм-менеджмент, готовность полностью погружаться в эксперименты и терпимость к тому, что очередная идея не улучшает результат.

В общем, участие оказалось очень полезным, всем советую попробовать себя в соревнованиях по Recsys)

#dl #nlp #cv #interview

#search #petproject

#sql #courses #novice

LeetСode Study Plan SQL 50

Как я провел лето длинные зимние каникулы – решал задачки по SQL с LeetСode из SQL 50 Study Plan.

Study Plan'ы на LeetСode сделали достаточно давно, но я их открыл только перед новым годом 🤦‍♂️. Это коллекции задачек по заданной технологии, сгруппированных по темам и уровням. Я когда-то записывал видео с разбором задач по SQL c LeetСode, но тогда Study Plan еще не было. И в целом задач по SQL на LeetСode было не очень много. Поэтому видео получилось мало и по тематике они были разбросаны.

В плане SQL 50, как можно понять из названия, 50 задач по SQL. Что важно, все задачи бесплатные. По уровню задачи рассчитаны от начинающего до продвинутого (basic to intermediate). Задачи разбиты по темам:
- SELECT.
- Базовые JOIN'ы.
- Базовые функции агрегации.
- Сортировка и группировка.
- Продвинутые SELECT'ы и JOIN'ы.
- Подзапросы.
- Продвинутые функции для обработки срок и регулярные выражения.

Задачи в основном уровня Easy (32 штуки) и Medium (17 штук), уровня Hard всего одна задача. Причем Hard не очень сложная, в ней нужно применить много различных особенностей SQL одновременно, но особых хитростей нет. Над многими задачами уровня Medium я думал значительно дольше, чем над хардовой задачей.

В целом особенность задач по SQL на LeetСode в том, что почти все содержат хотя бы небольшие, но хитрости. Поэтому даже над простыми задачами приходится задумываться и решение получается не сразу. Зато значительно лучше понимаешь, как действительно работает SQL и как его применять для практических задач с реальными ограничениями.

За каникулы успел решить все задачи из SQL 50. Для их решения почти достаточно моего курса по SQL. Не хватает следующих тем:
- Условный оператор CASE.
- Работа с NULL, в том числе COALESCE.
- Функции работы с датами, строками, регулярными выражениями и т.п.
Также будут полезны CTE, но их использовать не обязательно.

Рекомендую решить SQL 50, если вы начинаете изучать SQL, или хотите его вспомнить для подготовки к собеседованию. Я сам дальше планирую решать на LeetCode задачи уровня Hard. А также задачи на оконные функции, т.к. их в SQL 50 не было.

На LeetCode также есть продвинутый Study Plan Advanced SQL 50, но он только за деньги 😞. Из полезного еще есть два Study Plan'а по Pandas: Introduction to Pandas и 30 Days of Pandas. Недостаток – в них много задачек из SQL 50, но решать их нужно не с помощью SQL, а в Pandas. Код на Pandas написать полезно, но думать второй раз над задачкой уже не придется...

#quant #courses

#ab #statistics

Привет, товарищи-статистики!

Влад опять сделал это: нашел новую свежую статью, которую я коротко окрестил бы как "точки над CUPED". Пока Владислав пилит свой пост на тему как статьи, так и CUPED (ожидайте!), я отмечу самое примечательное на мой взгляд:

1) Начнем с того, что китайцы, выделили два вида симуляций: DBF - Design-Based Framework и MDF - Model-based framework.

Во время теста мы, как правило, случайно сплитуем пользователей в группы A и B, то есть у нас есть механизм назначения - рандомная сплитовалка, это раз.

Второе, модель генерации данных / модель, порождающая данная: во время симуляции мы можем задать популяцию на основе нормального распределения с Mu=24, sigma=2, то есть наша популяция (данные) будут порождены (сгенерированы) моделью N(24, 2)

population = np.random.default_rng().normal(mu_H0, sigma, population_size)
sample_based_on_population = np.random.choice(population, size = sample_size)

Далее мы брали выборки из этой популяции (тогда она сама бы была порождающей данные)
Но... а что если сразу задавать модель генерации данных на уровне выборки? Те же N(24, 2), только всего, условно, пара-тройка измерений?...

sample_based_on_model = np.random.default_rng().normal(mu_H0, sigma, sample_size)

Вот об этом и речь, что есть два подхода к симуляции, которые могут давать разные результаты при проверке работоспособности критериев:

1.1. DBF - Design-Based Framework, это подход к причинному выводу и статистическому анализу,
в котором единственным источником случайности считается механизм назначения (сплитовалка),
а не модель генерации данных

1.2. MBF - Model-based framework (модельно-ориентированный подход) - это подход к статистическому выводу, в котором данные рассматриваются как реализации случайных величин (в рамках выборок),
порождённых некоторой вероятностной моделью, а случайность исходит от процесса генерации данных, а не от сплитовалки.

При этом вся математика с ее E(X)=... построена именно на Model-based: поэтому если вы хотите обобщения корректности выводов вашей придумки для всех-всех, то надо обязательно доказывать корректность модели на MDF подходе, иначе вы просто доказали, что это работает в рамках вашей оценки ген. совокупности (DBF), то есть только для вашего случая (!)

В чем разница в рамках результатов симуляции-то?
MDF cимуляция каждый раз генерирует _новые_ данные. Если в модели заложен тяжелый хвост, выбросы будут приходить всегда вне ограничений по удаленности, но такое ограничение как раз будет при DBF (=просто популяция, мы делаем ее большой, но не бесконечной, а значит и не весь хвост соберёем). Используя MBF там, где надо DBF (а мы всегда в этом формате работаем), можно получить слишком много шума (=большая дисперсия), то есть.

Коротко: сначала проверка через Model-Based framework, а потом на Design-Based Framework на своих исторических данных; в случае же чистых симуляций, если у вас n очень большое, то особой разницы уже не будет.

2) Китайцы вывели поправку для theta (это такой коэффициент, который оптимальным образом позволяет ковариате минимизировать дисперсию), когда мы считаем ее отдельно для контроля и теста.

Всего есть три сценария расчета theta, которые вызывали (кажется, до этого момента) споры в индустрии:
1. theta сразу по всем данным теста и контроля, - используют Booking, Walmart, Statsig (Стасик, Стасик, Стасик, - сможешь ли ты меня остановить!?)
2. theta "усреднённая" (pooled) по тесту, контролю, - Netflix, Airbnb
3. отдельно по данным групп, - запрещенная в РФ Meta, Microsoft; эта theta как раз спорная, так как при не шибко больших выборках и MDF может быть смещенность дельты (не совпадать с истинным, например, нулем при отсутствии эффекта).

Но:
- cкриншот показывает, что 3-ая при DBF менее конвервативна и самая мощная из всех
- самое важное: китайские братушки вывели поправку для дисперсии разниц CUPED, чтобы не бояться bias'a! И при этом вывели они просто через базу в статистике! Ту самую, которую скипнуть бы и обмазаться сразу кьюдеп-х*юпед. Оказывается, нельзя! База всему голова.

Проникнуться гениальностью вывода

#ml #dl #llm #interview

RAG на практике

RAG – наверное, второе по популярности слово в индустрии после ai-aгент. Всем нужен RAG.

Наткнулся на статью победителя RAG Challenge. Это соревнование, где нужно было за 2.5 часа спарсить 100 PDF-отчётов (до 1000 страниц каждый) и построить QA-систему. Автор занял первое место. В статье описал весь пайплайн, показал код, рассказал, на какие грабли наступил – получилось очень интересно и практично.

Парсинг
Первый этап – превратить PDF в текст. Казалось бы, стандартная задача. Автор перепробовал пару десятков парсеров и пришёл к выводу: нормальных не существует. Таблицы разваливаются, многоколоночный текст путается. Пришлось форкнуть Docling и допиливать руками.

Индексация
Дальше текст нарезается на куски и складывается в векторную базу для поиска. Ключевое решение – отдельная база на каждую компанию. Зачем мешать метрики разных компаний в одну кучу? Область поиска сразу сужается в 100 раз.

Поиск
Векторный поиск возвращает топ-N результатов, но ранжирует их довольно грубо – при векторизации часть смысла теряется. В итоге в топ-10 попадает релевантная информация, но не всегда на первых местах.

Логичная идея – добавить классический текстовый поиск (BM25) и скомбинировать результаты. Автор попробовал – не зашло. Гибридный поиск чаще ухудшал качество, чем улучшал.

Зато сработал другой подход: достаём топ-30 из векторного поиска и просим gpt-4o-mini оценить релевантность каждого куска. Получается точнее, чем любой алгоритмический реранкинг. И стоит меньше цента на вопрос.

Генерация ответа
Чем больше правил даёшь модели в одном промпте, тем хуже она им следует. Модель начинает что-то игнорировать или путать.

Решение – роутинг, в зависимости от типа ожидаемого ответа вопрос уходит в разные промпты. В каждом – только релевантные правила.

Ещё одна проблема: модели дообучены быть полезными. Если в контексте нет прямого ответа, модель склонна притянуть что-то похожее за уши вместо честного – не знаю.

Помогает Structured Output + Chain of Thought: модель сначала рассуждает в отдельном поле, анализирует контекст с разных сторон, и только потом даёт ответ. Это заметно снижает количество галлюцинаций.

Неоднозначность
Отдельная история – что вообще считать правильным ответом. «Who is the CEO?» – звучит просто. Но CEO это только Chief Executive Officer? Или Managing Director тоже подходит? А President? И таких вопросов в бизнес-области может быть мильон.

Автор называет это – порогом свободы интерпретации. И его приходится калибровать с заказчиком вручную, разбирая edge cases.

Вывод такой, что для построения RAG нет одного магического решения. Качество складывается из мелочей на каждом этапе. И чем глубже понимаешь задачу – тем точнее можешь эти мелочи настроить.

Статью очень рекомендую.

#ai