Обновить
64K+

Поисковые технологии *

От AltaVista до Яндекса

74,06
Рейтинг
Сначала показывать
Порог рейтинга
Уровень сложности

Спросили три ИИ про мастера в Иркутске: один назвал местных, второй — Одессу и Киев

Уровень сложностиСредний
Время на прочтение5 мин
Охват и читатели10K

В прошлой статье я показал, что три ИИ-модели разных разработчиков выдают дословно совпадающие списки источников, потому что веб-поиск им делает один плагин. В комментариях сказали, что стенд собран на устаревших версиях — я перемерил на свежих, и общий корпус рассыпался: пересечение между Gemini и двумя другими моделями упало до 0.02. Заодно выяснилось, что от поколения зависит не только состав источников, но и то, видит ли движок ваш город: на запрос про Иркутск свежая Gemini дала 8 местных сайтов из 13, а прошлое поколение — ноль из 42. Внутри цифры по двум городам, ловушка с редиректом, на которой споткнётся любой повторяющий замер, и разбор, где эта метрика врёт.

Читать далее

Новости

Как искать живой спрос в шумных городских Telegram‑чатах

Уровень сложностиСредний
Время на прочтение5 мин
Охват и читатели7.7K

Городские Telegram-чаты похожи на непрерывный поток логов без схемы. В одном сообщении человек ищет квартиру, в следующем агент публикует двадцатую копию объявления, затем идут курс валют, потерянный телефон, рекомендация врача и спор не по теме. Поиск по словам быстро упирается в синонимы, несколько языков, устаревающие сообщения и главное противоречие: «сниму квартиру» и «сдам квартиру» говорят об одном объекте, но требуют противоположных результатов.

Ниже — архитектурные решения, которые мы используем в Global Pulse, поиске по городским Telegram-сообществам. Первый город — Нячанг. Это не рассказ о гарантированных лидах: система работает только с доступными сообщениями и может пропускать полезные события или ошибаться в классификации.

Читать далее

Честный RAG eval set: как собрать первые 100-300 кейсов и не обмануть себя цифрой

Уровень сложностиСредний
Время на прочтение13 мин
Охват и читатели7.4K

В прошлой статье серии мы сжимали эмбеддинги и замеряли, насколько изменится выдача относительно полного fp32-поиска. Там это был правильный вопрос: ломает ли квантизация уже существующий retrieval.

Но у такого замера есть неприятное слепое пятно. Можно аккуратно сохранить 99% выдачи исходного эмбеддера и все равно плохо находить нужные документы на своем домене. Внешний бенчмарк, даже сильный, этого не гарантирует. BEIR как раз был создан, чтобы показать, насколько результаты retrieval меняются между разными задачами и доменами; один усредненный скор там не заменяет проверку на собственных данных.

Нужен свой eval set. И тут обычно возникает ложная развилка:

Читать далее

Почему Илону Маску не удается создать по-настоящему правдивую нейросеть?

Уровень сложностиПростой
Время на прочтение6 мин
Охват и читатели6.3K

Илон Маск как одержимый выпускает на рынок все новые модели своей нейронной сети Grok, и 12 августа уже стала доступной версия 4.6, но, хотя он постоянно подчеркивает, что его детище является максимально правдивым ИИ, правдивость ответов Grok в некоторых случаях не обеспечивает. Это не случайно – в модели содержится принципиальный дефект – она не владеет научными правилами отличия правды от лжи и заблуждений. Чтобы исправить этот дефект, к алгоритмам обучения SFT и RL следует добавить новый – НРД.

Несколько лет назад Илон Маск захотел создать альтернативу ChatGPT – нейросеть TruthGPT, в которой упор был бы сделан на поиск правды, однако что-то пошло не так, и у него получилась в 2023 году нейросеть Grok, у которой из-за минимальной цензуры существует значительный риск воспроизведения непроверенных данных, поэтому ее пользователям рекомендуют обязательно проверять факты.

Тем не менее, сам Илон Маск постоянно подчеркивает, что его детище является максимально правдивым ИИ, даже если эта истина иногда противоречит общепринятой точке зрения или политкорректности. Да и название нейросети, которое взято из романа Роберта Хайнлайна «Чужак в чужой стране», там использовалось в смысле интуитивного, глубинное понимание чего-либо. То есть претензии на правду остались, несмотря на другое название.

