Forwarded from Дата канальи — про «специалистов» в данных / ML / AI
Летят V самолётов, нет V мало — K! и оба реактивные...
У опроса выше есть всего один правильный ответ, и мы к нему придем.
А пока разберем мифы
Напомню только что валидация (в тч кросс-валидация) модели — это не только способ выбрать лучшую среди класса моделей (лучшую == точнее , устойчивее, сильнее, с меньшим риском и пр), но и получить интервальные оценки ее качества.
Миф 1. LOO на практике почти не используется
LOO — в варианте не Jackknifing, а Hold Out — в котором test — последний элемент, val — предпоследний, а остальное — трейн — это частый сетап в академических статьях про рекомендашки (тк академики часто обделены вычислительными ресурсами + им нужно сравниваться с предшественниками в их сетапе -- как в байке с шириной железной дороги и ее связи с шириной римской телеги.
Примеры, которые были под рукой:
NIPS 2023
KDD 2023
RecSys 2023
CIKM 2020
IJCAI 2019
Миф 2. Двойная кросс-валидация позволит сделать вашу модель более робастой
Вопрос некогда популярной в задачах на малых выборках двойной кросс-валидации (Nested) закрылся около 2018 с итогом что игра не стоит свеч. В соревновательной практике тоже особо не применялась — проще оказалось усреднять по cидам. Спасибо Себастьяну Рашке, который честно сравнил как лучше всего получать интервальные оценки качества моделей.
Кстати, модификаций кросс-валидаций для малых выборок десятки, начиная с Balance-Incomlete CV, Monte-Carlo CV (с возвращениями) и заканчивая всякими Bayessian CV
Миф 3. Выбор K в K-fold валидации ни на что не влияет
В 2015 вышла (и обновлялась до 2018) 99-страничная инструкция как правильно выбрать V в V-fold валидации.
Жаль, что ей никто не пользуется 😂😂🤣
Миф 4. .632 это калибр 🔫
Нет, это тоже модификация кросс-валидации в статьях 90х. Вообще, применить бутстрап к кросс-валидации тянуло многих.
Тем, кому любопытно — снова пример в блоге Себастьяна Рашки.
Миф 5. K-fold vs V-fold
Burman в 1989 обозначил уже известную к тому времени процедуру как V-fold
В бессмертном ESL (а первое издание было в 2001 году) уже K-fold
Оттуда оно, вероятно, попало в sklearn в 2007-10 и понеслось, 64k звезд на гитхабе — не шутки.
Миф 6. Все вопросы с валидацией / кросс-валидацией решены еще 20-30-60 лет назад
Одни парни и в 2025 пишут, другие их рецензируют. Не знаете о чем писать диплом по ML -- возьмите любую задачу и сравните несколько протоколов валидации численно и теоретически.
Миф 7. На опрос выше нет правильного ответа.
Хотя опрос достаточно спорный (не очевидна, например, необходимость OOT в картинках, хотя можно придумать кейс), можно предположить что:
1. Больше всего DS работают там где больше всего денег — в продажах и рекламе, а это всякие response-модели NBO / NBA / RecSys + исторически в банках (снова response-модели вроде PD + регрессии в будущее -- cashflow) — это все табличные в основном задачи
2. Больше всего DS работают либо в корпорациях либо с корпоративными данными
А у корпоративных данных есть одна важная особенность: они проходят по достаточно сложному пути: CDC -> ETL/ELT -> DWH / Data Lake -> Common DM / User DM
И по всему пути накапливается задержка (gap), который DS/MLE обязан учитывать.
А если вспомнить еще и про data drift / concept drift / label shift — то очевидность последнего ответа не вызывает сомнений (хотя это частично можно решить adversarial validation и тестами)
При этом на практике я использовал и варианты со стратификацией, и с группами (в недвижке), и двойную (nested) кросс-валидацию, и все варианты OOT / OOS CV
Forwarded from Pavel Zloi
Анатомия агентов
Давно обдумывал данную публикацию, хотелось собрать опыт построения агентов в одно небольшое сообщение. И так, по порядку...
LLM агент - это не просто LLM с хитрым промптом, как многим кажется, а система, которая умеет ставить подзадачи, выбирать действия и оценивать результат.
Такая система опирается на четыре обязательных компонента:
1) Нейросеть - мозги агента, как правило это LLM, понимает контекст задачи, строит план, формирует запросы к тулам.
2) Инструкция (промт) - набор правил, выглядит как подробный системный промпт, описывающий поведение агента, как агенту планировать работу, какие критерии использовать для оценки результата.
3) Память - может быть как краткосрочная (контекст диалога), так и долговременная (база знаний, профиль пользователя, файлы markdown). Важно понимать, что память, в отличии от тулов, работает всегда и информация из памяти может быть запрошена или сохранена на любом этапе работы агента.
4) Тулы (инструменты) - набор вызываемых при необходимости инструментов для взаимодествия с внешним миром, например поисковый движок, база данных, внешние API, браузер, файловая система, датчики, роборуки и так далее. В отличии от памяти модель видит список инструментов и планирует свои действия с учётом оных.
Когда это не агент?
У меня есть простые критерии оценки, если одного или нескольких компонентов представленных в списке выше нет, то это уже не агент, а интерфейс к модели.
Например:
- LLM + промпт (+ память)? -> чат-бот.
- LLM + память -> RAG-подобная система.
- LLM + тулы (+ промт)? (без планирования и оценки) -> классификатор/роутер.
В принципе в этот список можно накидать ещё несколько примеров, но думаю суть ясна, агент это прежде всего система работающих в унисон компонентов, настроенных таким образом, чтобы наиболее эффективно решать заранее определённые задачи.
Как из RAG агента сделать?
Предлагаю разобрать простенький кейс, предположим у нас есть классическая RAG-система, состоящая из модельки (llm), ретривера из базы знаний (тул), инструкции которая описывает поведение модельки (промт) и история диалога с пользователем (краткосрочная память).
Этого вполне хватает для ответов по корпоративной документации или скажем для беглого поиска по базе знаний.
Чтобы стать агентом нужно ещё добавить в системный промт планирование шагов и оценку результата выполнения каждого из шагов, плюс в добавок к кратковременной памяти чата можно добавить память долгосрочную, например для случаев когда пользователь просит агента запомнить что-то, скажем ответ на вопрос или формат ответа.
Итого
Имеем компоненты:
- Нейросеть - понимает, планирует, оценивает
- Инструкция - задаёт правила и критерии оценки
- Память - хранит контекст и опыт
- Тулы - позволяют взаимодействовать с внешним миром
Все четыре вместе - агент.
Минус любой - интерфейс к модели или некая иная система.
Давно обдумывал данную публикацию, хотелось собрать опыт построения агентов в одно небольшое сообщение. И так, по порядку...
LLM агент - это не просто LLM с хитрым промптом, как многим кажется, а система, которая умеет ставить подзадачи, выбирать действия и оценивать результат.
Такая система опирается на четыре обязательных компонента:
1) Нейросеть - мозги агента, как правило это LLM, понимает контекст задачи, строит план, формирует запросы к тулам.
2) Инструкция (промт) - набор правил, выглядит как подробный системный промпт, описывающий поведение агента, как агенту планировать работу, какие критерии использовать для оценки результата.
3) Память - может быть как краткосрочная (контекст диалога), так и долговременная (база знаний, профиль пользователя, файлы markdown). Важно понимать, что память, в отличии от тулов, работает всегда и информация из памяти может быть запрошена или сохранена на любом этапе работы агента.
4) Тулы (инструменты) - набор вызываемых при необходимости инструментов для взаимодествия с внешним миром, например поисковый движок, база данных, внешние API, браузер, файловая система, датчики, роборуки и так далее. В отличии от памяти модель видит список инструментов и планирует свои действия с учётом оных.
Когда это не агент?
У меня есть простые критерии оценки, если одного или нескольких компонентов представленных в списке выше нет, то это уже не агент, а интерфейс к модели.
Например:
- LLM + промпт (+ память)? -> чат-бот.
- LLM + память -> RAG-подобная система.
- LLM + тулы (+ промт)? (без планирования и оценки) -> классификатор/роутер.
В принципе в этот список можно накидать ещё несколько примеров, но думаю суть ясна, агент это прежде всего система работающих в унисон компонентов, настроенных таким образом, чтобы наиболее эффективно решать заранее определённые задачи.
Как из RAG агента сделать?
Предлагаю разобрать простенький кейс, предположим у нас есть классическая RAG-система, состоящая из модельки (llm), ретривера из базы знаний (тул), инструкции которая описывает поведение модельки (промт) и история диалога с пользователем (краткосрочная память).
Этого вполне хватает для ответов по корпоративной документации или скажем для беглого поиска по базе знаний.
Чтобы стать агентом нужно ещё добавить в системный промт планирование шагов и оценку результата выполнения каждого из шагов, плюс в добавок к кратковременной памяти чата можно добавить память долгосрочную, например для случаев когда пользователь просит агента запомнить что-то, скажем ответ на вопрос или формат ответа.
Итого
Имеем компоненты:
- Нейросеть - понимает, планирует, оценивает
- Инструкция - задаёт правила и критерии оценки
- Память - хранит контекст и опыт
- Тулы - позволяют взаимодействовать с внешним миром
Все четыре вместе - агент.
Минус любой - интерфейс к модели или некая иная система.
Forwarded from Pavel Zloi
Долгосрочная память агентов
Под моей прошлой публикацией разгорелась бодрая дискуссия. В ходе которой я наконец-то четко сформулировал, что именно считаю "долгосрочной памятью" в контексте LLM-агентов и как, на мой взгляд, она должна работать.
Что я вообще называю памятью
Когда мы говорим "память" языковой модели, на практике речь идет про то, что реально попадает в контекст во время инференса:
- системный промт
- история сообщений
- любые дополнительные вставки (few-shots, заметки, справки, ссылки, извлеченные факты)
- вызов тулов и их ответы
То есть память - это не мистический модуль внутри модели, а то, чем мы обогащаем контекст диалога перед генерацией.
Два вида памяти моделей
- Краткосрочная - всё, что живет в текущей сессии и прямо подается в "messages" и "tools", это могут быть пары с ролями user/assistant и у некоторых моделей роль tool. По завершении сессии это естественным образом забывается (если не предпринять шагов по сохранению).
- Долгосрочная - всё, что сохраняется между сессиями и может быть автоматически извлечено и вставлено в будущие запросы. Это может быть база знаний, коллекция "вечных" заметок, библиотека кейсов или примеров. Ключевое: модель не обязана "знать", что где-то есть БД, она просто получает уже обогащенный промт.
Вызов БД как тула - это ещё не память
Тулы - это то, чем агент пользуется при необходимости, память же "работает всегда". Прежде чем модель что-то сгенерирует, контекст уже дополнен тем, что нужно вспомнить. Если мы заставляем модель осознанно "вызывать память как тул", это ближе к явному инструменту, а не к фоновому механизму.
Смысл долгосрочной памяти - функционировать автоматически, под нужный запрос подмешать нужные куски опыта без лишних размышлений модели о том, где они лежат.
[1/3]
Под моей прошлой публикацией разгорелась бодрая дискуссия. В ходе которой я наконец-то четко сформулировал, что именно считаю "долгосрочной памятью" в контексте LLM-агентов и как, на мой взгляд, она должна работать.
Что я вообще называю памятью
Когда мы говорим "память" языковой модели, на практике речь идет про то, что реально попадает в контекст во время инференса:
- системный промт
- история сообщений
- любые дополнительные вставки (few-shots, заметки, справки, ссылки, извлеченные факты)
- вызов тулов и их ответы
То есть память - это не мистический модуль внутри модели, а то, чем мы обогащаем контекст диалога перед генерацией.
Два вида памяти моделей
- Краткосрочная - всё, что живет в текущей сессии и прямо подается в "messages" и "tools", это могут быть пары с ролями user/assistant и у некоторых моделей роль tool. По завершении сессии это естественным образом забывается (если не предпринять шагов по сохранению).
- Долгосрочная - всё, что сохраняется между сессиями и может быть автоматически извлечено и вставлено в будущие запросы. Это может быть база знаний, коллекция "вечных" заметок, библиотека кейсов или примеров. Ключевое: модель не обязана "знать", что где-то есть БД, она просто получает уже обогащенный промт.
Вызов БД как тула - это ещё не память
Тулы - это то, чем агент пользуется при необходимости, память же "работает всегда". Прежде чем модель что-то сгенерирует, контекст уже дополнен тем, что нужно вспомнить. Если мы заставляем модель осознанно "вызывать память как тул", это ближе к явному инструменту, а не к фоновому механизму.
Смысл долгосрочной памяти - функционировать автоматически, под нужный запрос подмешать нужные куски опыта без лишних размышлений модели о том, где они лежат.
[1/3]
Forwarded from Pavel Zloi
Pavel Zloi
Долгосрочная память агентов Под моей прошлой публикацией разгорелась бодрая дискуссия. В ходе которой я наконец-то четко сформулировал, что именно считаю "долгосрочной памятью" в контексте LLM-агентов и как, на мой взгляд, она должна работать. Что я вообще…
Memory Copilot - концепт инструмента памяти агента
В своей практике стараюсь избегать прямых отсылок на то как (мне и многим моим визави кажется) работает разум и мышление, поскольку стоит только привести такую аналогию, как дискуссия сразу же уходит куда-то в эзотерические дали.
Поэтому вместо "внутреннего голоса" предлагаю более инженерный образ - "второй пилот" - сабагента, который целиком отвечает за память (саб- потому как у него нет своей памяти, он лишь оперирует тулами работы с базой).
И так, Memory Copilot - это самостоятельный сабагент, который:
1) обогащает промт перед генерацией за счет релевантного опыта, примерно как это описано в "Automatic Engineering of Long Prompts" (arXiv:2311.10117)
2) решает, что из результатов текущего шага стоит сохранить
3) работает автоматически, без того чтобы основная модель "тригерила память как тул"
То есть грубо говоря, я вижу данный модуль где-то между языковой моделью и интерфейсом общения с пользователем, эдаким генератором системного промта.
Предполагаю, что данный сабагент имеет только два тула:
- вспомнить (search) - происходит перед генерацией ответа, на этапе сборки промта. Агент сопоставляет текущий запрос пользователя с тем, что есть в долговременном хранилище, извлекает релевантные куски (например в виде few-shots или кратких "фактов") и подает это в контекст вместе с системными инструкциями и историей диалога.
- запомнить (save) - происходит после генерации, опциональный шаг. Агент оценивает полезность сгенерированного ответа и решает, стоит ли сохранить короткую выжимку из результата. Это снижает шум, экономит место и улучшает последующие извлечения.
Как это выглядит на одном запросе:
1) после запроса юзера вызываем search, в ответе получаем релевантные куски, добавляем в промт, генерируем ответ.
2) после ответа вызываем save, но не вслепую, сначала мини-оценка "LLM-as-a-judge" (есть ли уже такое воспоминание, пригодится ли это в будущем, оригинально ли, не дублирует ли уже сохраненное). Только если прошло отсев - сохраняем. Подробнее про оценку ответов в "From Generation to Judgment: Opportunities and Challenges of LLM-as-a-judge" (arXiv:2411.16594)
Такой цикл делает агента "самонастраивающимся", то есть чем дольше он работает, тем точнее подмешивает опыт и тем меньше ошибается ошибки, агент таким образом "учится", хотя наверно это не самая лучшая аналогия. Идея близка к линиям работы "Reflexion: Language Agents with Verbal Reinforcement Learning" (arXiv:2303.11366) про рефлексию и самокритику генераций, где модель перед сохранением оценивает свою же работу.
Не только лишь чат
Тот же принцип годится и "за пределами чатика".
Например, можно запоминать удачные решения на уровне действий, типа какой тул и с какими параметрами сработал лучше для определенного класса запросов, типа "поисковая кверя А дала релевантные документы".
По моим наблюдением добавление few-shots позитивно влияет на планирование вызова тулов, так как моделька быстрее и точнее выбирает нужный, про фьюшотс "Language Models are Few-Shot Learners" (arXiv:2005.14165).
В отличие запросов считаю, что ответы тула хранить не стоит, так как они устаревают и занимают место. Как по мне практичнее запоминать короткие правила и шаблоны действий, а не сам ответ.
Простенький пайплайн
1) Приходит запрос пользователя.
2) Сопоставление с долговременной памятью -> извлеченные фрагменты превращаем в few-shots/факты -> собираем промт.
3) Генерация ответа.
4) Быстрая проверка полезности результата (LLM-as-a-judge).
5) Если полезно, то дистиллируем и сохраняем.
На следующих шагах этот "опыт" автоматически всплывает при сборке промта.
[2/3]
В своей практике стараюсь избегать прямых отсылок на то как (мне и многим моим визави кажется) работает разум и мышление, поскольку стоит только привести такую аналогию, как дискуссия сразу же уходит куда-то в эзотерические дали.
Поэтому вместо "внутреннего голоса" предлагаю более инженерный образ - "второй пилот" - сабагента, который целиком отвечает за память (саб- потому как у него нет своей памяти, он лишь оперирует тулами работы с базой).
И так, Memory Copilot - это самостоятельный сабагент, который:
1) обогащает промт перед генерацией за счет релевантного опыта, примерно как это описано в "Automatic Engineering of Long Prompts" (arXiv:2311.10117)
2) решает, что из результатов текущего шага стоит сохранить
3) работает автоматически, без того чтобы основная модель "тригерила память как тул"
То есть грубо говоря, я вижу данный модуль где-то между языковой моделью и интерфейсом общения с пользователем, эдаким генератором системного промта.
Предполагаю, что данный сабагент имеет только два тула:
- вспомнить (search) - происходит перед генерацией ответа, на этапе сборки промта. Агент сопоставляет текущий запрос пользователя с тем, что есть в долговременном хранилище, извлекает релевантные куски (например в виде few-shots или кратких "фактов") и подает это в контекст вместе с системными инструкциями и историей диалога.
- запомнить (save) - происходит после генерации, опциональный шаг. Агент оценивает полезность сгенерированного ответа и решает, стоит ли сохранить короткую выжимку из результата. Это снижает шум, экономит место и улучшает последующие извлечения.
Как это выглядит на одном запросе:
1) после запроса юзера вызываем search, в ответе получаем релевантные куски, добавляем в промт, генерируем ответ.
2) после ответа вызываем save, но не вслепую, сначала мини-оценка "LLM-as-a-judge" (есть ли уже такое воспоминание, пригодится ли это в будущем, оригинально ли, не дублирует ли уже сохраненное). Только если прошло отсев - сохраняем. Подробнее про оценку ответов в "From Generation to Judgment: Opportunities and Challenges of LLM-as-a-judge" (arXiv:2411.16594)
Такой цикл делает агента "самонастраивающимся", то есть чем дольше он работает, тем точнее подмешивает опыт и тем меньше ошибается ошибки, агент таким образом "учится", хотя наверно это не самая лучшая аналогия. Идея близка к линиям работы "Reflexion: Language Agents with Verbal Reinforcement Learning" (arXiv:2303.11366) про рефлексию и самокритику генераций, где модель перед сохранением оценивает свою же работу.
Не только лишь чат
Тот же принцип годится и "за пределами чатика".
Например, можно запоминать удачные решения на уровне действий, типа какой тул и с какими параметрами сработал лучше для определенного класса запросов, типа "поисковая кверя А дала релевантные документы".
По моим наблюдением добавление few-shots позитивно влияет на планирование вызова тулов, так как моделька быстрее и точнее выбирает нужный, про фьюшотс "Language Models are Few-Shot Learners" (arXiv:2005.14165).
В отличие запросов считаю, что ответы тула хранить не стоит, так как они устаревают и занимают место. Как по мне практичнее запоминать короткие правила и шаблоны действий, а не сам ответ.
Простенький пайплайн
1) Приходит запрос пользователя.
2) Сопоставление с долговременной памятью -> извлеченные фрагменты превращаем в few-shots/факты -> собираем промт.
3) Генерация ответа.
4) Быстрая проверка полезности результата (LLM-as-a-judge).
5) Если полезно, то дистиллируем и сохраняем.
На следующих шагах этот "опыт" автоматически всплывает при сборке промта.
[2/3]
Forwarded from Pavel Zloi
Pavel Zloi
Memory Copilot - концепт инструмента памяти агента В своей практике стараюсь избегать прямых отсылок на то как (мне и многим моим визави кажется) работает разум и мышление, поскольку стоит только привести такую аналогию, как дискуссия сразу же уходит куда…
Ограничения и вопросики
Под конец хочу рассказать о потенциальных вопросах применения долгосрочной памяти.
- засорение памяти - нужно дистиллировать и выкидывать дубликаты, а перед сохранением новых данных проверять нет ли чего похожего, чтобы вместо условного insert делать условный update.
- TTL (устаревание) - полагаю данные со времен должны устаревать, например если к информации давно не обращаются, то помечать её "к удалению" или как-то так.
- персональные данные - сохранение "вечных" заметок это уже обработка персональных/корпоративных данных, тут надо будет покумекать над очисткой данных.
- время и стоимость - каждое вспоминанием и запоминание это токены и задержка, поэтому мне кажется важно будет заранее продумать такие вещи как: когда вспоминать, когда запоминать, когда судить, когда молча пропустить и так далее.
Итог
Для меня долговременная память агента - это не "еще один тул", а автоматический процесс обогащения промта опытом, который живет между сессиями. Вспоминаем - перед генерацией, запоминаем - только после оценки ответа. Такой режим постепенно превращает агента из простого интерфейса к LLM в систему, которая учится на собственной практике и гипотетически способна научиться избегать ошибок.
[3/3]
Под конец хочу рассказать о потенциальных вопросах применения долгосрочной памяти.
- засорение памяти - нужно дистиллировать и выкидывать дубликаты, а перед сохранением новых данных проверять нет ли чего похожего, чтобы вместо условного insert делать условный update.
- TTL (устаревание) - полагаю данные со времен должны устаревать, например если к информации давно не обращаются, то помечать её "к удалению" или как-то так.
- персональные данные - сохранение "вечных" заметок это уже обработка персональных/корпоративных данных, тут надо будет покумекать над очисткой данных.
- время и стоимость - каждое вспоминанием и запоминание это токены и задержка, поэтому мне кажется важно будет заранее продумать такие вещи как: когда вспоминать, когда запоминать, когда судить, когда молча пропустить и так далее.
Итог
Для меня долговременная память агента - это не "еще один тул", а автоматический процесс обогащения промта опытом, который живет между сессиями. Вспоминаем - перед генерацией, запоминаем - только после оценки ответа. Такой режим постепенно превращает агента из простого интерфейса к LLM в систему, которая учится на собственной практике и гипотетически способна научиться избегать ошибок.
[3/3]
Forwarded from Dealer.AI
Cookbook от HF, как построить world level LLM.
А пока орги продлили голосовухуи всю эту суету 🥲 до 5.11, почитаем cookbook от Huggingface 🤗. Как построить LLM мирового уровня, небольшой гайдик:
- Если ты не в курсе с чего начать, а оно вообще тебе надо?
- А в каком порядке идет pretrain, rl, sft, annealing?
- Что такое kv caching?
- А curriculum learning он зочем?
- Какие стратегии скейлинга по датке и gpu.
И многое другое, ты найдешь в данном небольшом руководстве на 200+ страниц🤣 , с формулами, картинками и графиками. Версия на сайте. Будет, что почитать на выходных. 🧑🎓
А пока орги продлили голосовуху
- Если ты не в курсе с чего начать, а оно вообще тебе надо?
- А в каком порядке идет pretrain, rl, sft, annealing?
- Что такое kv caching?
- А curriculum learning он зочем?
- Какие стратегии скейлинга по датке и gpu.
И многое другое, ты найдешь в данном небольшом руководстве на 200+ страниц
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Dealer.AI
Продолжаем посты, cookbooks для чтения на выходных.
У Microsoft вышел классный курс по малым моделям на конечных устройствах. Подписчики рекомендуют.
В целом, знаю много любителей моделек on-device, в свое время было очень популярно делать tflite формат + устройство, туда же потом влетел onnx и прочее.
В общем, приятного чтения.😁
У Microsoft вышел классный курс по малым моделям на конечных устройствах. Подписчики рекомендуют.
В целом, знаю много любителей моделек on-device, в свое время было очень популярно делать tflite формат + устройство, туда же потом влетел onnx и прочее.
В общем, приятного чтения.
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - microsoft/edgeai-for-beginners: This course is designed to guide beginners through the exciting world of Edge AI, covering…
This course is designed to guide beginners through the exciting world of Edge AI, covering fundamental concepts, popular models, inference techniques, device-specific applications, model optimizati...
Forwarded from Dealer.AI
Что, если вы попробовали BM25 и SPLADE – FM index+Infini-gram.
Эта статья стала best paper EMNLP2025.
Статья "Infini-gram mini: Exact n-gram Search at the Internet Scale with FM-Index" представляет собой исследование по созданию системы для точного поиска n-грамм в сверхбольших текстовых корпусах. Что такое n-граммный поиск? Это подход аля tfidf основанный на поиске совпадения в строках путем сравнение общих n-грамм токенов или символов. Статья может быть потенциально интересной для тех, кто строит RAG системы с учетом bm25 индексов и иных (аля SPLADE).
🎯 Постановка задачи
Языковые модели обучаются на огромных объемах текстовых данных из интернета, и важно понимать эти данные. Точный поиск по таким корпусам позволяет подсчитывать вхождения строк и находить исходные документы, но существующие системы не справляются с большими масштабами данных из-за высоких требований к хранилищу. Авторы ставят задачу создать эффективную и масштабируемую систему, которая сделает петабайтные текстовые корпуса доступными для поиска.
💡 Идея алгоритма
Основная идея алгоритма — использование FM-Index (Full Text Minute Index). Этот метод, созданный Феррагиной и Манзини, одновременно индексирует и сжимает текст. Алгоритм дает пользователю:
1. Эффективность: Infini-gram mini значительно улучшает существующие реализации FM-Index. Система создает индекс, размер которого составляет всего 44% от исходного корпуса.
2. Производительность:
- Скорость индексации повышается в 18 раз.
- Использование памяти в процессе индексации сокращается в 3.2 раза.
- Потребление памяти при выполнении запросов снижается до незначительного уровня.
Про Infini-gram, он работает принципиально иначе, чем традиционные языковые модели n-грамм. Вместо заранее вычисленных таблиц частот, он использует структуру данных суффиксный массив, что позволяет обрабатывать n-граммы практически неограниченной длины с низкой задержкой .
Ключевая инновация Infini-gram — это отказ от классических таблиц n-грамм в пользу суффиксного массива всего корпуса текстов.
В чем проблема традиционных n-грамм? Для больших n длин последовательности таблицы частот становятся астрономически большими. Например, для корпуса в 1.4 триллиона токенов 5-граммная таблица заняла бы около 28 ТБ, что делает модели с большим n невозможными.
Итого, зачем оно все нам? Недавно, мы видели, как можно использовать поиск встроенный в файловую систему для эффективной работы rag и памяти. Подход с Infiniti gram+fm index может быть полезен для агентных систем с памятью в качестве альтернативы поиска по большим массивам данных. Да, и все это помимо прямой задачи - фильтрации больших сетов.
Эта статья стала best paper EMNLP2025.
Статья "Infini-gram mini: Exact n-gram Search at the Internet Scale with FM-Index" представляет собой исследование по созданию системы для точного поиска n-грамм в сверхбольших текстовых корпусах. Что такое n-граммный поиск? Это подход аля tfidf основанный на поиске совпадения в строках путем сравнение общих n-грамм токенов или символов. Статья может быть потенциально интересной для тех, кто строит RAG системы с учетом bm25 индексов и иных (аля SPLADE).
🎯 Постановка задачи
Языковые модели обучаются на огромных объемах текстовых данных из интернета, и важно понимать эти данные. Точный поиск по таким корпусам позволяет подсчитывать вхождения строк и находить исходные документы, но существующие системы не справляются с большими масштабами данных из-за высоких требований к хранилищу. Авторы ставят задачу создать эффективную и масштабируемую систему, которая сделает петабайтные текстовые корпуса доступными для поиска.
💡 Идея алгоритма
Основная идея алгоритма — использование FM-Index (Full Text Minute Index). Этот метод, созданный Феррагиной и Манзини, одновременно индексирует и сжимает текст. Алгоритм дает пользователю:
1. Эффективность: Infini-gram mini значительно улучшает существующие реализации FM-Index. Система создает индекс, размер которого составляет всего 44% от исходного корпуса.
2. Производительность:
- Скорость индексации повышается в 18 раз.
- Использование памяти в процессе индексации сокращается в 3.2 раза.
- Потребление памяти при выполнении запросов снижается до незначительного уровня.
Про Infini-gram, он работает принципиально иначе, чем традиционные языковые модели n-грамм. Вместо заранее вычисленных таблиц частот, он использует структуру данных суффиксный массив, что позволяет обрабатывать n-граммы практически неограниченной длины с низкой задержкой .
Ключевая инновация Infini-gram — это отказ от классических таблиц n-грамм в пользу суффиксного массива всего корпуса текстов.
В чем проблема традиционных n-грамм? Для больших n длин последовательности таблицы частот становятся астрономически большими. Например, для корпуса в 1.4 триллиона токенов 5-граммная таблица заняла бы около 28 ТБ, что делает модели с большим n невозможными.
Итого, зачем оно все нам? Недавно, мы видели, как можно использовать поиск встроенный в файловую систему для эффективной работы rag и памяти. Подход с Infiniti gram+fm index может быть полезен для агентных систем с памятью в качестве альтернативы поиска по большим массивам данных. Да, и все это помимо прямой задачи - фильтрации больших сетов.
arXiv.org
Infini-gram mini: Exact n-gram Search at the Internet Scale with FM-Index
Language models are trained mainly on massive text data from the Internet, and it becomes increasingly important to understand this data source. Exact-match search engines enable searching in...
Forwarded from Записки Ппилифа (Ppilif)
Этот фильм уничтожит ваше FOMO и синдром самозванца. Хотябы ненадолго. Может быть.
В 2021 году Питер Джексон, в своих лучших традициях, выпустил 7-часовую трёхсерийную документалку про Битлз. Это очень скучный фильм. Челы большую часть его времени просто сидят на студии и пытаются записать альбом.
Узнал о нём от Ануара и поставил фоном во время работы. Возникает ощущение, что мы творим вместе. Битлы пытаются сделать что-то гениальное, а я прост пытаюсь им не мешать и занимаюсь своими делами. Я что-то вроде Рика Рубина, спящего на диване во время записи.
Битлы джемят, играют чужие песни, пытаются искать вдохновение и создавать что-то новое. Это очень длинный мучительный совместный процесс. Они кидают друг в друга идеи, пробуют что-то и нащупывают музыку, которую каждый из нас знает, но тогда её ещё нет.
Заглянуть в то как другие люди творят — офигенно. Ты начинаешь видеть, насколько процесс мучительный и сколько труда великие затрачивают для того, чтобы из ничего получить что-то. Именно благодаря этому они и великие.
Поэтому прекратили все быстро ныть, что выгорели и пиздуйте работать. Я тоже пойду.
В 2021 году Питер Джексон, в своих лучших традициях, выпустил 7-часовую трёхсерийную документалку про Битлз. Это очень скучный фильм. Челы большую часть его времени просто сидят на студии и пытаются записать альбом.
Узнал о нём от Ануара и поставил фоном во время работы. Возникает ощущение, что мы творим вместе. Битлы пытаются сделать что-то гениальное, а я прост пытаюсь им не мешать и занимаюсь своими делами. Я что-то вроде Рика Рубина, спящего на диване во время записи.
Битлы джемят, играют чужие песни, пытаются искать вдохновение и создавать что-то новое. Это очень длинный мучительный совместный процесс. Они кидают друг в друга идеи, пробуют что-то и нащупывают музыку, которую каждый из нас знает, но тогда её ещё нет.
Заглянуть в то как другие люди творят — офигенно. Ты начинаешь видеть, насколько процесс мучительный и сколько труда великие затрачивают для того, чтобы из ничего получить что-то. Именно благодаря этому они и великие.
Поэтому прекратили все быстро ныть, что выгорели и пиздуйте работать. Я тоже пойду.
Forwarded from Vibecon / вайбкодим вместе (Vlad)
Собрали для вас кейсы вайбкодинга для вдохновления
Вчера попросили поделиться кейсами, в результате получилась классная вдохновляющая подборка от подписчиков канала и выпускников курса. Напомню: у всех людей из подборки ранее не было опыта разработки.
Подписчики канала:
1. Кирилл Макаров — собрал за 3 часа тг-бота на Replit для своего челленджа по креативам. Бот мониторит выполнение домашек, хвалит и напоминает про штрафы, а также удаляет из челленджа после пропуска дедлайна.
2. Даниил Прокофьев — за 2 месяца на Lovable переписал всю операционку своей компании барных викторин (8 лет процессов, десятки городов, международные франшизы). Вместо разрозненных Google Sheets, Airtable и кастомного кода собрал единую ОС, которая покрывает ~70% логики и уже проходит тестирование командой.
3. Николай Березовский — за месяц собрал MVP собственной IDE для не-разработчиков: смесь Cursor и Arc прямо в браузере. Локальные файлы, вкладки, Markdown-редактор уровня Notion, сессионный контекст, встроенный Chrome и агент на Claude Code, который умеет всё — искать, читать, редактировать файлы, работать с вебом, обновлять метрики, коммитить, запускать команды.
Выпускники первого потока курса:
4. Marika Taavet — на Replit собрала себе собственный финтул под малый бизнес: загрузка банковских выписок, автокатегоризация на старых данных, отчёты, полный контроль над логикой. Начала с Cursor, но интерфейс показался перегруженным — ушла в Replit и там зажглась
5. Игорь Ленский — собрал семейное веб-приложение под реальные бытовые процессы. Дела на день с участниками и дедлайнами, список покупок с быстрыми подкатегориями, отдельный экран благодарностей с простым вводом. Минимум лишнего, максимум пользы — лёгкая внутренняя «семейная ОС»
6. Булат Ахметшин — создал бесплатный онлайн-тул для создания и обмена виш-листами. Пользователь быстро заполняет название и дату события, добавляет подарки с фото, ссылкой и комментарием, затем получает публичную ссылку, отправляет друзьям — они могут резервировать подарки без регистрации.
——
Напоминаем, что можно делиться кейсами и тогда будем публиковать еще подборки
Вчера попросили поделиться кейсами, в результате получилась классная вдохновляющая подборка от подписчиков канала и выпускников курса. Напомню: у всех людей из подборки ранее не было опыта разработки.
Подписчики канала:
1. Кирилл Макаров — собрал за 3 часа тг-бота на Replit для своего челленджа по креативам. Бот мониторит выполнение домашек, хвалит и напоминает про штрафы, а также удаляет из челленджа после пропуска дедлайна.
2. Даниил Прокофьев — за 2 месяца на Lovable переписал всю операционку своей компании барных викторин (8 лет процессов, десятки городов, международные франшизы). Вместо разрозненных Google Sheets, Airtable и кастомного кода собрал единую ОС, которая покрывает ~70% логики и уже проходит тестирование командой.
3. Николай Березовский — за месяц собрал MVP собственной IDE для не-разработчиков: смесь Cursor и Arc прямо в браузере. Локальные файлы, вкладки, Markdown-редактор уровня Notion, сессионный контекст, встроенный Chrome и агент на Claude Code, который умеет всё — искать, читать, редактировать файлы, работать с вебом, обновлять метрики, коммитить, запускать команды.
Выпускники первого потока курса:
4. Marika Taavet — на Replit собрала себе собственный финтул под малый бизнес: загрузка банковских выписок, автокатегоризация на старых данных, отчёты, полный контроль над логикой. Начала с Cursor, но интерфейс показался перегруженным — ушла в Replit и там зажглась
5. Игорь Ленский — собрал семейное веб-приложение под реальные бытовые процессы. Дела на день с участниками и дедлайнами, список покупок с быстрыми подкатегориями, отдельный экран благодарностей с простым вводом. Минимум лишнего, максимум пользы — лёгкая внутренняя «семейная ОС»
6. Булат Ахметшин — создал бесплатный онлайн-тул для создания и обмена виш-листами. Пользователь быстро заполняет название и дату события, добавляет подарки с фото, ссылкой и комментарием, затем получает публичную ссылку, отправляет друзьям — они могут резервировать подарки без регистрации.
——
Напоминаем, что можно делиться кейсами и тогда будем публиковать еще подборки
Forwarded from DevFM
Шаблонный сервис
Я всячески люблю, когда разработка идёт предсказуемо – и многое для этого делаю.
Давно хотел написать пост о важности шаблонного сервиса, но не было хорошего примера под рукой. И тут мой коллега выложил наш шаблонный сервис на FastAPI, который мы долгое время использовали и развивали.
Так зачем же нужен шаблонный сервис?
Легко ориентироваться в других сервисах. Иногда нужно залезть в сервис коллег, или поддерживаешь несколько сервисов. Никаких проблем – структура везде одинаковая, всё знакомо, не нужно тратить время на раскопки.
Быстрый старт. Стартуете новый сервис? Полчаса – и он готов. Никаких лишних приседаний.
Единые практики. Шаблон определяет, не только структуру, но и то, как мы, например, делаем ретраи, какие у нас зависимости. как устроен circuit breaker, обработка ошибок и т.д.
Лучшие практики – в одном месте. Если появляется что-то классное, мы добавляем это в шаблон и новые сервисы сразу это наследуют.
Обсервабилити, логирование, работа с секретами – готово из коробки. И меньше шансов, что кто-то забьёт на логирование до лучших времён»:)
Онбординг на кошечках. Новый человек сначала изучает шаблонный сервис, понимает подходы, а потом уже ныряет в боевые системы.
Просто экспериментировать. Создал веточку от шаблона – и прикручиваешь свою новую махарайку, не тратя время на базовую структуру.
Унификация линтинга. Конфиги линтеров лежат в шаблоне. Ничего настраивать не нужно, а код-ревью идёт быстрее – обо всём уже однажды договорились и зафиксировали.
Базовый CI/CD. Для шаблонного сервиса существует шаблонный ci/cd – и это очень удобно.
Мы активно использовали шаблонный сервис в микросервисной архитектуре, но и для монолитных решений он тоже отлично зашёл – стартовали с ним несколько проектов.
Понимаю, что это нужно не всем. Но если вы занимаетесь продуктовой разработкой и играете вдолгую — на мой взгляд, это мастхев.
В общем – заходите, смотрите, ставьте звездочки. И если с чем-то не согласны – пишите в комменты, автор обязательно ответит 🙂
#devfm #systemdesign
Я всячески люблю, когда разработка идёт предсказуемо – и многое для этого делаю.
Давно хотел написать пост о важности шаблонного сервиса, но не было хорошего примера под рукой. И тут мой коллега выложил наш шаблонный сервис на FastAPI, который мы долгое время использовали и развивали.
Так зачем же нужен шаблонный сервис?
Легко ориентироваться в других сервисах. Иногда нужно залезть в сервис коллег, или поддерживаешь несколько сервисов. Никаких проблем – структура везде одинаковая, всё знакомо, не нужно тратить время на раскопки.
Быстрый старт. Стартуете новый сервис? Полчаса – и он готов. Никаких лишних приседаний.
Единые практики. Шаблон определяет, не только структуру, но и то, как мы, например, делаем ретраи, какие у нас зависимости. как устроен circuit breaker, обработка ошибок и т.д.
Лучшие практики – в одном месте. Если появляется что-то классное, мы добавляем это в шаблон и новые сервисы сразу это наследуют.
Обсервабилити, логирование, работа с секретами – готово из коробки. И меньше шансов, что кто-то забьёт на логирование до лучших времён»:)
Онбординг на кошечках. Новый человек сначала изучает шаблонный сервис, понимает подходы, а потом уже ныряет в боевые системы.
Просто экспериментировать. Создал веточку от шаблона – и прикручиваешь свою новую махарайку, не тратя время на базовую структуру.
Унификация линтинга. Конфиги линтеров лежат в шаблоне. Ничего настраивать не нужно, а код-ревью идёт быстрее – обо всём уже однажды договорились и зафиксировали.
Базовый CI/CD. Для шаблонного сервиса существует шаблонный ci/cd – и это очень удобно.
Мы активно использовали шаблонный сервис в микросервисной архитектуре, но и для монолитных решений он тоже отлично зашёл – стартовали с ним несколько проектов.
Понимаю, что это нужно не всем. Но если вы занимаетесь продуктовой разработкой и играете вдолгую — на мой взгляд, это мастхев.
В общем – заходите, смотрите, ставьте звездочки. И если с чем-то не согласны – пишите в комменты, автор обязательно ответит 🙂
#devfm #systemdesign
GitHub
GitHub - ydjin0602/fastapi-template
Contribute to ydjin0602/fastapi-template development by creating an account on GitHub.