Сегодня мы запустили новый сервис Нейро — новый способ поиска ответов на вопросы. Пользователь может задать Нейро любой вопрос, а тот сам подберёт подходящие материалы в Поиске, проанализирует их и соберёт найденную информацию в одном ответе, подкрепив его ссылками на источники. Нейро объединил опыт Яндекса в создании поисковых технологий и больших языковых моделей.
Меня зовут Андрей Сюткин, и я отвечаю за ML-трек в Нейро. В этой статье покажу, как выглядит архитектура Нейро и как формируются ответы на технологическом уровне. Ну и, конечно же, поговорим о нейросетях, в том числе о YandexGPT 3, без обучения которых новый сервис просто не увидел бы свет.
TL;DR В статье рассказывается о том, как мне удалось перевести чтение лент в ВКонтакте**, Telegram, Facebook*, Instagram**, Reddit и почтовых рассылок в единый сервис InoReader. Причем почти без написания своих велосипедов.
В сентябре я устроился на должность поискового дата-саентиста и с тех пор часть моих обязанностей заключается в работе с Solr — опенсорсным поисковым движком на основе Lucene. Я знал основы работы поискового движка, но мне хотелось понять его ещё лучше. Поэтому я закатал рукава и решил создать его с нуля.
Давайте поговорим о целях. Слышали когда-нибудь о «кризисе сложности обнаружения маленьких веб-сайтов»? Проблема в том. что маленькие веб-сайты наподобие моего невозможно найти при помощи Google или любого другого поискового движка. Какова же моя миссия? Сделать эти крошечные веб-сайты снова великими. Я верю в возвращение славы этих малышей вдали от SEO-безумия Google.
В этом посте я подробно расскажу о процессе создания поискового движка с нуля на Python. Как обычно, весь написанный мной код можно найти в моём GitHub (репозиторий microsearch). Эта реализация не будет притворяться готовым к продакшену поисковым движком, это лишь полезный пример, демонстрирующий внутреннюю работу поискового движка.
Кроме того, мне стоит признаться, что в заголовке поста я слегка преувеличил. Да, поисковый движок действительно реализован примерно в 80 строках Python, но я ещё и писал вспомогательный код (краулер данных, API, HTML-шаблоны и так далее), из-за которого весь проект становится немного больше. Однако я считаю, что интересная часть проекта находится в поисковом движке, который состоит из менее чем 80 строк.
P.S. Написав этот пост и microsearch, я осознал, что пару лет назад нечто похожее написал Барт де Гёде. Моя реализация очень похожа на работу Барта, но я считаю что кое-что улучшил, в частности: (1) мой краулер асинхронный, что сильно ускоряет работу, (2) я реализовал пользовательский интерфейс, позволяющий взаимодействовать с поисковым движком.
Вот так когда-то отвечала языковая модель, когда её просили привести пример стихотворения Бальмонта. Стихотворение с таким названием действительно есть, но начинается оно совсем не так.
К сожалению, генеративные модели могут галлюцинировать и выдумывать ответ. С таким мы боремся с помощью внешней информации.
Мы, Александр Кайгородов и Светлана Маргасова, обучаем генеративные модели в Яндексе. В этой статье мы расскажем, как заставить генеративные модели перестать придумывать несуществующие факты и как научиться находить эти ошибки, если они всё же случаются. Вы узнаете о том, как использовать внешнюю информацию, опираясь на которую мы можем выполнять как обусловленную генерацию (Retrieval Augmented Generation), так и фактологическую оценку имеющихся генераций (Fact-Check).
moz_places.sqlite содержатся все посещённые URL-адреса и адреса закладок (то есть moz_bookmarks.sqlite базы данных SQLite). У меня получилось около 2000 закладок. Это меньше, чем я предполагал, так как многие оказались нерабочими из-за битых ссылок. 
В этой статье я расскажу вам о том, как мы в Ozon оптимизируем базовый поиск: как у нас выстроены процессы, как найти бутылочное горлышко, конкретные рекомендации по написанию горячего кода, реальные примеры значимых оптимизаций и что делать, когда все низко висящие фрукты уже сорваны, а хочется ещё.
Пару недель назад я совершенно случайно обнаружил в Яндекс Вебмастере плашку о фатальной ошибке. Там было написано, что мой сайт может угрожать безопасности пользователя, или на нём были обнаружены нарушения правил поисковой системы. Других ошибок не было: индекс качества даже немного подрос.
Удивительно было, что этот сайт — известное в регионе СМИ, и вопросов к нему со стороны Яндекса не было все восемь лет его существования. Потому что мы и на самом деле нарушениями правил поисковиков не занимаемся. Но сначала я, конечно, подумал, что проблема в нас самих — где‑то спрятался баг или, того хуже, взломали. Однако всё оказалось куда интереснее.
Дело оказалось в новом алгоритме Яндекса, который теперь буквально запрещает писать новости. В нашей области он уже забанил примерно треть независимых региональных СМИ. Причём под удар, на удивление, попали одни из самых качественных. Поэтому я считаю, что проблема здесь не столько в сайтах, сколько в самом алгоритме, создатели которого придумали хорошую идею по борьбе за уникальность контента, но не до конца её протестировали. Почему я пришёл к такому выводу и что конкретно с алгоритмом не так, я здесь и расскажу.
На КПДВ: «Региональный журналист пишет новость» глазами другой нейросети Яндекса — «Шедеврум».
Привет! Меня зовут Артём, я руковожу командой эффективности рекламы в Ozon. Наша задача состоит не только в том, чтобы реклама приносила деньги компании, заказы рекламодателям и была релевантной для пользователей, но и в том, чтобы сделать запуск рекламных кампаний удобным и эффективным для рекламодателей.
В статье я расскажу о том:
• как мы пришли к идее автоматического управления ставками в рекламных кампаниях на платформе;
• какие алгоритмы оптимизации и машинного обучения нам помогли;
• как построена архитектура автобиддера;
• как выкатить новый продукт в прод и измерять эффективность.
Есть много причин почему доступ научным статьям и книгам должен быть свободным:
Во-первых, это прекрасно
Поскольку ChatGPT последних версий недосягаем для честной российской белошвейки, все мы возлагаем огромные надежды на отечественного производителя.
Это вторая статья из цикла. В первой части я рассказывал про самые базовые понятия Elasticsearch. В этом же посте разберем устройство анализа текста и немного пощупаем полнотекстовый поиск.
Несколько слов про анализ текста
Анализ текста — процесс преобразования оригинального текста в структурированный формат, оптимизированный под эффективное хранение и быстрый поиск.
Мы уже познакомились с некоторыми типами Elasticsearch, но в этом разделе будем рассматривать только два — keyword и text. Тип text анализируется для полнотекстового поиска. Тип keyword преимущественно остается без изменений для точного поиска, сортировки и агрегации.
При построении прикладных систем, работающих с текстами, первая же задача — это отождествление слов друг с другом. Для большинства языков индо-европейской группы её решение не представляет большой сложности. И решений этих существуют сотни, а самые простые из них, как правило, дают вполне пригодные (в рамках решаемой задачи) результаты.
Английский, с его весьма условным делением на части речи и практически отсутствующим склонением/спряжением, вполне прилично описывается простыми моделями выделения неизменяемой основы слова (стеммерами) с небольшим словариком исключений буквально на сотню слов. Слова немецкого прекрасно бьются на части по формальным признакам, словарю корней и принципу «максимума суммы квадратов длин». Системы окончаний других европейских языков также достаточно просты.
Со славянскими языками сложнее из-за развитой грамматики и глубокой изменчивости — любое русское прилагательное, к примеру, имеет как минимум двадцать четыре разных грамматических формы: три рода и множественное число, да по шесть оставшихся на сегодня падежей. А то и все двадцать девять, если принять во внимание краткие формы (широк, широка, широки) и образуемое от многих прилагательных наречие.
Для решения задачи отождествления разных форм существует некоторое количество реализаций морфологических анализаторов русского. Но почти все они — во всяком случае, заслуживающие внимания — растут из одного корня...
(По материалам внутреннего семинара компании МойОфис)
Два года назад я писал о потенциальном новом поисковике, дерзнувшем бросить вызов гигантам — Google и Bing. С упором на приватность данных и (шок!) платным поиском. Который жил бы не за счет продажи данных пользователей рекламодателям. Со слоганом «Вы — не продукт». Так вот, вчера он объявил о своем закрытии. По крайней мере, в качестве поисковой системы. Ставка на то, что некоторые пользователи готовы платить за безопасность своих данных, не оправдалась. Людей, не пожелавших быть продуктами, оказалось немного.