Маск считает, в частности, что другие нейросети содержат скрытые элементы идеологии разнообразия, равенства и инклюзивности (DEI), а это представляет серьезную угрозу, так как ИИ может из-за этого принимать неверные решения. Например, если ИИ научить, что разнообразие является единственным приемлемым результатом, то нейросеть может сказать, что у власти слишком много белых парней, и их надо просто казнить. А если, допустим, запрограммировать ИИ думать, что неправильное определение пола – это худшее, что может произойти, тот, чтобы гарантировать, что неправильное определение пола никогда не произойдет, решит просто уничтожить всех людей, так как это сведет к нулю  вероятность неправильного определения пола.

Читать далее

SEO трафик на сайте есть, а заявок нет. Я полез в серверные логи и посмотрел, кто на самом деле «ходит» на сайт

Уровень сложностиСредний
Время на прочтение15 мин
Охват и читатели9.7K

У сайта рос органический трафик, позиции были в порядке, а заявок всё равно не хватало. Клиент задал простой вопрос: «Если людей стало больше, где заявки?»

Я полез не только в Метрику, но и в access.log — и там уже начался отдельный зоопарк: Googlebot, YandexBot, GPTBot, Ahrefs, Semrush, MJ12bot, DataForSEO и Chrome, который вёл себя совсем не как человек.

В статье покажу, как отличать визиты от серверных запросов, проверять настоящего Googlebot, разбирать crawler'ов и решать, кого вообще стоит пускать на коммерческий сайт через robots.txt.

Читать далее

Написал валидатор llms.txt на 64 тестах — и проверил, читают ли этот файл боты

Уровень сложностиПростой
Время на прочтение4 мин
Охват и читатели11K

Файл llms.txt предлагают класть в корень сайта с 2024 года: считается, что языковые модели прочитают его вместо того, чтобы разбирать вёрстку. Я написал для него генератор и валидатор, проделал 64 теста для отладки — и параллельно посмотрел, сколько раз ИИ-боты вообще запрашивают этот файл. Значения получились неутешительные, но валидатор всё равно оказался полезным. Ниже — устройство разбора, схема оценки и код.

Читать далее

Как я первый в Казахстане измерил ИИ видимость банков (и что из этого вышло)

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели7.9K

Это моя первая публикация на Хабре, который я читаю уже лет 10... Так что, если честно, даже немного трясусь от волнения. Всё равно что смотреть футбол и выйти на поле в составе моего любимого Кайрата. Но постараюсь без лирики и перейду к делу.

Итак, в 2026 году уже всем как будто понятно, что потенциальные клиенты всё чаще выбирают банк не в поиске, а в диалоге с нейросетью (хотя многие с этим до сих пор почему‑то спорят). На выходе клиент получает короткий список из трёх‑четырёх названий.

Так как я занимаюсь аналитикой данных, мне стало интересно, по какому принципу этот список собирается, как эти данные обрабатываются, и кто вообще попадает в этот заветный шорт‑лист.

Ниже я описываю, как за пару вечеров собрал на Python замер видимости банков Казахстана в пяти ИИ‑ассистентах, на что напоролся и к каким выводам в итоге пришел. Код и формулы прилагаю, цифры можно перепроверить, если у вас будет желание.

Читать далее

Почему цена Bitcoin «сломалась»: разбор аномалий 2022–2026 с WhyTrend

Уровень сложностиСредний
Время на прочтение7 мин
Охват и читатели6K

Увидел провал на графике → открыл Google или Twitter → полдня собираешь версии "почему". Знакомо? Детектор аномалий сам по себе даёт только точки на оси времени, а вопрос "почему" как был ручным, так и остаётся.

В этот раз я прогнал WhyTrend не на паре аккуратных точек из Google Trends, а на полном ряде BTC за 4.5 года — и заодно на двух разных LLM. Результат оказался неожиданным: модель меньшего размера дала в три раза больше настоящих объяснений, чем более крупная. Расскажу, что случилось и почему.

Читать далее

Один запрос, семь ИИ-поисковиков, ноль общих источников

Время на прочтение6 мин
Охват и читатели11K

Когда человек спрашивает у ассистента «к кому обратиться», он получает не десять синих ссылок, а один ответ с пятью-десятью доменами внутри. Я прогнал два запроса через семь ИИ-поисковиков в один заход и сравнил, кого именно они цитируют. Общего источника не нашлось ни одного, а три модели разных разработчиков выдали дословно совпадающие списки — потому что веб-поиск им делает один и тот же плагин. Ниже — стенд, цифры и пять мест, где методика такого замера ломается.

