home.social

#поиск — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #поиск, aggregated by home.social.

fetched live
  1. Делаем RAG-систему с нуля

    У меня с давних времен сохранилась куча всяких заметок, в основном в виде простых текстовых файлов. Самых разных: от скриптов и конфигов до всяких рецептов, всё что когда-то пригодилось или могло пригодиться. Хранение в виде файлов - это на самом деле очень удобно: их практически всегда можно прочитать, их легко создавать и редактировать, они не требуют установки каких-то специальных особых редакторов и информационных систем, при этом их легко копировать, добавлять в архивы и т.д. И даже полнотекстовый поиск по ним организуется элементарно. Единственный минус, когда их много - для того чтобы что-то найти нужно пройтись по каталогам где они лежат и увидеть глазами. Особенно - если их никто не пытался строго структурировать, и они лежат где-то так: "Документы/старое/1/1/разобрать/старый диск/Документы/Работа/...". Ну, это конечно запущенный случай, и надо бы разобрать, когда-нибудь, может быть - ну, собственно говоря, там так и написано... Что если попробовать прикрутить к этому поиск?

    habr.com/ru/articles/1090066/

    #rag #поиск #ollama #perl #эксперименты

  2. 50 лет эволюции поиска по коду: что под капотом кодинговых агентов

    Когда мы просим Claude Code, Codex или Cursor «починить воот эту функцию», то сначала надо понять, где этот код вообще находится. В каком файле? В какой функции? Как она называется и кто её вызывает? Через какие еще системы пролетают байтики наших данных? За последние полвека для этой задачи придумали огромное количество инструментов: grep , текстовые индексы, полнотекстовый поиск, ctags, LSP, AST, анализ потоков данных, графы, поиск по смыслу и многое другое. Самое забавное, что весь зоопарк с нами и почти ничего из этого не умерло. В 2026 году поиск по коду в лучших кодинговых агентах по-прежнему состоит из алгоритмов и технологий, которым пять, десять, тридцать, а иногда и больше пятидесяти лет (grep вышел в 1973 году!). И в этой огромной статье я расскажу об эволюции этих технологий, истории и философии их создания, решаемых проблемах и способе работы. Погнали!

    habr.com/ru/articles/1089460/

    #grep #ripgrep #векторный_поиск #llm #языковые_модели #поиск #search #ast #lsp

  3. Запустили полнотекстовый и гибридный поиск в YDB: рассказываем, что под капотом

    Привет, Хабр! Меня зовут Александр Зевайкин, и мы с командой делаем YDB (СУБД Яндекса). Год назад я рассказывал на Хабре, как мы запустили векторный поиск , а весной — как он используется в Нейроюристе для поиска по миллионам юридических документов. В релизе 26.3 к векторному поиску добавились полнотекстовый поиск с ранжированием и гибридный поиск, который объединяет оба вида поиска в одном SQL-запросе. Кроме того, мы доработали фильтруемый векторный индекс. Зачем нужны оба вида поиска, хорошо видно на примере. Страховой юрист ищет «выплаты по полису 7702-345678 при переносе рейса». Номер полиса нужно найти слово в слово, а описание случая — понять по смыслу. Полнотекстовый поиск справляется с первой половиной задачи и не справляется со второй, векторный — наоборот. Прежде чем перейти к статье, я хочу пригласить вас на вебинар «

    habr.com/ru/companies/ydb/arti

    #ydb #rag #векторный_поиск #векторный_индекс #полнотекстовый_поиск #полнотекстовый_индекс #гибридный_поиск #поиск #индекс

  4. Тенденции в изменении механик восприятия информации в интернете

    В статье рассматривается, как за последние годы изменился путь пользователя к информации в интернете. Речь идет не только о росте популярности коротких видео, нейросетей или новых поисковых интерфейсов. Более заметное изменение связано с тем, кто теперь отбирает информацию, в каком виде человек получает первый ответ и насколько часто он вообще доходит до исходного источника. В материале сопоставляются данные Reuters Institute, Pew Research Center, Google, Яндекса, ВЦИОМ и ряда академических исследований. Отдельно разбираются алгоритмические ленты, AI-summary, мультимодальный поиск, короткие видео, доверие к ссылкам и сценарии, в которых пользователь получает достаточно информации без перехода на сайт. Основной вывод статьи состоит в том, что привычная схема «запрос — выдача — переход на источник» постепенно дополняется другими моделями. Часть поиска, отбора и интерпретации информации берет на себя интерфейс, поэтому меняется не только потребление контента, но и роль самого источника.

    habr.com/ru/articles/1085510/

    #информационное_поведение #восприятие_информации #алгоритмические_ленты #поиск #AI_Search #генеративный_ИИ #zeroclick #мультимодальный_поиск #GEO

  5. Открываем претрейн Alice AI Search: как устроена модель быстрых ответов Алисы на Поиске

    Быстрый ответ Алисы AI — это самый массовый генеративный продукт Яндекса и первое соприкосновение с Алисой для пользователей Поиска. Даже в час пиковой нагрузки пользователь должен получить лаконичный ответ за считаные секунды. Для этого мы, команда Alice AI Search, адаптируем весь пайплайн быстрых ответов — от собственного претрейна с кастомной архитектурой до онлайн‑rl‑обучения на поведенческие сигналы пользователей. В статье разберём, как устроен генеративный ответ в Поиске, и расскажем про основные улучшения июньского релиза: как мы ускорили ответы за счёт коротких инфоконтекстов, зачем совместили Encoder‑Decoder с разреженной MoE‑архитектурой и как обучение на реальных пользовательских сигналах повлияло на качество и использование продукта. Кроме того, мы выложили в открытый доступ обученную с нуля модель Alice AI‑T5-35B‑A0.6B Base с тем ограничением, что внешним пользователям доступен инференс через Hugging Face Transformers, а оптимизированный production‑инференс пока доступен только внутри Яндекса.

    habr.com/ru/companies/yandex/a

    #яндекс #ai #ml #alice_ai #поиск #ии #быстрые_ответы #опенсорс_яндекса

  6. RAG, поиск и LongContext: почему сложные пайплайны не всегда нужны

    В 2023 году RAG был единственным способом засунуть знания в LLM — контекстное окно было маленьким, часто были галлюцинации. RAG постепенно стал одной из самых популярных технологий, чтобы получить базу знаний, по которой можно искать данные через натуральный язык. Но с другой стороны — RAG-пайплайн тяжёлый и трудозатратный. Компания хочет чат по своей документации. Разработчик говорит: нужен пайплайн — чанкинг, эмбеддинги, векторная база, реранкер. Два-три месяца работы плюс сервис, который надо вечно поддерживать, ради 400-страничной документации. И всё это занимает месяцы, тратит ресурсы ради не такой уж и большой выгоды. Сегодня многие модели держат 1M токенов, а то и больше, а в это окно контекста чаще всего спокойно влезает вся документация. Но если не влезет — то обязательно ли сразу строить весь RAG самому? А как понять, когда есть альтернатива RAG, а когда нет? В этой статье мы разберём, почему RAG стал выбором по умолчанию (и почему это было оправдано), посмотрим, как падает качество при Long Context, сравним подходы и узнаем, что, как и когда использовать.

    habr.com/ru/companies/bothub/a

    #документация #техническая_документация #RAG #LLM #longcontext #AI #ИИ #arxiv #эмбеддинги #поиск

  7. [Перевод] Исследуйте данные Manticore с помощью OpenSearch Dashboards

    Подключите OpenSearch Dashboards к Manticore Search, исследуйте данные в Discover и создавайте визуализации и дашборды в знакомом интерфейсе.

    habr.com/ru/articles/1079666/

    #Manticore_Search #OpenSearch_Dashboards #поиск #визуализация_данных #логи

  8. Найти человека по голосу среди 134 тысяч записей

    В последний вечер дататона у нас оставалось три попытки отправить решение. К этому моменту мы уже перебрали несколько моделей, собрали тяжёлый ансамбль и упёрлись в 0.6605 . Новые энкодеры добавляли по одной-две тысячных, а fine-tuning показывал отличные цифры локально и проваливался на лидерборде. Добавлять ещё одну модель смысла почти не было. Мы решили изменить сам поиск соседей: попробовать K-reciprocal re-ranking, а затем ещё раз применить AS-Norm. От этого варианта ждали примерно 0.67–0.69 . Получилось 0.7042 и 10-е место из 93. Почти весь день мы пытались выжать из моделей тысячные, а перерасчёт соседей добавил больше четырёх сотых без дополнительного обучения.

    habr.com/ru/articles/1043378/

    #ии #speaker #speaker_retrieval #хакатон #бизнес_кейс #machinelearning #ансамбль_моделей #поиск

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

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

    habr.com/ru/articles/1070646/

    #Telegram #поиск #embeddings #pgvector #NLP #уведомления #классификация_намерений

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

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

    habr.com/ru/articles/1070534/

    #rag #retrieval #evals #оценка_качества #LLM #эмбеддинги #поиск #MTEB #ragas #BEIR

  11. Агентный RAG, бенчмарк TRuST и при чём здесь Нафаня?

    Тестирование агентного RAG на многошаговых задачах бенчмарка TRuST: эволюция архитектуры, сравнение моделей и правила работы с промптами для сложных поисковых задач.

    habr.com/ru/articles/1067136/

    #rag #агенты #бенчмарк #поиск #языковые_модели #нафаня

  12. MCP без облака

    У меня возникла такая задача: есть куча файлов, на которые хорошо бы натравить нейросеть, чтобы она искала ответы прямо по ним, а не выдумывала. Файлы разнородные, среди них тяжелые PDF. Закинуть их в модель целиком не выйдет: контекстное окно забьется раньше, чем она доберется до сути. Нужен способ скармливать модели не весь архив разом, а только нужный кусок. Так мне пришла идея применить MCP «с другой стороны» — не для агента, а для аккуратного доступа к большому архиву локальных документов.

    habr.com/ru/companies/basis/ar

    #rag #model_context_protocol #поиск #pdf #markdown #данные #нейросети #mcp

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

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

    habr.com/ru/articles/1065732/

    #документы #поиск #оптимизация #версии #ИИ #деньги #документооборот

  14. YaGo: как я хотел бесплатный self-hosted Tavily API, а в итоге воскресил YaCy

    Всё началось не с мечты про «поисковик нового поколения». Мне понадобился быстрый self-hosted Tavily-compatible API для собственных рабочих и личных AI-решений: без оплаты за каждый запрос, без внешнего сервиса в обязательной цепочке и с индексом, содержимое которого контролирую я сам. Тут я вспомнил про YaCy. Когда-то я уже поднимал его ноду. Идея мне нравилась, а реализация — заметно меньше: Java, тяжёлая машина и примерно шесть секунд ожидания ответа на моей тогдашней установке. Для человека, который один раз нажал Enter, это ещё можно пережить. Для агента, делающего несколько поисков, уточнений и extract подряд, это превращает один шаг в минутный перекур. Поэтому вместо ещё одной обёртки над чужим поиском я оставил от YaCy сетевой протокол и начал собирать поисковую ноду заново: на Go, с отдельным краулером, embedded storage, нормальным API и ranking pipeline из современных работ по information retrieval. Под катом — немного сетевой археологии, Bleve, bbolt, gRPC, BM25, LambdaMART и рассказ о том, как задача «дайте локальный endpoint для AI-агентов» постепенно превратилась в реинкарнацию YaCy.

    habr.com/ru/articles/1060298/

    #yacy #поиск #selfhosted #ai #llm #tavily #яндекс #google

  15. Опять назвали медведем. Прогнал 21 телеграм-канал про нейросети через 6 ИИ и посчитал, кого они реально видят

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

    habr.com/ru/articles/1058902/

    #ии #поиск #алиса #выдача #выдача_поисковиков #искусственный_интеллект

  16. Как мы ускорили разметку видеопоиска в десятки раз и не потеряли качество: опыт внедрения VLM-асессора

    Современный поиск по видеоконтенту — это высоконагруженная система, требующая молниеносной реакции и безупречной релевантности. Сервис VK Видео оперирует колоссальной базой в 500 миллионов видеороликов и ежедневно обрабатывает около 10 миллионов запросов пользователей. При времени ответа в 0,5 секунды и нагрузке в 1800 RPS алгоритмам необходимо моментально находить именно тот контент, который ожидает увидеть зритель. Однако развитие алгоритмов ранжирования невозможно без качественных данных, на которых они обучаются. Традиционный подход с использованием ручной разметки асессорами долгое время оставался индустриальным стандартом, но на масштабах сотен тысяч видео он неизбежно становится бутылочным горлышком продуктовой разработки. Меня зовут Владислав Чернышев, я руководитель группы качества поиска по видео в AI VK. В этой статье подробно расскажу про путь перехода от классической ручной разметки к гибридной VLM-системе, разберу ошибки и инфраструктурные барьеры, которые пришлось преодолеть для кратного ускорения процессов подготовки обучающих датасетов и офлайн-оценки качества поиска. Переходим к VLV-системе

    habr.com/ru/companies/vk/artic

    #aivk #поиск #поиск_видео #видеоконтент #vk_видео #vlm #видеопоиск

  17. Как я стал туалетным сомелье

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

    habr.com/ru/articles/1054682/

    #карты #туалеты #минск #кабинка #уборные #туалет #поиск #карта

  18. Manticore Search 27.1.5: аутентификация, шардированные таблицы, диалоговый поиск и более быстрый векторный поиск Manticor...

    #полнотекстовый #поиск #векторный #поиск #аутентификация #семантический #поиск #sql #sharding

    Origin | Interest | Match
  19. RAG на кончиках пальцев Хочу поделиться своим опытом создания системы контекстного поиска. Плотно занялся LL...

    #rag #reranking #база #знаний #поиск #семантический #поиск #тюннинг

    Origin | Interest | Match
  20. RAG не только для вопросов и ответов: почему он естественно подходит для рекомендаций Retrieval-Augmented Generation (RAG) ча...

    #rag #nlp #рекомендательные #системы #machine #learning #llm #информационный #поиск #faiss #эмбеддинги

    Origin | Interest | Match
  21. Конволюция и деконволюция — работаем с сигналами под нефтяным соусом Разбираем такие инструменты анализа ...

    #деконволюция #свертка #сигналы #нефть #и #газ #гидродинамика #алгоритмы #поиск #решений #оптимизация

    Origin | Interest | Match
  22. Сократили друга Две недели назад я закрыл свой кейс с 15 собесами и вышел на работу в финтех-стартап. А через ...

    #поиск #работы #резюме #ATS #автоотклики #собеседование #hh.ru #сокращения #в #IT #карьера

    Origin | Interest | Match
  23. Ученые 7 часов сканировали межзвездный объект 3I/ATLAS в поисках сигналов от инопланетян Специалисты Институт...

    #Новости #поиск #инопланетян #космос

    Origin | Interest | Match
  24. Поиск IT-железа по 30+ дистрибьюторам сразу: как мы собрали 114k SKU

    Кейс, в котором мы поняли что закупщику не нужен «ещё один маркетплейс» — нужен инструмент, который за один запрос покажет, у кого из дистров есть нужный артикул, по какой цене и когда он будет на складе.

    habr.com/ru/articles/1046067/

    #B2B #закупки #дистрибуция #поиск #SaaS #парсинг #нормализация_данных #ITинфраструктура #REST_API #кейс

  25. Мечтали ли шумеры о нейросетях — от «живых поисковиков» до вездесущего ИИ

    В наши дни поиск информации стал почти скучен и почти тривиален. На 90% запросов и вовсе можно получить ответ от встроенной в поисковик нейросети, без необходимости прокликивать пару десятков ссылок. Разумеется, так было не всегда. Автору статьи, например, до сих пор непривычно пользоваться нейроподсказками. Прочитать текст по ссылке своими глазами — бесценно, если требуется на 100% точная информация. Поколение 35+ наверняка помнит, как интернет выглядел без Google и Яндекса. Кто-то был завсегдатаем школьной или районной библиотеки. Кому-то приходилось каталогизировать и размечать конспекты учебных лекций вручную. Казалось бы, это не слишком связанные вещи — где интернет-поиск и где допотопная картотека. Но без второго не было бы первого. В сегодняшней статье мы решили посмотреть, как люди учились индексировать, хранить, а самое главное, быстро находить информацию в доцифровую эпоху. Вместе мы пройдем весь путь от седой древности до вездесущего chatGPT. Присаживайтесь поудобнее, первая остановка — Месопотамия.

    habr.com/ru/companies/ispsyste

    #поисковые_системы #нейросети #индексация #поиск #данные #хранение #хранение_данных

  26. Мечтали ли шумеры о нейросетях — от «живых поисковиков» до вездесущего ИИ В наши дни поиск информации стал ...

    #поисковые #системы #нейросети #индексация #поиск #данные #хранение #хранение #данных

    Origin | Interest | Match
  27. Как и зачем мы сделали собственный OCR-бенчмарк Однажды нам понадобилось выбрать OCR-модель для RAG-пайплайна. К...

    #ocr #rag #LLM #deepseek #glm #markdown #векторный #поиск #data #science #computer

    Origin | Interest | Match
  28. Как мы ускорили расчёт факторов ранжирования в поиске Ozon с помощью динамической компиляции

    Всем привет! Меня зовут Петя Портнов, я работаю в Ozon ведущим разработчиком в команде среднего поиска — слоя, который ранжирует поисковую выдачу. Представьте, что вы вводите запрос в поисковую строку маркетплейса. За этим простым действием скрывается сложный поисковый пайплайн: миллионы товаров фильтруются, ранжируются и сортируются по релевантности. Но как именно система решает, что показать первым? В основе этого решения лежат вычисления, среди которых — сотни разнообразных формул, учитывающих цену, рейтинг, популярность, персонализацию и другие факторы. По мере развития системы таких формул становится всё больше, а сами они усложняются. В какой-то момент вычисления превращаются в узкое место: начинают потреблять значительную долю CPU, создают множество промежуточных объектов — и так для каждого поискового запроса. Возникает вопрос: как снизить стоимость таких вычислений в JVM? В этой статье я расскажу, что сделали мы, чтобы снизить нагрузку на систему: как заменили интерпретирующий движок формул на динамический компилятор, выполняющий построение эффективного байт-кода, отлично векторизующегося JIT-компилятором. Это текстовая версия доклада с Joker 2025 с дополнениями, которые не вошли в выступление или появились в проекте уже после конференции.

    habr.com/ru/companies/ozontech

    #java #поиск #оптимизация_производительности #компиляция #байткод #jvm #ozon_tech

  29. Хакатон Samsung IT Academy Hack 2026: как студенты оптимизировали поиск в корпоративном мессенджере

    Поиск — штука настолько привычная, что её редко рассматривают как отдельную инженерную задачу. На деле это связка из четырёх частей: парсинг и нормализация исходных данных, индексация, обработка пользовательского запроса и ранжирование результатов. Каждая из них живёт по своим правилам и ломается по своим причинам. Сложно представить более прикладную область, поэтому на хакатоне IT Academy Hack 2026 от IT Академии Samsung Innovation Campus в этом году, мы решили попросить студентов предложить варианты улучшения поиска по сообщениям в контуре корпоративного мессенджера. Кстати, VK Tech стал индустриальным партнером конкурса уже во второй раз — предоставил инфраструктуру для студентов, и стал одним из постановщиков задач. Меня зовут Сергей Харламов, я руковожу Исследовательской лабораторией VK Tech . В этой статье расскажу об актуальных проблемах оптимизации поиска, а также о задаче и подходах, которые можно было применить для ее решения.

    habr.com/ru/companies/vktech/a

    #хакатон #поиск #информационный_поиск #elasticsearch #qdrant #embeddings #векторный_поиск #ранжирование #vk_workspace #vk_tech

  30. Прокачиваем локальный поиск на Dart и Flutter

    Hola, Amigos! На связи Павел Гершевич, Mobile Team Lead агентства продуктовой разработки Amiga и соавтор книги “Основы Flutter”. Иногда нужно реализовать поиск по данным без участия бэкенда. Самый простой вариант — обычное вхождение строки — не прощает опечаток. Одна лишняя буква, и поиск выдает пустоту. В статье разберем, как усовершенствовать этот процесс: научим поиск обрабатывать ошибки и сортировать результаты по степени совпадения.

    habr.com/ru/articles/1031212/

    #flutter #dart #dartlang #алгоритмы #нечеткий_поиск #поиск

  31. Русская рулетка с поиском: почему каждый десятый ответ в AI-выдаче — ложь

    ИИ все активнее в повседневных задачах, например стал частью поиска. Google и другие системы генерируют сверху LLM-сводку. Не надо тратить время на выбор ссылок и анализ информации — получаешь всё на блюдечке, даже с понятной версткой. Но все мы знаем, что ИИ выдает несуществующие факты, путает источники и делает некорректные выводы. Насколько часты эти ошибки? И критичны ли? Рассмотрю, откуда они в поиске, на примере Google — только потому, что под руку попалось исследование его точности. Так-то поисковые ИИ-агенты чудят примерно одинаково.

    habr.com/ru/companies/ru_mts/a

    #ошибки #ошибки_ии #поиск #google

  32. Наглядный пример, зачем нужны агенты

    Расскажу историю длиною в полгода, на которой прекрасно прочувствовал все прелести современных инструментов и способов эксплуатации llm. Идея до жути простая и наверняка встречалась или приходила в голову очень многим, кто начинал задумываться об использовании llm api или после знакомства с rag. В августе 2025 года папа предложил мне создать хороший поисковик-анализатор новостей: ты даешь ему список источников и пожелания того, что хочешь увидеть в ответе, он тебе присылает в выбранный интервал сводку с источниками и отвечает на твои вопросы. Казалось бы, классическая задача чтобы показать всем удачное применение rag, словить аплодисменты и разойтись. Так показалось и мне, и я буквально за 1-2 месяца работая в свободное время собрал вполне достойный прототип. Он умел хорошо искать семантически, просить llm сформировать ответ на основе найденных постов и даже помогал их открывать. В мыслях салюты, шампанское и ai единороги. Но реальность Довольно быстро на самотестировании я нашел два серьезных упущения: первое - сложный запрос для такой системы оставался недопустимой роскошью: попытка найти “причины шатдауна правительства США” в лучшем случае приводила меня к заголовкам про Трампа и что-то там про переговоры, а иногда и вовсе такого рода запросы не давали никакой выборки по базе; второй серьезной проблемой стало абсолютное непонимание предметной области, если того же Трампа вектора в базе еще ставят в один ряд с Америкой и политикой, то вот ЦБ РФ может запросто восприниматься как Россия или вообще непонятная модели сущность, а может вообще трактоваться как два отдельных слова. В целом обе эти неприятности подсвечивают один известный изъян всей системы - слишком большое доверие к семантической схожести и вытекающие из нее проблемы: размытие смысла на длинных запросах, непредсказуемое поведение имен собственных, поиск связей по частотному сходству, а не смыслу.

    habr.com/ru/articles/1027998/

    #agent #агент #rag #поиск #память #llm #ai #openclaw

  33. Как я решил задачу с навязчивым Yahoo в FVD Speed Dial с помощью ИИ

    Я давно пользуюсь FVD Speed Dial как основной экспресс‑панелью. Однажды после перенастройки сети (VPN, прокси, DNS) заметил неприятный эффект: любое слово, набранное в строке поиска новой вкладки, всегда улетало в Yahoo. Никаких настроек выбора поисковика в интерфейсе расширения не было — только встроенное поле, жёстко завязанное на внутреннюю логику FVD. Системный поисковик Chrome я менял, но это никак не влияло на поведение FVD Speed Dial: расширение упрямо перенаправляло все запросы в Yahoo.

    habr.com/ru/articles/1020180/

    #google_chrome #speed_dial_FVD #поиск

  34. Гибридный поиск по коду в GitLab: как я ускорил поиск по 100+ GitLab-проектам с часов до минут

    Когда проектов в GitLab становится много, довольно быстро появляется одна и та же задача: найти, где используется конкретный API, URL, env-переменная или конфигурационный параметр. Пока репозиториев мало, всё просто: открыл поиск, ввел строку, получил результат. Но когда проектов уже больше сотни, а нужные вхождения лежат не только в коде, но и в YAML-конфигах, Helm-чартах, .env и JSON-файлах, жизнь становится менее романтичной. Первый лобовой вариант — просто скачать все проекты локально и искать по ним через grep , ripgrep или IDE. Работает, но тащить 100+ репозиториев на локальную машину ради одной проверки — идея так себе. Ноутбук, скорее всего, энтузиазма не разделит. Мне хотелось искать прямо поверх GitLab, без локального зеркала всей группы репозиториев. Я начал с просмотра готовых вариантов, а в итоге пришёл к своему гибридному краулеру: код ищется через GitLab API, а конфиги добираются отдельным глубоким обходом файлов. В результате поиск по 100+ проектам сократился с часов до нескольких минут.

    habr.com/ru/articles/1019332/

    #краулер #поиск #проект #гитлаб

  35. Убейте это немедленно: делаем худший поиск на рынке

    За последние шесть лет я прошёл через дюжину проектов, связанных с поиском. Роднило их немногое, кроме того, что практически в каждом я обнаруживал одни и те же ошибки. Не сговариваясь, разные команды спотыкались в одних и тех же местах. Эта статья — каталог самых живучих ошибок при проектировании поиска, кочующих из проекта в проект. Примеры построены на ElasticSearch, но большинство пунктов применимы к любому поисковому стеку. Статья будет полезна как тем, кто еще не делал поисковых систем и столкнулся с проблемой “чистого листа”, так и тем, кто уже имеет какой-то поиск и нутром чует неладное, но не может понять, что не так. А чтобы было интереснее и веселее, разбирать ошибки мы будем в формате вредных советов, следование которым гарантированно испортит UX ваших пользователей и сделает поиск по вашему ресурсу бесполезным, ненадежным и ужасно дорогим. Поехали!

    habr.com/ru/articles/1017142/

    #поиск #elasticsearch #оптимизация_поиска #поиск_в_интернетмагазине #полнотекстовый_поиск

  36. RAG вместо GPT: как мы сделали внутреннего ассистента для корпоративных данных

    В больших компаниях поиск почти всегда «работает». Но это не значит, что сотрудники быстро находят нужное: нередко они тратят часы на попытку вспомнить формулировку, место и контекст. Мы построили внутренний RAG-ассистент в закрытом контуре: изоляция данных, контроль доступа, бенчмарки качества и долгая работа с вендором. В статье — архитектура, переговоры с вендором, ошибки, компромиссы и выводы для тех, кто думает о корпоративном ИИ всерьёз. Конечно, до внедрения RAG компания нормально работала — это не история про «без ИИ ничего не функционирует». Это история про оптимизацию: сократить время на рутинный поиск и навигацию в массивах информации.

    habr.com/ru/companies/croc/art

    #rag #корпоративная_архитектура #поиск #llm

  37. Тайны рекламного аукциона в Ozon и как мы приручали VCG

    Привет! Меня зовут Дмитрий, я ведущий разработчик в команде рекламного рантайма. Наша команда, как вы уже могли догадаться, занимается разработкой аукционов в поисковой рекламе Ozon. В этой статье я хочу познакомить вас с механикой аукционов и рассказать, как мы делаем это в Ozon. Сначала мы разберёмся, что такое рекламный аукцион, что он имеет общего с аукционом в обычном понимании и как используется в контексте поисковой рекламы. А ещё подробно разберём аукцион типа VCG (аукцион Викри — Кларка — Гровса), вместе выведем формулы для него и посмотрим, какие результаты мы получили на практике.

    habr.com/ru/companies/ozontech

    #ozon #поисковая_реклама #рекламный_аукцион #ecommerce #ozon_tech #поиск

  38. После опроса пользователей DuckDuckGo на предмет "поиск с AI, или без него" из поисковика разумеется не исчез ИИ агент, НО был создан отдельный домен noai.duckduckgo.com где AI исключён, то же касается сгенерированных изображений в результате поискового запроса.

    Что ж, это разумное решение, только о нём мало кто знает.

    #ai #ии #поиск #search #duckduckgo

  39. Ты не потерял путь. Ты его строишь.

    Если ты не знаешь, куда идти — это не ошибка. Это начало. В детстве тебе рисовали карту: “учись”, “работай”, “копи”. Но эта карта не для тебя. Ты пришёл строить свою. И с нуля — это не страшно. Это честно. На белом листе можно написать правду. Не бойся не знать. Бойся жить чужим.

    #путь #поиск #жизнь #честность #самость
    → t.me/tribute/app?startapp=srfZ
    P.S. Made by a madman — Kirill Bereznev

  40. Ты не потерял путь. Ты его строишь.

    Если ты не знаешь, куда идти — это не ошибка. Это начало. В детстве тебе рисовали карту: “учись”, “работай”, “копи”. Но эта карта не для тебя. Ты пришёл строить свою. И с нуля — это не страшно. Это честно. На белом листе можно написать правду. Не бойся не знать. Бойся жить чужим.

    #путь #поиск #жизнь #честность #самость
    → t.me/tribute/app?startapp=srfZ
    P.S. Made by a madman — Kirill Bereznev

  41. Я больше не бегу за ответами
    Раньше я искал. Сейчас — слушаю. Не внешнее. Внутреннее. Ответы — внутри. Но чтобы их услышать, нужно замолчать.

    #внутримир #тишина #поиск #самость
    → t.me/tribute/app?startapp=srfZ
    P.S. Made by a madman — Kirill Bereznev
    t.me/tribute/app?startapp=srfZ

  42. Я больше не “ищу себя”. Я создаю себя.
    Поиск — это бег по чужим следам. Создание — это честный выбор.

    Я пробовал “найти”. Перепробовал образы, роли, маски. Пока не понял: никто не скажет, кто я. Кроме меня. И я начал — рисовать, собирать, выстраивать. Не искать. А творить.

    #самость #путь #поиск #создание #я
    → t.me/tribute/app?startapp=srfZ
    P.S. Made by a madman — Kirill Bereznev
    t.me/tribute/app?startapp=srfZ

  43. Я не в поиске. Я в пути.
    Поиск — это иллюзия. Путь — это практика.

    Я не жду, что найду “то самое”. Я просто иду. Каждый день. Через ясность, паузы, боль. Это не романтика. Это дорожная карта. И в этом — устойчивость.

    #путь #поиск #движение #вектор #смысл
    → t.me/tribute/app?startapp=srfZ
    P.S. Made by a madman — Kirill Bereznev
    t.me/tribute/app?startapp=srfZ

  44. Ты не потерял путь. Ты его строишь.

    Если ты не знаешь, куда идти — это не ошибка. Это начало. В детстве тебе рисовали карту: “учись”, “работай”, “копи”. Но эта карта не для тебя. Ты пришёл строить свою. И с нуля — это не страшно. Это честно. На белом листе можно написать правду. Не бойся не знать. Бойся жить чужим.

    #путь #поиск #жизнь #честность #самость
    → t.me/tribute/app?startapp=srfZ
    P.S. Made by a madman — Kirill Bereznev

  45. #Поиск
    У меня Gorenje.

    Почему при поиске по конкретному слову на первом месте товар, который его вообще никак не содержит?

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

    P.S: сейчас на работе сам пилю поиск, как-то балансируя между скоростью и корректностью работы, но упаси меня господь творить такое говно.

  46. Федерация #Mastodon базируется на открытом протоколе #ActivityPub, что позволяет независимым серверам (нодам) взаимодействовать друг с другом.

    bastyon.com/kolibristudio?s=6e

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

    #Связанность в Mastodon:
    Локальная связь:
    Участники одной ноды взаимодействуют напрямую.
    Общий временной поток доступен только пользователям этой ноды.
    Федеративная связь:
    Нода "подписывается" на обновления от других нод.
    Пользователи могут подписываться на учетные записи с других нод и видеть их публикации в своём фиде.
    Децентрализованная структура:
    Отсутствие единого центра управления.
    Каждая нода автономна, что делает сеть устойчивой к цензуре и сбоям.
    Кому это нужно?
    Индивидуальные пользователи:
    Тем, кто ценит приватность, контроль над своими данными и свободу выражения.
    Для тех, кто разочаровался в централизованных платформах (Twitter, Facebook).
    Организации:
    Ноды могут использоваться как внутренние или внешние коммуникационные платформы.
    Бренды и сообщества создают свои пространства для целевой аудитории.
    Активисты и #СМИ:
    Децентрализация позволяет избегать блокировок и цензуры.
    Возможность распространять информацию независимо от централизованных платформ.
    Разработчики и энтузиасты открытого ПО:
    Протокол ActivityPub позволяет экспериментировать с новыми подходами к социальным сетям.
    Возможность интеграции с другими платформами на основе ActivityPub.
    Плюсы и минусы
    Плюсы:
    Контроль над данными.
    Отсутствие рекламы и #алгоритмической ленты.
    Возможность выбирать "идеологически близкую" ноду.
    Минусы:
    Требуется разбираться в устройстве федерации.
    Возможна изоляция при закрытой политике некоторых нод.
    Сложности для новых пользователей.
    Mastodon привлекателен для тех, кто стремится к свободе и децентрализации, но остаётся нишевым продуктом из-за сравнительно высокой кривой обучения и отсутствия массового охвата.
    #Проблематика федерации Mastodon
    Фрагментация и изоляция:
    Разные ноды могут придерживаться различных идеологических и модерационных принципов. Это создаёт барьеры в коммуникации между пользователями. Например, если одна нода блокирует другую, пользователи из этих двух нод не могут взаимодействовать.
    Иногда пользователи испытывают сложности с выбором "правильной" ноды, особенно если она слишком узкоспециализированная или имеет строгие правила.
    Управление и модерация:
    Ноды управляются администраторами, чьи решения могут быть субъективными. Это приводит к спорам о справедливости модерации, удалении контента или блокировке пользователей.
    Администраторы несут большую ответственность, включая техническое обслуживание сервера, модерацию и защиту данных. Это может быть избыточной #нагрузкой для небольших команд или отдельных энтузиастов.
    Сложности #масштабирования:
    Рост популярности Mastodon увеличивает нагрузку на популярные ноды. Это требует дополнительной инфраструктуры, что может быть дорого.
    Многие ноды зависят от #пожертвований или энтузиазма #администраторов, что не всегда устойчиво в долгосрочной перспективе.
    Технические барьеры:
    Новичкам бывает трудно разобраться с концепцией федерации, выбором ноды и настройкой аккаунта.
    Интерфейс некоторых клиентов менее интуитивен, чем у популярных централизованных платформ.
    Проблемы с децентрализацией:
    Хотя децентрализация защищает от цензуры, она же делает невозможным централизованное регулирование. Это позволяет некоторым нодам распространять незаконный или токсичный контент.
    Отсутствие общего авторитетного центра затрудняет координацию работы между нодами и защиту пользователей от злоупотреблений.
    Низкая узнаваемость и адаптация:
    Несмотря на активную нишевую аудиторию, Mastodon остаётся малоизвестным для широкой публики. Это делает сложным массовое привлечение пользователей.
    Пользователи привыкли к централизованным платформам и алгоритмической ленте, что снижает интерес к федеративной модели.
    Отсутствие #совместимости с привычными соцсетями:
    Mastodon сложно интегрируется с централизованными платформами, такими как Facebook, Instagram или Twitter.
    Федерация позволяет интеграцию с другими платформами на основе ActivityPub, но их тоже не так много.
    Выводы
    #Федерация Mastodon сталкивается с вызовами, характерными для децентрализованных систем: баланс между свободой и ответственностью, сложностью управления и масштабирования. Для успешного развития необходимо:
    Упрощение интерфейсов и повышение осведомлённости пользователей.
    Улучшение инструментов для модерации и взаимодействия нод.
    Стабильная #модель #финансирования для #администраторов.
    Тем не менее, Mastodon остаётся перспективным решением для тех, кто ценит #свободу, #открытые #стандарты и #децентрализацию.
    Потенциальные улучшения для Mastodon
    1. Улучшение пользовательского опыта (UX/UI):
    Упрощение регистрации:
    Сделать процесс выбора ноды более интуитивным. Например, добавить рекомендации на основе предпочтений пользователя (#тематика, язык, активность).
    Объединённый #поиск:
    Улучшить глобальный поиск, чтобы пользователи могли легче находить аккаунты и публикации на других нодах.
    Интуитивный интерфейс:
    Разработать более дружелюбный интерфейс для мобильных и веб-клиентов, чтобы конкурировать с привычными платформами (Twitter, Facebook).
    2. Укрепление федеративной связности:
    Лучшие инструменты модерации:
    Ввести стандартизированные механизмы для управления федерацией между нодами, чтобы избегать конфликтов и изоляции.
    Механизмы разрешения конфликтов:
    Разработать общие рекомендации или протоколы для решения споров между нодами.
    3. Образование и популяризация:
    Обучающие материалы:
    Создать простые гайды и видео для новых пользователей о том, как работает федерация и как пользоваться Mastodon.
    Партнёрства:
    Продвигать Mastodon через #коллаборации с известными брендами, активистами или открытыми проектами.
    Маркетинг:
    Акцентировать внимание на преимуществах Mastodon — приватность, децентрализация, отсутствие рекламы.
    4. Технические улучшения:
    Оптимизация производительности:
    Разработать решения для масштабирования крупных нод, чтобы они справлялись с нагрузкой при росте числа пользователей.
    Интеграция с другими протоколами:
    Расширить совместимость с другими федеративными платформами, такими как #Matrix, Pixelfed, PeerTube, или даже централизованными сервисами через API.
    Фильтрация контента:
    Улучшить возможности пользователей по фильтрации нежелательного контента, используя гибкие настройки.
    5. Финансовая устойчивость:
    Поддержка администраторов:
    Разработать универсальные инструменты для сбора пожертвований или других видов монетизации (например, премиум-функции).
    #Фонды и гранты:
    Создать фонд поддержки для администраторов небольших нод, чтобы те могли оплачивать хостинг и развивать свои сервера.
    6. Сообщество и взаимодействие:
    Поощрение разработчиков:
    Поддерживать разработчиков, которые создают новые клиенты и плагины для Mastodon, через гранты или краудфандинг.
    Динамика общения:
    Ввести дополнительные инструменты для взаимодействия, такие как голосования, опросы, или системы обратной связи между пользователями.
    7. Этика и стандарты:
    Прозрачность модерации:
    Рекомендовать нодам вести прозрачные отчёты о модерации и блокировках.
    Универсальные кодексы поведения:
    Предложить шаблоны для создания правил поведения на нодах, чтобы минимизировать конфликты.
    Примерный план действий
    Создать "информационный хаб" для пользователей и администраторов.
    Активно привлекать разработчиков для внедрения новых функций.
    Искать стратегические партнёрства для популяризации платформы.
    Поддерживать ключевых энтузиастов и администраторов для сохранения устойчивости.
    Ожидаемый результат
    Эти улучшения могут сделать Mastodon более доступным и привлекательным для широкой аудитории, не утрачивая духа децентрализации и свободы, которые являются ключевыми преимуществами платформы.
    Термины:
    Федерация — модель распределённой сети, где независимые узлы (сервера) могут взаимодействовать между собой через единый протокол.
    ActivityPub — открытый стандарт для федеративных социальных сетей, обеспечивающий взаимодействие между платформами.
    Нода — отдельный сервер в федеративной сети, выполняющий роль автономного узла.
    Фрагментация — изоляция узлов или пользователей внутри федеративной сети из-за разногласий в политике или блокировок.
    Модерация — процесс управления контентом и пользователями на платформе, включающий фильтрацию, блокировку и установление правил.
    Децентрализация — архитектура сети, где управление распределено между независимыми участниками.
    Библиография:
    ActivityPub W3C Recommendation — Официальная документация протокола ActivityPub: W3C.org
    #Gargron (Eugen #Rochko), Mastodon Documentation — Руководство и технические детали Mastodon: Joinmastodon.org
    Тони #Баубек, Децентрализованные социальные сети: будущее коммуникаций — Анализ перспектив федеративных сетей.
    Фрейзер #Симон, Challenges in Decentralized Social Media — Статья о проблемах масштабирования и модерации.
    Материалы проекта Fediverse — История и развитие федеративных сетей: Fediverse.party

    richamster.com/auth/register?r

    XMR
    8A13jXRRgqh4iDMMrV1HpyWjy5ojVHaEbBPAsxd3NXJPBdaMCsZ3AKP4VQZoNqTUGRhPH21afxzJMXhB525MWE8XUtm5Dyr

    Самая приватная пара на планете Земля:
    Richamster
    richamster.com/trade/KRB_XMR

    DASH

    XxBLVTZFK9xocY8BAXKorzykF51BmaJKV4

    PKOIN

    PPuoSzXpSnY1Q4w1MLeVdLcbaUpVDCwpBp

    Хэштеги:
    #Mastodon #ActivityPub #Федерация #Децентрализация #ОткрытыеПротоколы #СоциальныеСети #Fediverse #Приватность #СвободаСлова #Модерация

  47. #Google #Yandex #поиск #music #митол #torrent
    Вот вы Гугл хуесосите, зато Утку пиарите. А я вот попробовал найти торрент отечественной команды. У Яши на 2-й странице, у Гугла — первая ссылка в выдаче. Утка про такое не в курсе.

  48. #Mastodon #лайфхак
    Если на вашем инстансе не прикручен полнотекстовый #поиск, а хочется (хотя бы по своим постам) — подпишитесь на самого себя по #RSS:
    https://instance_name/users/user_name.rss

    С этого момента все новые посты будут сохраняться в RSS-читалке (я пользуюсь Inoreader ) и индексироваться.

    Это для начала. А дальше — можно в автоматизацию (ifttt.com, zapier.com) или еще что-нибудь интересное придумать.

  49. Конкурс: "А ну ка отыщи"

    *На этом фото определённо есть крысович.*

    #конкурс #поиск #osint

  50. На #TheDroth добавлен новый сервис — SearxNG: https://search.thedroth.rocks

    #поиск

  51. #web #закладки #поиск #lytdybr

    Когда уже я приучу себя при поиске СНАЧАЛА смотреть в закладках на Raindrop.io, а уже во вторую очередь шерстить Гугол?..

  52. @TrueSnowBuddy

    Неочевидный факт: в #Mastodon ЕСТЬ #поиск по текстам постов. Но ищет ТОЛЬКО по собственным постам/ответам либо среди избранного/закладок.

    Следствие: не ленитесь ставить звездочки/делать закладки в первую очередь для собственного удобства -и жмите колокольчик чтобы не пропустить- 😄

Share on Mastodon

Enter the server where you have an account.