Perplexity берёт с процитированной страницы лишь 6% текста: разбор 1355 отсылок

Разбор 60 ответов Perplexity, полученных через API на модели sonar-pro, показал: на страницах, попавших в источники, реально задействовано около 6,4% слов. Медианно это два фрагмента по 49 слов — абзац, пункт списка или ячейка таблицы. Остальной текст страницы в ответ не уходит.

Автор прогнал 20 промптов по три повтора, собрал 60 ответов и связал каждую номерную отсылку в тексте с конкретной страницей-источником. Всего в датасете 583 строки в поле sources_cited, за которыми стоит 220 уникальных URL, и 1407 номерных пометок [N]. После отсева коротких обрубков вроде «см. также» в разбор ушло 1355 отсылок. Из них 948 вели на страницы, которые ещё открываются, и только на 448 нашёлся пассаж, покрывающий хотя бы треть слов утверждения из ответа.

Главный практический вывод для тех, кто пишет страницы под цитирование: планировать нужно не прочтение страницы целиком, а то, что из неё вытащат один самодостаточный абзац. По числу фрагментов задействовано 2% текста, по словам — медиана 6,4% при среднем 11,6%. Сработавший кусок текста в среднем длиннее типичного: ИИ выбирает не случайные предложения, а более плотные и завершённые по смыслу.

В API Perplexity работа с фрагментом, а не с полным текстом, заложена впрямую. Параметр search_context_size со значениями low / medium / high управляет глубиной извлечения, а max_tokens_per_page задаёт максимум токенов содержимого с каждой результирующей страницы. Рядом стоит max_tokens — общий лимит на все результаты сразу. Как эти ручки соотносятся с тем, что реально долетает до ответа, документация не раскрывает: там не описано ни как выбирается кусок, ни на отрезки какого размера режется страница, ни правило самой нарезки.

У каждого источника в ответе Search API возвращается пять полей: title, url, date, last_updated и snippet — «короткая выдержка из статьи, относящаяся к запросу». Поля с полным текстом страницы, который ушёл в модель, в ответе нет вообще. То есть видно, какие URL Perplexity поставил в источники, но не видно, что именно со страницы поехало в ответ — весь текст, абзац или одна строка списка.

Чтобы восстановить это снаружи, автор резал HTML не по переводам строк, а по закрывающим тегам </p>, </li>, </h1>—</h6>, </td>, </blockquote>. Перенос строки в вёрстке не значит ничего, а закрытый тег абзаца, пункта списка или ячейки — это граница единицы смысла. Тег </div> в правило намеренно не входит: вёрстка оборачивает в div и обёртку, и её содержимое, поэтому один и тот же текст попадает в выборку дважды, а счётчик фрагментов раздувается.

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

Отдельная оговорка про имена полей: sources_cited — это поле собственного лога автора, куда он нормализует источники ответа. В самом API Perplexity они приходят как search_results и citations. Путать удобное имя из своего кода со схемой чужого ответа — хороший способ потом полчаса искать несуществующее поле в документации.

Для отрасли это означает, что оптимизация под цитирование в ИИ-поиске смещается от «сделать страницу релевантной» к «сделать отдельные абзацы самодостаточными». Страница может быть длинной, но если в ней нет плотного фрагмента, который отвечает на запрос целиком, шанс попасть в ответ падает. Это меняет приоритеты для тех, кто делает контент под Perplexity, — важнее структура и завершённость отдельных блоков, чем общий объём текста.