Перейти к содержанию

Как работать с источниками

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

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

Основное правило

Для важного факта сначала найдите утверждение модели, затем откройте источник и проверьте, что источник действительно говорит то же самое.

1. Четыре уровня информации

В хорошем ответе полезно мысленно разделять четыре уровня.

Уровень 1. Первичный источник

Документ или страница, где информация опубликована непосредственно ответственным субъектом.

Примеры:

  • официальная документация проекта;
  • нормативный акт;
  • release notes разработчика;
  • security advisory производителя;
  • официальный тариф;
  • официальный репозиторий;
  • первичная статистическая публикация.

Уровень 2. Вторичный источник

Материал, который пересказывает или анализирует первичный.

Примеры:

  • техническая статья;
  • обзор СМИ;
  • блог инженера;
  • сравнительный тест;
  • форум.

Вторичные источники полезны для объяснения и опыта эксплуатации, но для точного факта часто лучше вернуться к первичному.

Уровень 3. Извлечённый факт

Факт, который Студия получила из источника.

Например:

В release notes версии 2.4 указано исправление X.

Уровень 4. Вывод модели

Интерпретация фактов.

Например:

Поэтому обновление особенно важно для серверов с конфигурацией Y.

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

2. Источник не равен доказательству любого соседнего предложения

Представим ответ:

Версия 5.1 выпущена 10 сентября. Она быстрее прошлой версии и поэтому рекомендуется всем клиентам. [Источник]

Источник может подтверждать только дату релиза, но не утверждение «быстрее» и не рекомендацию «всем клиентам».

Проверяйте границы утверждения.

3. Как открыть источник

После поискового ответа:

  1. найдите ссылку или карточку источника;
  2. откройте её;
  3. проверьте домен;
  4. найдите нужный фрагмент;
  5. сопоставьте его с формулировкой модели;
  6. проверьте дату;
  7. при необходимости проверьте версию документа.

Если источник больше недоступен, не считайте его автоматически подтверждением.

4. Проверяйте домен

Название страницы легко имитировать, домен — сложнее.

Например, заголовок:

Official Kubernetes Documentation

не делает страницу официальной.

Проверьте фактический адрес.

Для критичной информации полезно заранее указать допустимый домен:

Используй официальный источник с домена example.com.
Если нужной информации там нет, скажи об этом до обращения к вторичным источникам.

5. Дата публикации и дата события — разные вещи

Это один из самых частых источников ошибок.

Статья может быть опубликована 14 сентября, но описывать событие 1 сентября.

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

Поэтому для временно чувствительных задач фиксируйте:

  • дата события;
  • дата публикации источника;
  • дата последнего обновления, если известна;
  • дата вашей проверки.

Хороший запрос:

Проверь информацию на 14 сентября 2026 года.
Не путай дату публикации статьи с датой описанного события.

6. Версия документа важнее красивой даты

Для технической документации всегда проверяйте, к какой версии продукта относится страница.

Например:

Документация: продукт 4.x
Мой сервер: продукт 3.8

Даже свежая страница может быть неприменима к вашей системе.

7. Приоритет первичных источников

Практический приоритет для технической задачи:

Приоритет Источник Когда использовать
1 Официальная документация Поведение и настройки
2 Официальные release notes Изменения версий
3 Официальный репозиторий Код, issue, release
4 Advisory производителя Безопасность
5 Качественная техническая статья Объяснение и опыт
6 Форум / Q&A Симптомы и практические случаи

Форум иногда содержит лучшее практическое решение, но его нельзя автоматически считать нормативным описанием продукта.

8. Несколько источников

Несколько источников полезны, когда:

  • факт спорный;
  • информация быстро меняется;
  • решение дорогостоящее;
  • есть риск маркетинговой предвзятости;
  • важен опыт реальной эксплуатации.

Но учитывайте происхождение.

Три статьи, перепечатавшие один пресс-релиз, — не три независимых подтверждения.

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

Проверь утверждение минимум по двум источникам.

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

10. Что делать, если источники противоречат друг другу

