Продолжаем data mining путешествие в погоне за удачей. Сегодня разберем как устроена оценка интеллекта. Тут мы вступаем на очень скользкую почву. Объективности у большинства людей тут гораздо меньше и на это есть причины. Давайте попробуем разобрать это подробнее.
С опытом у RAG-инженера накапливается солидный багаж эвристик и инструментов, которые в определенных задачах превосходят по качеству или скорости стандартные. Фраза «а для этого у меня есть собственный ретривер» звучит с некоторым снобизмом, но добавляет к профессионализму несколько пойнтов.
Хотите в свою коллекцию ретривер, который умеет работать с терминами, плохо различимыми в векторном пространстве эмбеддинга, в частности с именами и названиями? Тогда давайте перейдём от снобизма к практике. Начнём с обработки текста и сегментируем его на фрагменты - «чанки». Далее сделаем TFIDF модель, добавим поиск и обернём всё это в ретривер LangChain. Наконец сравним наш ретривер с двумя-тремя стандартными решениями. А Ollama поможет с вопросами для бенчмарка.
Мы довели TAPe‑детекцию на COCO до уровня лучших SOTA‑моделей по точности, но с двумя порядками выигрыша по параметрам и радикально меньшими требованиями к данным и ресурсам. При этом модель держит 7–8 мс на изображение при mAP50 на уровне RF‑DETR‑2XL и работает почти одинаково быстро на GPU и CPU. В этом финальном посте нашего "дневника" мы подведем итоги эксперимента, покажем ключевые бенчмарки и объясним, почему TAPe‑подход позволяет реально экономить данные, железо и время разработки.
В итоговой детекционной модели у нас меньше 100 000 параметров — примерно в 10 раз меньше, чем у ближайших «облегчённых» моделей уровня YOLO, и примерно в 1000 раз меньше, чем у сильных DETR‑подходов вроде RF‑DETR с 127 млн параметров.
Продолжаем data mining путешествие в погоне за удачей. Сегодня разберем как устроены жизненные факторы. Эти категория достаточно скучна, но статистически хорошо подтверждена. И интуитивно понятна большинству людей. Но влияние ее очень сильное. Поэтому рассмотрим ее подробнее.
В этом посте продолжаем дневник TAPe‑детекции на COCO: добавляем сегментацию по контрастным патчам на границе объектов, дорабатываем классификацию, избавляемся от learning rate и смотрим, как ведёт себя YOLO на нашем маленьком датасете.
А уже завтра покажем базовые и COCO‑бенчмарки, сравнения с YOLO и RF‑DETR по точности (mAP50/mAP50‑95), скорости, числу параметров и требованиям к данным, а заодно чуть подробнее поговорим про аннотацию и то, почему нам хватает десятков изображений на класс там, где другим нужны сотни тысяч.
Продолжаем data mining путешествие в погоне за удачей. Сегодня разберем как устроены богатство, социальные связи и образование. Эти категории достаточно сложны, но статистически хорошо подтверждены. Откалибровать их было довольно просто.
Привет! Я Артём Юрченко — DS-инженер в команде Недвижимости Авито. Наши кол-центры совершают до 30 000 звонков в день, и вручную можно проверить лишь небольшую часть из них. Расскажу, как мы начали строить систему речевой аналитики и разработали первую модель, которая автоматически находит в звонках возражения клиентов и анализирует, как операторы их отрабатывают.
Статья будет полезна DS-инженерам, аналитикам и продакт-менеджерам, которые работают над продуктами построения речевой аналитики.
Анализ проблемы и формирование гипотезы — удача является важным фактором в жизни человека. Но главный вопрос — насколько? Какие категории параметров можно выделить для декомпозиции с целью анализа? Начинаем погружение в “кроличью нору”.
Продолжаем описание создания симуляции с учетом фактора удачи. Составляем список факторов, влияющих на жизненный успех. Изначально идея была простой. Но что получилось в итоге?
Я задался вопросом: насколько блокировка Telegram оказалась эффективной со стороны цензоров? Косвенно можно оценить и уровень использования VPN среди населения. Логика простая: Telegram — один из крупнейших каналов распространения информации, и если доступ к нему ограничивается, поведение аудитории должно это отразить.
Отдельный плюс исследования — его воспроизводимость: при желании любой может повторить подход и проверить результаты.
Попытки заменить чем‑то векторный поиск в RAG продолжаются. Про GraphRAG я уже высказывался, новый претендент на замену — Pageindex.
Идея простая. Сегментируем документ на страницы, при помощи LLM и хитрого кода строим для него таблицу содержания, TOC с деревом узлов и саммари для каждого узла. Далее отправляем эту структуру в промпт поискового запроса и просим LLM найти релевантные узлы. За каждым найденным узлом закреплены страницы документа. Эти страницы достаём и используем в качестве контекста в финальном запросе.
Нет чанков, не нужны эмбеддинги и векторные хранилища. Выглядит заманчиво. Попытаюсь добавить к этой идее немного критики и заодно расскажу как эту штуку запустить локально.
Когда-то я был молодым и активным. И под воздействием средств массовой информации, окружения и прочитанных довольно глупых книг я искренне считал, что человек с активной жизненной позицией, прилагающий значительные усилия, может в жизни добиться всего. В целом, я и сейчас наблюдаю такую же позицию у активной части молодёжи. Более того — в технологической среде эта вера ещё сильнее. Hustle culture, гаражные мифы Кремниевой долины, «если ты не добился — значит, мало хотел».
Потом были подряд 5 бизнесов-стартапов. 4 неудачных и один приносил не более чем хорошую зарплату в офисе. И при этом я регулярно пахал по 16 часов без выходных и личной жизни. И когда всё заканчивалось плохо — я говорил себе, что я, видимо, мало приложил усилий.
Знакомо?
ДИСКЛЕЙМЕР:
Автор не призывает к игре с сторонним ПО. Вся информация, приведенная в статье - приведена лишь в образовательных и ознакомительных целях. Информация была взята из открытых источников и ни к чему не призывает.
СОДЕРЖАНИЕ:
Здравствуйте. Несколько лет глубоко погружён в тему корпоративных RAG-систем. В последнее время, как от коллег, так и от заказчика часто слышу, что векторный поиск это слабое место и вчерашний день, и что нас спасут только графовые системы. Нашел несколько постов и видео на эту тему. Захотелось попробовать. В статье делюсь своими впечатлениями, рефлексирую и рассказываю как воспроизвести эксперименты.
Почему Ollama? Выделение вычислительных ресурсов на RAG в проекте - отдельная больная тема. Мне нужно было понять нижнюю планку. Если коротко, кое-как работает даже на 4b моделях.
Причём здесь киберпанк? Очень нравится этот жанр, а ещё я люблю использовать для проверки RAG/LLM штук знакомые тексты. Для экспериментов с Microsoft GraphRAG я выбрал рассказ "Johnny Mnemonic" Уильяма Гибсона, для начала на английском.
Красивый средний MAPE не спасает, если однажды модель крупно промахнулась именно в тот момент, когда по прогнозу принимают решения. После этого бизнес перестаёт верить цифрам и начинает либо “на всякий случай” жечь миллиарды на промо, либо, наоборот, игнорирует сигнал и до последнего верит, что план выполнится сам.
В этой статье – сразу два пути: от простой Excel-сезонки, которая неожиданно обыграла Prophet и классику на длинном горизонте, к ансамблю на базе TSMixer и от наивной веры в средний MAPE – к нормальной системе оценки качества с rolling backtest, bias, EOM и деградацией по горизонту.
Это не лонгрид про ML ради ML, а история о том, как сделать прогноз рабочим инструментом бизнеса.
Если вы хоть раз общались с большими языковыми моделями, то знаете их главную слабость: они патологические лжецы. Они могут с абсолютной уверенностью рассказывать о вещах, которых никогда не существовало.
В мире IT это называют «галлюцинациями», а лечат их с помощью RAG (Retrieval-Augmented Generation). Если просто: это способ дать модели «шпаргалку» из ваших документов, чтобы она не гадала, а опиралась на факты.
Но как эта сложная механика выглядит изнутри? Давайте разберем устройство RAG на примере одной поучительной истории из Цифрового Королевства, где один рыжий Кот чуть не довел Бизнес до нервного срыва своим враньем.
Как и многие фанаты автоспорта, я внимательно слежу за жаркими дискуссиями вокруг жесточайшего клиппинга (исчерпания заряда батареи) в рамках нового технического регламента Формулы-1.
В этом контексте вспомнил про открытую библиотеку fastf1 с сырыми данными с телеметрии болидов и решил посмотреть в цифрах на этот самый клиппинг. Длинная 1.2-километровая задняя прямая в Шанхае (между 13 и 14 поворотами) показалась мне идеальным полигоном, чтобы на цифрах проверить, насколько сильно машины задыхаются в конце скоростных участков.
Статья о том, почему «лучшие хиты Queen» и «что-нибудь под пробежку» – это принципиально разные запросы, и что с этим делать ML-инженеру музыкального стриминга
Работа принята на EACL 2026 Workshop NLP4MusA. Авторы: Фёдор Бузаев, Ринат Муллахметов, Роман Богачёв, Илья Седунов, Олег Павлович, Камиль Мазитов, Дарья Пугачёва, Иван Сухарев (Zvuk, AIRI, НИУ ВШЭ, Иннополис).
Привет, Хабр!
За последние годы большие языковые модели (LLM) глубоко проникли в нашу работу и повседневную жизнь. Многие из нас регулярно используют их как обычные пользователи в веб-интерфейсе. Но что, если вы хотите выйти за рамки «чата с моделью» и создавать собственные интеллектуальные инструменты под конкретные задачи и бизнес-сценарии?
Если ваш основной язык программирования — R, то у меня для вас отличная новость! Экосистема R за прошлый год совершила огромный скачок в интеграции с ИИ.
Всем привет.
Речь пойдет о методике ETL-процесса. Очень мало информации об этой важной области работы с данными. Я много раз видел на проектах, что в командах нет общего не то что фреймворка, а даже методики по загрузке данных. Либо есть, но у каждого разработчика своя. И те, что есть, не универсальны и не учитывают некоторые реперные точки. Иногда даже журнал загрузок не ведется. Созрела идея создать, перенести свою методику в питон код и поделиться. Начнем.
Когда мы создаем ETL- процессы основные требования: идемпотентность, обработка ошибок, целостность данных, инкрементальность, производительность, мониторинг, происхождение данных, и т.д. Может еще что, но и этого достаточно.
Основные понятийные объекты в тексте: tech_query_id, tech_batch_id. tech_query_id – является штампом момента запуска pipeline, вручную или автоматически, не важно. Если запустили загрузку для терабайт данных, то и штамп будет всего один для этой конкретной загрузки. Штамп tech_query_id проставляется в каждой строке в самих таблицах с данными цели и в журнале. А так же проставляется tech_batch_id, который является обычным номером пакета. Понятно зачем пакеты.., если данных миллионы, мы их бьем по пакетам. Номер пакета для каждого query_id начинается с единицы. Эта комбинация является ключом в таблицах с данными для трассировки происхождения и ключом в таблице журнала загрузок для фиксации метаданных, дельтапоинта и любой полезной информации в json поле.