Читать далее

Поиск после LLM: почему классической SEO-модели уже недостаточно

Уровень сложностиПростой
Время на прочтение3 мин
Охват и читатели8.6K

Эта статья не о том, что SEO перестало работать. Она о том, почему архитектура поиска изменилась настолько, что привычной модели «индексация → ранжирование → клик» уже недостаточно для описания происходящего.

На протяжении более двадцати лет веб-поиск был относительно простой системой.
На высоком уровне ее можно представить следующим образом:

Читать далее

Когда подписи недостаточно: как мы расчищали «серую зону» в Поиске по картинкам

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели9.3K

Исторически в Яндекс Картинках релевантность документа оценивалась по двум сигналам: насколько запросу подходит само изображение и насколько — текст, связанный с этим изображением. Такой подход позволяет учесть контент картинки и не провалиться на визуально трудноотличимых объектах, однако он же порождает проблему: в «серой зоне», когда текстовая релевантность не сонаправлена с картиночной, становится неочевидно, как именно агрегировать сигналы в финальный скор релевантности.

Привет! Я Константин Николаев, занимаюсь внедрением нейротехнологий в Поиске по картинкам. В этой статье я расскажу, как наша команда научила модели смотреть на картинку и читать текст документа одновременно: начали с тяжёлой мультимодальной VLM ради максимального качества, а затем дистиллировали её в набор лёгких моделей — по одной под каждую стадию пайплайна. Что из этого удалось довести до realtime‑поиска с десятками тысяч запросов в секунду и как совместный анализ двух модальностей добавил 5% релевантных картинок в топ выдачи — под катом.

Читать далее

UUID в Manticore: практическое руководство

Время на прочтение9 мин
Охват и читатели7.9K

В обзорной статье мы разобрали, зачем использовать в поиске тот же UUID, что и в основной базе (если таковая имеется). Здесь сразу перейдём к практике: создадим таблицу, выполним основные операции через SQL и JSON API, а затем загрузим несколько документов через /bulk.

Все примеры рассчитаны на Manticore Search 28.5.0 или новее. Значение <generated UUID> в ответах обозначает UUID, который Manticore создаст при обработке запроса. Копировать эту строку в следующий запрос не нужно: подставьте фактический id из своего ответа.

Читать далее

Винни-Пух в 768 измерениях: семантический поиск Codex Pets на YDB

Уровень сложностиСредний
Время на прочтение10 мин
Охват и читатели8.6K

В многомерном пространстве найти Винни-Пуха можно даже не зная его имени. В запросе “тревожный коричневый медведь из старого мультфильма” нет ни одного слова из имени или описания питомца, но гибридный поиск по словам и векторам всё равно выдает его первым. Показываю, как Codex Pets превращает текст и кадры анимации в векторы, сравнивает их в YDB и помогает Винни найти друзей.

Читать далее

Ближайшие события

UUID в Manticore: единый ID для основной БД и Manticore

Время на прочтение5 мин
Охват и читатели8.9K

Допустим, у вашего товара в основной базе уже есть ID 550e8400-e29b-41d4-a716-446655440000. Он попадает в события, логи и ответы API. Но при загрузке того же товара в Manticore приложению приходится выдавать ему ещё один, числовой ID.

До Manticore Search 28.5.0 ID документа был беззнаковым 64-битным числом. UUID можно было сохранить в отдельном строковом атрибуте, однако идентификатором документа он от этого не становился. Для UPDATEREPLACE и DELETE всё равно требовался числовой id.

В результате приходилось хранить соответствие между UUID из основной БД и числовым ID в таблице Manticore. Теперь без него можно обойтись: RT-таблица Manticore умеет использовать UUID как ID документа.

Читать далее

Я научил Obsidian искать по смыслу. Как устроен локальный семантический индекс без отдельной векторной БД

Уровень сложностиСредний
Время на прочтение14 мин
Охват и читатели9.1K

В комментариях к прошлой статье мне написали примерно следующее: граф связей выглядит красиво, но хороший поиск по заметкам полезнее.

Спорить было трудно. Я сам регулярно открывал Obsidian, помнил, что где-то писал нужную мысль, но не помнил ни заголовок, ни точную формулировку. Обычный поиск в такой ситуации помогал примерно как человек, который на вопрос «где мои ключи?» отвечает «там, где ты их оставил».

Например, в заметке могло быть написано:

Читать далее