Не просите модель «выбрать правильный» без анализа.

Используйте процедуру.

Шаг 1. Зафиксировать утверждения

Источник A: ...
Источник B: ...

Шаг 2. Сравнить даты

Более новый источник может отменять старый.

Шаг 3. Сравнить область действия

Разница может объясняться:

  • регионом;
  • тарифом;
  • редакцией продукта;
  • архитектурой;
  • типом лицензии;
  • API-версией;
  • датой действия правила.

Шаг 4. Определить первичность

Официальный документ обычно важнее пересказа.

Шаг 5. Сохранить неопределённость

Если конфликт не удалось разрешить, итог должен так и говорить.

Правильно:

Источники расходятся. По состоянию на дату проверки однозначного подтверждения нет.

Неправильно:

Я думаю, скорее всего верен вариант A.

если оснований для выбора нет.

11. Как читать цитату

Если интерфейс показывает фрагмент страницы, задайте три вопроса:

  1. Это именно тот источник?
  2. Фрагмент действительно содержит нужный факт?
  3. Модель не расширила смысл сверх написанного?

Пример источника:

Feature X is available in Enterprise edition.

Модель не должна превращать это в:

Feature X доступна во всех редакциях.

12. Источник может быть правдивым, но нерелевантным

Например, вы спросили о России, а найденная страница описывает США.

Или спросили про self-hosted редакцию, а источник — про SaaS.

Проверяйте:

  • регион;
  • продукт;
  • редакцию;
  • версию;
  • тип аккаунта;
  • дату;
  • техническую платформу.

13. Источник может устареть

Особенно быстро устаревают:

  • цены;
  • тарифы;
  • API;
  • поддерживаемые модели;
  • версии ПО;
  • облачные квоты;
  • публичные политики;
  • интерфейсные инструкции.

Для них полезно требовать:

Укажи дату, на которую информация проверена.

14. Динамические страницы

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

Если ответ выглядит подозрительно коротким:

  1. откройте страницу вручную;
  2. сравните содержимое;
  3. найдите альтернативную статическую документацию;
  4. попросите Студию использовать другой официальный источник.

15. PDF как веб-источник

Если поисковый результат ведёт на PDF:

  • убедитесь, что PDF действительно относится к нужной версии;
  • проверьте титульную страницу и дату;
  • если документ большой, лучше загрузить его в Студию и анализировать через File Search;
  • не делайте вывод только по сниппету поисковой выдачи.

Подробнее: Работа с PDF.

16. Репозиторий как источник

Для программного обеспечения полезными первичными источниками являются:

  • Releases;
  • Tags;
  • CHANGELOG;
  • SECURITY.md;
  • официальные issues;
  • pull request, который внёс изменение;
  • документация конкретного commit/tag.

При этом main/master может содержать ещё не выпущенную функциональность.

Поэтому спрашивайте:

Это уже входит в последний стабильный релиз или пока есть только в основной ветке?

17. Форумы и пользовательский опыт

Форумы особенно полезны для вопросов:

  • «встречал ли кто-то такой симптом»;
  • «какие реальные ограничения у решения»;
  • «какие проблемы появились после обновления».

Но пользовательское сообщение может:

  • быть ошибочным;
  • относиться к другой версии;
  • не содержать полного контекста;
  • предлагать небезопасный workaround.

Попросите модель маркировать такие сведения как опыт сообщества, а не официальное требование.

18. Маркетинговая страница

Маркетинговый сайт — первичный источник того, что заявляет производитель, но не всегда достаточный источник для технического ограничения.

Например:

«Поддерживает enterprise security»

не объясняет:

  • какие именно механизмы;
  • в какой редакции;
  • при каких настройках;
  • какие сертификаты реально есть.

Ищите техническую документацию.

19. Цены и тарифы

Для цены всегда проверяйте:

  • валюту;
  • НДС;
  • единицу тарификации;
  • регион;
  • дату;
  • минимальный объём;
  • бесплатный tier;
  • скидки;
  • входящие/исходящие единицы;
  • условия кэширования.

