Операторы, движки и время: механика запроса

Предыдущая глава закончилась на том, что у вас появился термин. Эта — про то, как донести его до индекса без потерь и в каком именно индексе искать.

Тезис главы простой и непопулярный: общий веб-поиск — не главный инструмент инженера, а инструмент последней очереди. Он нужен, когда вы не знаете, где искать. Как только вы знаете, есть индекс лучше: документация проекта, поиск по коду, трекер, архив рассылки, база уязвимостей. Общий поиск хуже них по всем параметрам, кроме одного — он работает, когда вы ещё ничего не знаете.

Анатомия запроса

Полезный запрос состоит из четырёх слотов, и три из них люди обычно не заполняют.

• Ядро — существительные, называющие механизм. Два-четыре слова. Это то, что вы добывали в первой главе.
• Экосистема — имя языка, продукта, протокола. Один токен. Отсекает омонимию.
• Площадка — где искать: site:, конкретный трекер, конкретный индекс.
• Время — к какому периоду или к какой версии относится вопрос.

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

Что из синтаксиса действительно работает

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

Чего больше нет и на что не стоит рассчитывать: оператор + (убран в 2011), тильда для синонимов, link: для обратных ссылок, и — важное недавнее изменение — cache:. Google убрал кэш из выдачи и отключил оператор в 2024 году, о чём объявили публично. Практическое следствие: если страница исчезла или изменилась, единственный доступный вам архив — Wayback Machine и archive.today.

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

Почему длинный естественный запрос работает хуже

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

1. Ваш редкий термин может быть заменён на частый синоним. Вы искали idempotency key, движок подмешал «уникальный идентификатор запроса» и вернул общие статьи.
2. Лишние слова разбавляют сигнал. «Почему у меня в проекте на питоне» — семь токенов, которые встречаются везде и ни на что не указывают.
3. Вопросительная форма притягивает контент-фермы. Страницы, оптимизированные под вопросы, — это и есть жанр пересказа.

Отсюда правило: существительные, а не предложения. Три-пять слов, из которых каждое — термин. Если очень нужна точность, обрамляйте кавычками ту часть, которая должна найтись дословно.

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

Воронка сужения

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

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

Ограничение по площадке

site: — оператор, который чаще всего окупается, потому что встроенный поиск на сайтах в среднем плохой. Типичные применения:

site:docs.python.org asyncio "cancel scope"
site:github.com "TimeoutError" repo-name
site:kernel.org io_uring "IORING_SETUP_SQPOLL"
site:postgresql.org "synchronous_commit"
-site:medium.com -site:dev.to kubernetes taints tolerations

Последняя строка — приём исключения. У любой темы есть набор доменов, которые производят пересказы; исключив три-четыре из них, вы заметно очищаете выдачу. Список у каждого свой, и его стоит один раз составить под свою область.

Отдельный трюк для сайтов с плохим встроенным поиском: ищите не по содержанию, а по структуре URL. site:example.com inurl:changelog, site:example.com inurl:/api/v2/ — так находится то, что поиск по тексту не находит, потому что страница состоит из таблицы.

Ограничение по времени

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

Операторы before: и after: принимают дату: after:2024-01-01. Работают по дате, которую движок приписал документу, а она бывает неверной, — но даже приблизительное ограничение отсекает основную массу устаревших ответов.

Инструменты интерфейса. В крупных движках есть фильтр по периоду (последний год, свой диапазон). Он делает то же самое, но нагляднее.

Ограничение версией вместо даты. Часто лучше, чем дата: "3.12" в запросе про Python, "v18" про Node, номер релиза в запросе про базу. Версия — более точный маркер, чем время публикации, потому что документ мог быть написан позже, но про старое.

Обратное ограничение. Иногда нужно именно старое: вы работаете с легаси, и вам нужен ответ про версию, которой уже нет в документации. Тогда before:2018 плюс Wayback Machine по адресу старой документации. У большинства крупных проектов старые версии доков доступны и напрямую — по URL с номером версии.

Движки: чем они отличаются и когда менять

Разные движки имеют разные индексы и разную политику ранжирования. Менять движок стоит не из принципа, а когда вы упёрлись.

Bangs заслуживают отдельного упоминания. В DuckDuckGo (и в некоторых других) префикс восклицательного знака отправляет запрос сразу в поиск конкретного сайта: !so, !mdn, !gh, !w, !npm, !crates, !aw (ArchWiki), !py. Это экономит не столько секунды, сколько шаг «получить выдачу общего поиска и не поверить ей».

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

Специализированные индексы

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

Подробнее по нескольким, где есть неочевидный синтаксис.

Stack Overflow и сеть Stack Exchange. Поиск поддерживает свой язык:

[postgresql] [performance] is:question score:5 answers:1..
[rust] "borrow checker" closed:no
user:12345 [kubernetes]
inquestion:1234567 lifetime

