На SQL-собеседованиях интервьюер часто формулирует условия устно, просит рассуждать вслух и быстро писать запрос в реальном времени. Это непривычный формат — и именно поэтому он становится испытанием даже для тех, кто много практиковался.
В предыдущей статье мы говорили о текстовом поиске, а в сегодняшней я расскажу о векторном (семантическом) поиске.
Итак, если мы используем OpenSearch, в Yandex Cloud представляется логичным использовать модели вложений этого же облака.
Этот код можно запустить как Python Cloud Function. Написан он исходя из того, что в каталоге сервисного аккаунта, под которым запускается функция, доступна модель вложений (embedding). Детали подключения к кластеру описаны в документации.
Рассмотрим один крайний случай: если мы подключаемся, указывая FQDN DATA-узлов, у которых не включен публичный доступ, то функция должна запускаться в сети кластера OpenSearch, иначе они будут недоступны. Альтернативные варианты: подключаться через «Особый FQDN» или узел DASHBOARD с публичным доступом.
Код создаёт тестовый индекс с текстовым и векторным полем, явно вызывает embedding model через REST API, создавая векторы вложений для документов и запроса, и выполняет векторный поиск, демонстрируя способ интеграции. Обратите внимание на способ выбора разных моделей для документов и запросов.
Ранее я уже делился опытом, как мой приятель искал работу в Германии в 2025 году (см. статью [Личный опыт] Поиск работы в Германии в середине 2025). И вот теперь уже нашей компании самой пришлось искать Middle Data Engineer в команду на замену увольняющемуся сотруднику, что позволило мне взглянуть на процесс с другой стороны баррикад, так как я выполнял в этом найме роль основного технического эксперта. Как это выглядит со стороны работодателя, а также своими наблюдениями я хочу поделиться в данной статье.
Спойлер - от результата (кого в итоге мы наняли) я выпал в осадок %)
Сегодня наличие платформы данных является уже де-факто стандартом даже для малого бизнеса. И частный, и государственный секторы понимают важность цифровой трансформации через накопление и анализ данных для будущей монетизации и грамотного управления. Принятие стратегических и даже операционных решений на основе экспертизы и чуйки уходит в прошлое. Прогнозирование спроса, управление запасами, оптимизация логистики — все опирается на анализ данных.
Однако внутренняя эффективность компаний при работе с данными (трансакционные издержки) остается все еще «темной материей». Time-2-market для релиза цифровых решений по-прежнему велико, документация устаревает быстрее среднего срока работы специалиста по данным в компании, а приоритезация бэклога, выбор способа расчета метрик и т. д. принимаются на основе экспертизы, эскизов в Miro и тысяч внутренних Excel-таблиц, которые переделываются при каждой смене лидеров направлений. Все это — скрытые внутренние издержки, которые негативно сказываются на марже компании в долгосрочном периоде.
Искусственный интеллект резко ворвался в нашу жизнь. Для кого-то это возможность смотреть или генерировать прикольные и не очень картинки и видео, которые многим уже надоели.
А для нас, коллеги, это мощный инструмент, позволяющий быстрее решать различные задачи. Многие кто уже успел попробовать Cursor и подобные инструменты, восхищаются как ИИ способен писать код.
В этой статье речь пойдёт о менее заезженной, но не менее актуальной теме – как ИИ уже сейчас помогает проектировать базы данных.
Кажется, о внедрении каталога данных не написал только ленивый. Каждая крупная компания так или иначе к этому (каталогу) приходит. Пробует разные решения и методологию. У кого-то успешно только на презентации для совета директоров (чаще всего), у кого-то на деле.
Здесь же я хочу рассказать не о том, как заполнять каталог или какой выбрать. А о том, что нужно сделать, прежде чем переходить к покупке/запуску этого каталога. Для тех, кто уже имеет такого зверя в своем зоопарке, но с ним что-то не так, думаю, тоже будет полезно.
Если вы один из счастливчиков, у кого каталог действительно взлетел, можете дальше не читать. Однако что-то мне подсказывает, что таких будет не много.
Осторожно, статья-детектор.
Привет, Хабр! На связи — технические лидеры направления разработки Apache Spark в составе платформы Data Ocean Андрей Первушин и Дмитрий Паршин из Data Sapience. Мы занимаемся решением нетривиальных задач в области Spark-вычислений, некоторые из которых становятся частью конечного продукта.
Сегодня мы расскажем, с какими проблемами можно столкнуться при реализации Upsert Streaming в Iceberg, что такое equality delete, почему они создают нагрузку при чтении таблиц в Apache Iceberg и как мы оптимизировали Apache Spark, чтобы снизить потребление памяти и ускорить чтение данных.
Давайте разберем, как выглядит работа с MCP, на реальном примере из опыта моего дата-консалтинга. В этой статье теории не будет, только практика, много скриншотов и пара лайфхаков.
В A/B-тестах хотелось бы смотреть на главную метрику, ту самую North Star, которая показывает успех продукта. Но на практике она почти всегда медленная, шумная и бесполезная для быстрых решений. Например, вы запускаете тест новой системы рекомендаций, ждёте неделю, две, а LifeTime Value не двигается. И непонятно, это потому что нет результата или ещё рано делать выводы.
Чтобы не тратить месяцы на догадки, можно воспользоваться прокси-метриками — быстрыми, чувствительными показателями, которые реагируют раньше, чем бизнес-метрика «успевает моргнуть». Проблема в том, что это решение часто требует дополнительные ресурсы.
Привет, Хабр! Меня зовут Артем Ерохин, и я Data Scientist в X5 Tech. Я прочитал современные исследования, пропустил их через свой опыт и собрал концентрат подходов к работе с прокси-метриками. Постараюсь передать только суть. Разберемся, зачем нужны прокси, как с ними не выстрелить себе в ногу, где заканчивается польза и начинается самообман.
Привет, Хабр!
Сегодня предлагаю обсудить Managed OpenSearch Yandex Cloud. Поговорим о том, как автоматизировать управление кластером, чтобы сократить расходы на разработку, и как улучшить качество поиска на русском языке, используя доступные в сервисе инструменты морфологии.
Импортозамещение аналитических систем остаётся одной из наиболее трудоемких задач в корпоративной ИТ-среде. Особенно когда речь идёт о платформах уровня SAP BW/4 HANA: больших объемах данных, сложной архитектуре, множестве отчетов и строгих нефункциональных требованиях. В подобных проектах важны не только выбор стека и корректная миграция хранилища, но и организационные решения, планирование и работа с пользователями.
Всем привет! Меня зовут Михаил Синельников, я лидер кластера импортозамещения аналитической отчетности в ВТБ. Вместе с моим коллегой Владимиром Ведяковым, ИТ-лидером проекта со стороны компании «Сапиенс Солюшнс», мы описали в этой статье перенос системы аналитической отчетности SAP BW/4 HANA на импортонезависимый стек. В этом материале представлен наш практический опыт: ключевые решения, подходы к планированию, особенности реализации и выводы, которые могут быть полезны командам, работающим с аналогичными задачами.
От «обезьяньей» работы к Smart-анализу: как правильно готовить данные для моделей.
Что такое Exploratory Data Analysis и как избежать основных ошибок при его выполнении.
В статье описываю практический опыт построения корпоративного ИИ‑ассистента: от структуры базы знаний и графовой модели до фильтрации контекста и контроля версий. Материал будет полезен продактам, архитекторам, маркетологам и всем, кто внедряет ИИ в бизнес‑процессы.
«Garbage in — garbage out», как мусор в корпоративной Базе Знаний мешает корректной работе ИИ и как мы предлагаем это исправить.
Сегодня многие компании внедряют ИИ‑агентов по упрощённому сценарию: загружают PDF‑регламенты, Excel‑прайсы и архивы переписок в векторную БД, после чего ожидают, что модель будет корректно отвечать на вопросы пользователей.
Такой подход, известный как Naive RAG, в большинстве случаев приводит к нестабильным результатам: несогласованные ответы, ошибки в тарифах, применение устаревших инструкций.
Причина — не в возможностях моделей: современные LLM хорошо работают с контекстом. Проблема — в структуре данных, которые подаются на вход. Если знания представлены в виде фрагментов без связей, версий и семантической целостности, то на выходе появляется то, что обычно называют «галлюцинациями».
Краткая история о техническом эксперименте. Автор проанализировал многолетнюю историю высоколиквидных активов, чтобы найти «гарантированные» ранги наклона, которые всегда дают выигрыш. Робот был идеален, но столкнулся с фундаментальным препятствием. О том, как эмпирическое фиаско приводит к формулировке метафизического принципа, который опровергает Эйнштейна и Екклесиаста.
Привет, Хабр! Хочу поделиться опытом разработки такой системы. Определяющими параметрами проблемно‑ориентированной системы являются.
Статья демонстрирует построение минималистичного MapReduce-фреймворка на Scala для локальных экспериментов. Рассматриваются стадии Map, Shuffle и Reduce с ленивыми вычислениями через Iterator, а также абстракции ввода/вывода IO и локальные исполнители с виртуальными потоками.
Миронов В.О., Кальченко С.Н.
Приветствую вас, бравые хаброжители ;-) В наше время искусственный интеллект очень быстро развивается, при этом, вносит значительные коррективы в развитие различных профессий, диктуя там свои правила и виденье. При этом основные козыри — это скорость, время и профит. В этом контексте мы и будем говорить о сложившейся ситуации, а именно, о дифференцированной трансформации профессий.
Да-да, все видели, эти километровые лонгриды, когда ИИшка выкатывает список профессий, которые попадают под трансформацию. При этом какие-то прогнозы сбываются какие-то нет, как и в целом всё в жизни. Однако, почему именно дифференцированной, да всё потому что, профессии даже не столько дифференцируются, сколько видоизменяются, но их суть остаётся той же. Бывает даже так, что не всегда удаётся охватить весь спектр нововведений.
Команда Python for Devs подготовила перевод статьи о том, почему Python — несмотря на свою популярность — не всегда идеален для Data Science. Автор показывает, как отсутствие нестандартной оценки выражений усложняет анализ данных, и сравнивает Python с R, где такие задачи решаются куда элегантнее.
This is a hands-on case study of migrating Trip’s UBT from ClickHouse to StarRocks with storage–compute separation. By redesigning partitioning, enabling DataCache and MergeCommit, and backfilling history via SparkLoad, we reduced average query latency from 1.4 s to 203 ms, P95 to 800 ms, cut storage from 2.6 PB to 1.2 PB, and decreased node count from 50 to 40. We detail Compaction tuning, partitioned materialized views, and second‑level elastic scaling without data migration, and compare gohangout vs. Flink in reliability and operability. The article targets data engineers and architects running high‑load real‑time OLAP workloads.
Статья объясняет, как StarRocks 4.0 делает запросы к JSON почти столь же быстрыми, как к нативным столбцам. FlatJSON на этапе загрузки «колоннизирует» частые поля и задействует индексы (включая ZoneMap), словарное кодирование и Global Dictionary, а также Late Materialization. В результате логовая, e‑commerce и IoT‑аналитика работает в реальном времени без тяжёлого ETL.