Как я делал базу знаний для ИИ‑агента и тестировал её на собственных медицинских анализах

Уровень сложностиСредний
Время на прочтение12 мин
Охват и читатели5.1K

Результаты годового чекапа пришли в пятницу вечером. Семь документов в личном кабинете лаборатории, в половине строк звёздочки «выше нормы» и «ниже нормы», запись к эндокринологу через две недели. Кто сдавал, тот знает этот вечер: гуглишь каждый показатель по отдельности, находишь ужасы, и нигде не написано, что все эти цифры значат вместе.

Работаю бэкендером, делаю базу знаний в Искре. Поэтому вместо поисковика открыл свой же продукт: загрузил туда все семь файлов и начал спрашивать.

Сразу про конфликт интересов: база знаний, о которой пойдёт речь, — часть продукта, который делаю я сам. Поэтому дальше будет не про то, какая она хорошая, а про устройство и про места, где она ломается.

Читать далее

Фасетный поиск с активными фильтрами

Время на прочтение10 мин
Охват и читатели6K

Фасеты в интернет-магазине кажутся простыми до первого выбранного фильтра.

В каталоге это часть навигации. Выбранный цвет не должен исчезать из списка. Соседние цвета лучше оставить доступными: пользователь может переключиться на них или расширить выбор. А варианты без товаров полезнее сразу показать как недоступные. Внутри одного фасета обычно работает OR: красный или синий. Между разными фасетами - AND: бренд, цвет и размер одновременно.

Неприятная часть начинается после первого выбора. Представьте каталог товаров: пользователь выбрал бренд, цвет и размер. Основная выдача должна остаться узкой и показать только товары, которые подходят под все три условия. Но панель фильтров живёт по другим правилам. В ней нужно сохранить выбранный цвет и одновременно показать цвета, на которые можно переключиться при том же бренде и размере.

Если каждый фасет наследует все фильтры из основного запроса, он быстро схлопывается до уже выбранных значений. Если для каждого фасета фильтры приходится пересобирать вручную, появляются отдельные ветки запросов для цвета, размера, бренда, наличия, продавца и остальных атрибутов.

В Manticore Search 25.12.0 появился facet_filter_mode, который переносит это поведение в API фасетов. Теперь в запросе можно описать, как ведёт себя панель фильтров магазина, а приложению не нужно вручную собирать почти одинаковые запросы для каждого фасета.

Читать далее

Почему никто не объясняет аномалии во временных рядах?

Уровень сложностиСредний
Время на прочтение10 мин
Охват и читатели9.3K

Недавно встретились с коллегой за кружкой кофе, без всякой рабочей повестки. Он занимается Data Science, я — backend‑разработкой. Разговор как‑то незаметно, как это обычно бывает, свернул в сторону обсуждения рабочих нюансов, а самый обычный вопрос про очередной график в дашборде — закончился идеей проекта, который в итоге вырос в open‑source фреймворк.

В какой‑то момент он сказал фразу, которая неожиданно зацепила:

Читать далее

BM25 против эмбеддингов, Protocol против наследования: как рождался фреймворк WhyTrend

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели7.2K

В прошлой статье я рассказывал про WhyTrend — open-source инструмент, который не просто находит аномалии во временных рядах, а пытается объяснить, почему они произошли: собирает внешний контекст (новости, Hacker News, Wikipedia) и формирует объяснение со ссылками на источники. Если коротко: идея выросла из наблюдения, что находить аномалии мы научились отлично, а вот объяснять их до сих пор приходится вручную — гуглить, листать Reddit и Slack, собирать гипотезу самому.

Эта статья — про внутреннюю кухню: почему WhyTrend в итоге оказался фреймворком, а не очередной библиотекой, и какие архитектурные решения к этому привели.

Читать далее

Как оценить стоимость ручного поиска документов в компании на 200 человек

Уровень сложностиПростой
Время на прочтение5 мин
Охват и читатели12K

В корпоративных системах обычно хорошо считают то, что приходит отдельным счётом: лицензии, серверы, внедрение, поддержку, подрядчиков. Эти расходы видно в бюджете, у них есть владелец, договор и понятная строка в финансовой модели.

Мы решили посчитать, во сколько компании на 200 человек может обходиться ручной поиск документов. Взяли простую модель: 15 минут поиска в день на сотрудника, 247 рабочих дней в 2026 году и среднюю стоимость рабочего часа 700 ₽. Получилось 8 645 000 ₽ в год.

Как сэкономить
1
23 ...