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

Kafka — это популярный брокер сообщений, который используется в самых разных проектах: от обработки логов и управления очередями задач до персонализации контента и аналитики в реальном времени. Например, его можно использовать для индексирования изменений в Википедии или поиска товаров в интернет-магазинах. Manticore Search, в свою очередь, поддерживает интеграцию с Kafka, что позволяет автоматически импортировать данные и использовать их для полнотекстового поиска, аналитики, векторного поиска и многого другого.

При импорте данных в Manticore вы можете гибко их обрабатывать:

Лучший в мире ИИ уже встроен в ваш телефон, почту и поиск, а вы даже не заметили?

Gemini 2.5 Pro занимает первое место на всех ИИ-бенчмарках и предлагается пользователям бесплатно

Узнаете, почему интеграция с семью платформами-миллиардниками делает позиции Google неуязвимыми

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

Доброго времени суток. В этой статье я хочу дополнить первую часть рассказа о том как же донести поисковику информацию о своём сайте. Здесь будут рассмотрены такие темы как IndexNow, security.txt, schema.org.

Привет. Меня зовут Вячеслав Гришанков, и у меня есть сайт, который я очень ценю. Появился он в 2014 году — собран на коленке в общаге в свободное от учебы время (его было много).

Книга Elasticsearch в действии. Второе издание — это подробный (~650 страниц в русском переводе) путеводитель по созданию масштабируемых поисковых систем на базе Elasticsearch. Второе обновленное издание знакомит с архитектурой, API и реальными сценариями применения Elasticsearch — от полнотекстового поиска до визуализации данных и машинного обучения. Книга — отличный выбор для начинающих разработчиков, но наверняка может быть полезна и для практикующих специалистов. 

Как запустить поисковый сервис, если у тебя всего три недели, а данные нужно агрегировать с десятков источников, каждый из которых работает по своим правилам? Как обойти жёсткие лимиты партнёров, которые ограничивают запросы в 500 RPM и p99 до 5 секунд, когда для быстрой загрузки первых результатов нужно минимум 1000 RPM? Как справиться с геопоиском, когда традиционные решения вроде Elasticsearch не подходят?

В 2022 году 2ГИС запустил сервис бронирования Отелло, и перед нами стояла амбициозная цель — не просто создать поиск, а сделать его быстрым, надёжным и масштабируемым, чтобы успеть занять место на рынке. Спойлер: мы справились. В этой статье расскажем, как именно.

Материал будет полезен бэкенд-разработчикам и продакт-менеджерам, которые сталкиваются с задачами интеграции сложных данных, высокой нагрузки и оптимизации поисковых алгоритмов. А если тебе понравится наш проект, рассмотри нашу вакансию — мы в поисках Senior Golang Engineer. 

Привет! Меня зовут Андрей Попов, я SEO-специалист в AGIMA. В современном мире несколько подходов к пониманию поисковых систем вроде Google и Яндекс. Каждый из них имеет право на существование, у каждого свои апологеты и противники. Но, скорее всего, в этом вопросе истина лежит где-то посередине, а абсолютной правды не знает никто.

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

Алгоритмы ранжирования Google основываются на наборе внутренних параметров, которые вручную определяются его инженерами.

Другими словами, это фиксированные параметры, которые не изменяются динамически и применяются как абсолютные правила.

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

Сайтам нужна поисковая индексация, они без этого просто не живут. Это все давно знают. Известно также и то, что хостинг играет большое значение. Я опишу свою странную историю, которая происходит в данный момент и кажется лишена какой-либо логики. Однако по анализу происходящего может быть связана с серверными настройками хостинга, хотя проверка непосредственно моего VPS, не показала ничего подозрительного. А чтобы не оказаться в статусе белой вороны, скажу, что о точно такой же проблеме ранее сообщал другой пользователь (из Турции кажется), но сообщество зарубежного форума только «развело руками» и дало ему простейшие рекомендации проверить на ошибки файл robots.txt или на наличие тега noindex.    

Агенты супер багованы. В своих проектах в компании мы заметили, что Langchain стал работать хуже. В мультиагентных системах агенты зачастую циклятся, так как не понимают, когда они выполнили финальное действие, не вызывают друг друга когда надо, или же просто возвращают данные в битом формате JSON. Короче говоря, создать агентную систему стало не так то просто, и мы даже стали задумываться об упрощении систем, избавляясь от кучи агентов. И вот неделю назад OpenAI обновили SDK для создания агентов, а еще выкатили доступ к новым тулзам по API. Ну и я пошел тестить.

Как я отказался от оверинжиниринга и переместился с 30 места на 7 в Enterprise RAG Challenge. И чего не хватило до 1 места.

Сейчас облась ИИ – дикий запад. Никто не знает, как правильно решать задачи, а результаты экспериментов лежат приватными под NDA. Тем ценнее, когда кто-то делится реальным опытом с разбором деталей и подводных камней. Так что делюсь с хабром своей мартовской статьей про участие в Enterprise RAG Challenge от Рината LLM под капотом