Плюс есть Stack Exchange Data Explorer — публичная SQL-консоль по дампу базы. Через неё отвечают на вопросы, которые обычный поиск не берёт: «какие теги растут», «сколько вопросов по теме осталось без ответа», «когда ответ последний раз редактировали». Это же способ проверять утверждения о состоянии площадки самому, а не по чужой статье.

GitHub: issues и pull requests. Отдельный язык запросов, который экономит часы:

repo:owner/name is:issue "connection reset" sort:reactions-+1-desc
org:kubernetes is:pr merged:>2024-06-01 label:kind/bug
is:issue state:closed reason:completed "deprecated" in:title
repo:owner/name is:issue involves:username

Приём, который стоит запомнить: искать среди закрытых issue. Ответ на ваш вопрос чаще всего лежит в закрытой задаче с комментарием мейнтейнера «это ожидаемое поведение, потому что…». Открытые issue — это список нерешённого; закрытые — это база знаний.

Списки рассылки. Для проектов, которые старше веба в его нынешнем виде, основной архив мысли — рассылка. Ядро Linux: lore.kernel.org с поиском по всем спискам сразу. Многие проекты используют public-inbox или Mailman-архивы. Здесь лежат обоснования решений, которых нет нигде больше.

Уязвимости и версии. NVD, GitHub Advisory Database, OSV. Последняя особенно удобна, потому что отвечает на инженерный вопрос напрямую: «затронута ли конкретная версия конкретного пакета». Про сам процесс — глава про цепочку поставок.

Обсуждения как источник опыта. Поиск по Hacker News через hn.algolia.com даёт то, чего нет в документации: комментарии людей, которые эксплуатировали инструмент в проде и рассказывают, что сломалось. Это низкокачественный источник по форме и высококачественный по содержанию — читать надо с поправкой на то, что каждый пишет про свой контекст.

Как читать выдачу за десять секунд

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

Что даёт положительный сигнал:

• домен документации самого проекта (docs.*, *.readthedocs.io, pkg.go.dev, docs.rs);
• github.com с путём в /issues/ или /pull/ — это обсуждение, а не пересказ;
• домен стандарта: rfc-editor.org, w3.org, pubs.opengroup.org;
• инженерный блог компании, которая эксплуатирует эту технологию в большом объёме;
• заголовок, содержащий ваш точный термин, а не его пересказ обычными словами.

Что даёт отрицательный сигнал:

• заголовок в форме вопроса, дословно повторяющий ваш запрос, — типовой признак страницы, построенной под запрос;
• «Топ-10», «Полное руководство», «Всё, что нужно знать» в заголовке технического запроса;
• один и тот же текст в трёх разных доменах подряд — сеть перепечаток;
• домены-агрегаторы, которые перепечатывают ответы с Q&A-площадок с рекламой;
• отсутствие даты в сниппете при вопросе, где версия имеет значение.

Правило: если в первой десятке нет ни одного положительного сигнала, надо менять запрос, а не открывать ссылки. Оценка занимает секунды, открытие десяти вкладок — четверть часа.

Что делать, когда ничего не находится

Семь тактик по возрастанию затрат.

1. Снять кавычки или, наоборот, поставить. Слишком точный запрос находит ноль; слишком расплывчатый — всё.
2. Убрать одно слово. Обычно лишним оказывается то, которое кажется самым важным, потому что оно ваше, а не общепринятое.
3. Сменить термин на синоним. У большинства механизмов два-три названия: backpressure и flow control, circuit breaker и fail fast, debounce и rate limit.
4. Сменить площадку. Если веб пуст, попробуйте трекер, поиск по коду и архив рассылки. Для новых или нишевых тем ответ часто существует только там.
5. Сменить язык. Ответ мог быть написан по-английски, по-китайски или по-японски — см. главу 10.
6. Проверить, что термин существует. Пустая выдача по «общепринятому термину» — сильный признак того, что термина нет; вероятно, его вам придумали.
7. Принять, что ответа в вебе нет. Это нормальный исход. Дальше — исходники, эксперимент или вопрос людям.

Локально: запросы, которые не должны уходить в интернет

Часть вопросов быстрее закрывается без сети, и это стоит довести до рефлекса.

# что вообще умеет утилита и какие есть флаги
somecmd --help | less
man 2 open                 # раздел 2 — системные вызовы, 3 — библиотечные функции

# поиск по всем man-страницам по ключевому слову
man -K "O_DIRECT"
apropos socket

# документация языка, установленная вместе с ним
go doc net/http.Client
python -m pydoc socket.socket
perldoc -f sprintf

# поиск по исходникам зависимостей, которые уже лежат у вас на диске
rg --type py "def connect" .venv/lib/
rg -n "IORING_SETUP" ~/src/linux/include/

# поиск по истории вашего же проекта
git grep -n "retry" -- '*.go'
git log -S "MaxIdleConns" --oneline