Не используйте старую статью как источник текущего тарифа, если доступна официальная страница цен.

20. Факт и рекомендация

Попросите модель явно отделять:

ФАКТ:
официальная документация требует минимум 8 ГБ RAM.

ВЫВОД:
для production я бы закладывал 16 ГБ с запасом.

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

21. Проверка чисел

Числа особенно легко искажать.

Если ответ содержит:

  • цену;
  • процент;
  • дату;
  • лимит;
  • размер;
  • производительность;
  • количество;
  • версию;

откройте соответствующий источник.

Попросите:

Для каждого числа укажи источник рядом с самим числом.

22. Проверка таблицы

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

Лучший формат:

Критерий A B Основание
API есть есть официальная документация
Цена ... ... страницы тарифов
Linux ... ... support matrix

Так легче понять происхождение каждой строки.

23. Если ссылка ведёт не туда

Возможные причины:

  • страница переехала;
  • сайт изменил URL;
  • поисковая система отдала устаревший адрес;
  • редирект изменил назначение;
  • модель неверно сопоставила источник.

Не восстанавливайте отсутствующий факт по памяти модели. Найдите новый первичный URL.

24. Если источник недоступен

Пометьте его как недоступный на момент проверки.

Если факт важен:

  • найдите официальный mirror;
  • найдите другую страницу того же производителя;
  • найдите release note;
  • проверьте репозиторий;
  • сохраните неопределённость.

25. Если страницы меняются без истории версий

Для решения, которое должно быть воспроизводимым через месяц, одного URL недостаточно.

В рабочем процессе можно сохранить:

  • PDF/HTML-снимок страницы, если это разрешено;
  • дату доступа;
  • номер версии;
  • release/tag;
  • relevant quote;
  • хэш документа для внутреннего архива.

Это особенно важно для аудита.

26. Высокорисковые сведения

Для юридических, медицинских, финансовых, кадровых и security-решений:

  1. используйте первичный источник;
  2. проверяйте действующую редакцию;
  3. привлекайте профильного специалиста, когда это требуется процессом;
  4. не считайте генеративный пересказ официальным заключением.

ИИ Студия помогает найти и объяснить информацию, но не заменяет процедуру утверждения вашей организации.

27. Контрольный чек-лист источника

Перед тем как использовать найденный факт в решении, проверьте:

[ ] Домен настоящий?
[ ] Источник первичный или вторичный?
[ ] Дата подходит?
[ ] Версия продукта подходит?
[ ] Регион подходит?
[ ] Фрагмент действительно подтверждает утверждение?
[ ] Нет ли более нового документа?
[ ] Не перепутан факт с выводом модели?
[ ] Числа проверены?
[ ] Есть ли конфликтующие источники?

28. Контрольный запрос для модели

После сложного исследования можно отправить:

Проведи самопроверку предыдущего ответа.

Для каждого существенного утверждения:
1. укажи источник;
2. укажи, подтверждает ли источник утверждение напрямую;
3. отметь собственные выводы как интерпретацию;
4. укажи неподтверждённые пункты;
5. проверь дату и применимость версии.

Ничего нового не додумывай.

29. Источники и корпоративные документы

Тот же принцип действует для File Search.

Цитата из Регламент.pdf показывает происхождение фрагмента, но модель всё равно может неверно интерпретировать его.

Поэтому методика едина:

найти источник
    ↓
увидеть цитату
    ↓
открыть оригинал
    ↓
проверить смысл
    ↓
только потом использовать вывод

Подробнее: Цитаты из файлов.

30. Источники и память

Память не является источником истины.

Если в памяти сохранено:

production PostgreSQL = 15

а официальный актуальный документ говорит:

production PostgreSQL = 16

документ должен иметь приоритет.

Устаревшую память необходимо обновить или удалить.

Подробнее: Память.

Короткое правило

Для любого важного утверждения задайте три вопроса:

Кто это сказал? Когда? Где это написано?

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

Что читать дальше