Если вы интересуетесь разработкой продуктов поверх LLM, то

Привет! Меня зовут Павел Яковлев, я инженер по разработке ПО искусственного интеллекта в YADRO. В команде GenAI мы занимаемся умными продуктами на основе корпоративных баз данных.

В проектах мы часто используем современные генеративные модели и энкодеры. В статье расскажу, как мы в компании разрабатываем и оптимизируем семантический поиск по сложным документам: PDF, HTML и DOCX.

Из‑за санкций, эластик многие стали отвергать. Единственное, что его спасает, это RAG'и шмаги. Я первую работу выбрала в поисковом отделе, для меня это было гораздо «сексуальнее», чем datascience, с которым я была уже знакома. 8 лет назад начала изучать эластик. Наработалась «интуиция» на его функционал, так как с нуля я делала поиск для других компаний несколько раз. Поиск текстовый, GEO поиск, подсказки для поиска (suggester) и с МЛ'ем которым майнились синонимы или кластеризовались запросы.

В технологии зеркальных движений (технологии D-SELF) анализировались природные движения от землетрясений до глобальных вихрей в атмосфере и океане. Было установлено, что «зеркальность» связана с пространственно-временной симметрией относительно особых точек (центров симметрии), разделяющих движения на устойчивые зеркально-сопряженные интервалы. Особыми точками могут являться точки пересечения (встречи) движущихся объектов, либо значения критических параметров, таких как предельные скорости движения объектов, либо физические константы (например,скорость звука) и другие локальные параметры.

Общие центры симметрии D-SELF позволили объединить несвязанные (на первый взгляд) движения различных объектов, и представляли загадку, которая не находила решения в рамках обычной логики причинно-следственных связей.

Одно из решений проблемы пришло с неожиданной стороны – из древнегреческой физики...

Всем привет! Это Игорь Густомясов, CTO кластера техноплатформы в МТС, и Никита Бояндин, ведущий разработчик в том же кластере. (Да, мы создали текст вместе.) Рассказываем о поиске данных API для Интеграционной платформы МТС.

Наш коллега Александр Бардаш круто расписал, как мы развиваем функции Интеграционной платформы. Так вот: получилось настолько хорошо, что возникла проблема.

В экосистеме МТС множество продуктов — от проката самокатов до высокотехнологичных сервисов The Platform. Стоило интеграционной платформе встать на ноги, как на ней резко выросло количество спецификаций API.

Так перед нами развернулась двойная задача: не только технически поддержать различные протоколы взаимодействия (HTTPS, gRPC, GraphQL и прочие), но и сделать поиск данных API. Решение — под катом.

Представим себе такой сценарий.

Пользователь устно и/или в чате поручает ИИ-агенту найти и приобрести нужный товар с заданными параметрами.

ИИ-агент в разговоре уточняет у пользователя задание, составляет описание товара и на его основе формирует запрос к поисковой системе... а затем ищет товар в базах данных поставщиков.

OpenAI часто упрекают в недостаточном внимании к продуктовой составляющей. Критикуют, что компания никак не может перестроиться с роли исследовательской лаборатории на полноценную коммерческую структуру.

В то же время Perplexity активно делает акцент именно на продукте. Их CEO в одном из недавних интервью заявил, что ключевое конкурентное преимущество компании заключается именно в тщательной работе над продуктовой частью.

Решил провести небольшой эксперимент и сравнить два похожих инструмента — Deep Research от OpenAI и аналогичную функцию у Perplexity.

Deep Research очень рекомендую для проведения "кабинетных" исследований, я уже сэкономил пару десятков часов работы, подписка себя с лихвой окупила.

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

После моей прошлой статьи прилетело много фидбэка.Я не эксперт в области торрентов, но благодаря комментариям узнал несколько интересных нюансов. Это вдохновило меня на продолжение предыдущей стати и создания мини-аналога IKnowWhatYouDownload (как оказалось, его можно сделать буквально за пару часов).

Начнем с базы

Разберемся, как работает IKnowWhatYouDownload (и подобные агрегаторы).
Вот что говорят его создатели:
Торрент-файлы попадают в нашу базу данных несколькими способами. Во-первых, мы собираем новинки с популярных торрент-сайтов (как зарубежных, так и российских). Во-вторых, у нас есть компоненты, которые постоянно мониторят DHT-сеть. Если кто-то ищет или анонсирует infohash, мы также добавляем его в базу.

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

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

Как вы понимаете, на сайте идеология другая — получить по большому количеству торрент-файлов как можно больше данных, поэтому применяемые методы могут быть неточными. Да, кроме того, на сайте не отображаются данные старше 4х недель.

Что такое DHT?

DHT (Distributed Hash Table) — это технология, которая используется в торрент-сетях для децентрализованного поиска участников раздачи (пиров) без необходимости подключения к центральному трекеру. Вместо того чтобы полагаться на сервер, DHT позволяет каждому участнику сети хранить и обмениваться информацией о пирах напрямую.