Три причины, почему это стоит делать первым:

1. Локальные исходники — это ровно та версия, которая у вас установлена. Никакой проблемы датировки.
2. Быстрее. rg по дереву зависимостей отрабатывает за доли секунды.
3. Находит то, чего нет в документации. Недокументированные флаги, внутренние константы, комментарии авторов.

Для офлайнового чтения документации многих языков сразу есть DevDocs (работает офлайн после кэширования), Dash и Zeal. Один поиск по объединённому индексу тридцати доков — часто самый быстрый путь к сигнатуре.

Приёмы, которые стоит знать

Поиск по уникальному идентификатору. Код ошибки вендора, OID, номер CVE, magic-байты формата, hex-сигнатура, номер строки в стандарте. Такие токены дают почти стерильную выдачу, потому что случайно не встречаются нигде.

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

Поиск по имени файла. filename:Dockerfile, filename:.golangci.yml в поиске по коду находят реальные конфигурации, а не примеры из документации. Подробнее — следующая глава.

Проверка, что термин существует. Прежде чем строить поиск вокруг слова, которое вам подсказали, убедитесь, что оно встречается в первичных источниках: в документации, в исходниках, в спецификации. Слово, живущее только в пересказах, — плохая опора.

Смена регистра запроса с «как сделать» на «почему не работает». Иногда прямой запрос не находит, а запрос про типичную ошибку находит сразу, потому что люди пишут в интернет, когда у них не получилось, а не когда получилось.

Push вместо pull: как искать меньше

Часть поисков возникает потому, что вы пропустили изменение. Их можно убрать заранее.

• Подписка на релизы. На GitHub — Watch → Custom → Releases для критичных зависимостей. Приходит уведомление о новой версии с changelog.
• RSS на changelog и блоги. Многие проекты отдают релизы как ленту (в том числе GitHub: /releases.atom у репозитория). Один агрегатор на два десятка лент — это несколько минут в неделю и отсутствие сюрпризов.
• Оповещения по запросу. Google Alerts и аналоги для узкой темы: имя редкой библиотеки, название вашего продукта, специфический термин.
• Подписка на нужный тег в трекере. В GitHub — подписка на конкретную issue, а не на весь репозиторий; иначе шум.

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

Типичные ошибки

1. Идти в общий веб-поиск, когда известно, где ответ. Документация, трекер и код — лучшие индексы по своим темам.
2. Писать предложениями. Движок не читает вашу мысль, он матчит токены.
3. Не ставить кавычки на строку из исходников. Без кавычек она распадётся.
4. Игнорировать время. Ответ без датировки — это ответ про неизвестную версию.
5. Открывать вкладки вместо переформулировки. Если в первой десятке нет подходящих доменов, надо менять запрос, а не читать.
6. Считать выдачу объективной. Она зависит от региона, языка и истории. Для спора нужен воспроизводимый источник, а не «первое в гугле».
7. Не знать про существование специализированных индексов. Это единственная ошибка из списка, которую нельзя исправить умением: нужен именно список, и его стоит собрать под свою область.

Мини-итог

• Запрос состоит из четырёх слотов: ядро-термин, экосистема, площадка, время. Обычно заполняют первый.
• Существительные работают лучше предложений: движок переписывает естественный язык и разбавляет редкий термин частым.
• Устойчиво работают кавычки, минус, site:, filetype:, intitle:/inurl:, before:/after:. Часть исторических операторов исчезла, включая cache: — архивы веба стали обязательным инструментом.
• Сужайте воронкой, оценивая выдачу по доменам за секунды, а не открывая вкладки.
• Ограничение по версии часто точнее ограничения по дате.
• Общий поиск — инструмент, когда неизвестно, где искать. Как только известно, есть индекс лучше: документация, код, трекер, рассылка, база уязвимостей, архив.
• Часть запросов вообще не должна уходить в сеть: man, --help, go doc, rg по зависимостям и git log -S по своей истории отвечают быстрее и про вашу версию.
• Подписки на релизы и changelog убирают целый класс срочных поисков.

Источники

• Google Search, справка по операторам и уточнению запросов — support.google.com/websearch/answer/2466433.
• Stack Exchange, синтаксис поиска — stackoverflow.com/help/searching; публичная SQL-консоль по дампу — data.stackexchange.com.
• GitHub Docs, поиск по issues и pull requests — docs.github.com/search-github/searching-on-github.
• Архив списков рассылки ядра Linux с полнотекстовым поиском — lore.kernel.org.
• OSV: база уязвимостей, ориентированная на версии пакетов — osv.dev.
• DevDocs: объединённый офлайн-индекс документации — devdocs.io.
• Internet Archive Wayback Machine — web.archive.org.

Что дальше

Отдельный индекс, который заслуживает целой главы, — это код. Поиск по коду и артефактам.