TL;DR
Quote-Grounded Extraction ("заземление цитатой") — это способ вытаскивать факты из текстов так, чтобы им можно было верить. Сначала модель щедро собирает кандидатов и к каждому обязана приложить дословную цитату. Потом факт проходит узкие проверки: цитату ищут в тексте как строку, затем модель перечитывает всю страницу, если цитата называет только одну сторону связи. В конце пять независимых вызовов голосуют по вопросам «да/нет».
Главная боль в том, что на вопрос «подтверждает ли эта страница, что клиент X пользуется продуктом Y?» модель слишком охотно отвечает «да». Одну и ту же фразу она оценивает по-разному: один и тот же отзыв на четырёх страницах получил три «да» и одно «нет». Чем больше текста модель читает и выдаёт за раз, тем хуже результат. При этом лишний «клиент» в списке вредит сильнее, чем пропущенный: он создаёт ложное доверие.
Метод разводит задачи. Один вызов только предлагает (щедро, с цитатой). Другие вызовы только проверяют (узко, по одному критерию). Если доказательство разорвано (отзыв называет больницу, а заголовок называет продукт), включается шаг «прочитай всю страницу». Итоговое решение принимает голосование, а доля «да» служит шкалой уверенности.
Схема метода
ШАГ 1: Собрать страницы (весь сайт вендора + поиск по вебу с бюджетом) → кэш текста
ШАГ 2: Извлечение (щедрое, 1 вызов на страницу) → связь + дословная цитата
ШАГ 3: Починка цитаты (если склеена из кусков) → цитата из оригинального текста
ШАГ 4: Разрешение ссылки (referent): если цитата называет не обе стороны,
модель читает ВСЮ страницу → аргумент + да/нет + доказательная фраза из страницы
ШАГ 5: Проверки формы (без модели) → цитата есть в тексте? это организация, а не «больницы» или человек?
ШАГ 6: Панель: 5 одинаковых вызовов × вопросы да/нет → критерий пройден, если «да» ≥ половины
ШАГ 7: Принять с цитатой, URL, временем — или отклонить с кодом причины
Шаги 2–6 — отдельные запросы. Один запрос на всё не заменяет их, потому что метод держится на узости каждого вызова.
Пример применения
Задача: Маркетолог российского SaaS-сервиса готовит сравнение с «Битрикс24». Нужен список реальных клиентов конкурента с доказательствами. Источники: страницы кейсов, пресс-релизы, блог. Ошибка тут опасна: если в презентации назвать клиентом компанию, которая им не является, отдел продаж потеряет лицо.
Типичная проблема таких страниц: заголовок называет продукт («Как X внедрили Битрикс24»), а отзыв ниже называет только компанию («Мы сократили время обработки заявок вдвое»). Ни одна цитата не содержит обе стороны сразу.
Промпт 1 (извлечение, щедрый):
Ты извлекаешь факты о клиентах продукта «Битрикс24» из текста страницы.
Найди все организации, которые, возможно, используют «Битрикс24».
Если формулировка неоднозначна — всё равно включай, решать будем позже.
Для каждой связи верни:
- организация
- цитата: ОДИН непрерывный фрагмент, скопированный из текста дословно.
Захвати соседний заголовок или предложения, чтобы в цитате
оказались и название организации, и признак использования продукта
- тип доказательства: кейс / отзыв / логотип / пресс-релиз / другое
Не считай использованием: инвестиции, награды, участие в ассоциации,
партнёрство без внедрения.
Текст страницы:
[вставь текст]
Промпт 2 (разрешение ссылки, читает всю страницу):
Вот страница целиком и утверждение: «Компания {организация} использует
«Битрикс24»».
Прочитай страницу и ответь:
1. Аргумент: что на странице говорит за или против (2-3 предложения).
Учти, что «мы» в отзыве может относиться к автору отзыва, а название
продукта может быть только в заголовке.
2. Вердикт: ДА или НЕТ
3. Доказательная фраза: предложение, скопированное со страницы дословно.
Если прямого подтверждения нет — вердикт НЕТ.
Страница:
[вставь текст]
Результат: Промпт 1 вернёт список кандидатов с цитатами, среди них сомнительные. Промпт 2 для каждого сомнительного кандидата даст аргумент, «ДА/НЕТ» и фразу, которую можно проверить поиском по тексту (Ctrl+F). Принимаются только кандидаты с «ДА» и найденной фразой. Дальше пять запусков короткого судьи (шаблон ниже) отсеивают остальные сомнительные случаи.
Почему это работает
Слабость модели. Вопрос «подтверждает ли страница это?» провоцирует согласие, и ответ плавает от запуска к запуску. Когда модель читает много и сразу выдаёт много, качество падает. Если просить «найди и сразу проверь», получаешь то и другое хуже.
Сильная сторона. Модель хорошо выполняет узкую задачу с чёткой формой: скопируй фрагмент, ответь «да/нет» на один вопрос. Копирование проверяется простым поиском строки. Результат повторяется, когда ответы нескольких независимых вызовов усредняются.
Как метод это использует. Цитата превращает вопрос «верю ли я модели?» в вопрос «есть ли эта фраза на странице?», а на него отвечает поиск по тексту. Разделение ролей снимает конфликт: извлекатель может ошибаться в сторону щедрости, потому что дальше стоят фильтры. Шаг с разрешением ссылки закрывает главную дыру узких проверок: они теряют доказательства, разбросанные по странице. В экспериментах этот шаг более чем вдвое увеличил число найденных связей.
Рычаги управления: - Число голосов (5) → уменьши до 3 для экономии, увеличь, если ответы всё ещё плавают. - Порог «половина голосов» → подними до «все пять», если ложное срабатывание дороже пропуска. - Список критериев → добавляй по одному вопросу на каждую замеченную ошибку, например «это награда, а не использование». - Объём текста, который видит судья → шире даёт меньше потерь верных фактов, уже даёт меньше шума. В исследовании узкий кусок страницы давал много ложных отказов. - Строгость извлечения → «щедро» для поиска возможностей, «строго» для отчёта, который уйдёт клиенту.
Шаблон промпта
Шаблон из трёх промптов, по одному на этап. Критерии судьи в статье приведены в таблице 8, которой нет в доступной части текста. Поэтому ниже примеры критериев по описанию в статье, адаптируй их.
Промпт A — Извлекатель (щедрый):
Ты извлекаешь связи вида «{субъект} {тип_связи} {объект}» из текста.
Найди все связи, которые, возможно, есть в тексте. При неоднозначности
извлекай — решение примем на следующем шаге.
- Для каждой связи дай ОДНУ непрерывную цитату, скопированную из текста дословно.
- Захвати соседний заголовок или предложения, чтобы в цитате были
оба названия и признак связи.
- Не меняй, не склеивай, не сокращай цитату.
{что НЕ считается связью: например, инвестиция, награда, членство}
Текст:
{текст}
Промпт B — Разрешение ссылки (читает всё):
Дано утверждение: «{субъект} {тип_связи} {объект}».
Прочитай страницу целиком.
Местоимения («мы», «наша команда») относятся к автору отзыва.
Название продукта может быть только в заголовке или подписи.
{правило_для_типа_страницы: страница самого вендора или чужая}
Страница:
{страница}
Промпт C — Судья (запусти 5 раз независимо, каждый раз в новом чате или вызове):
Утверждение: «{субъект} {тип_связи} {объект}»
Фрагмент страницы: {фрагмент_вокруг_цитаты}
Дополнительно (если есть, от предыдущего шага): {аргумент_и_фраза}
Ответь только ДА или НЕТ по каждому критерию:
1. {критерий_1: страница представляет организацию как пользователя продукта?}
2. {критерий_2: субъект — конкретная организация, а не «клиники» вообще?}
3. {критерий_3: связь — не инвестиция, награда или членство?}
4. {критерий_4}
5. {критерий_5}
Формат: номер — ДА/НЕТ — причина в одну строку.
Правило итога: критерий пройден, если «ДА» набрало не меньше половины голосов. Связь принимается, если пройдены все применимые критерии. Доля «ДА» — твоя шкала уверенности: всё ниже порога отправляй на ручную проверку.
Что подставлять: {тип_связи} — то, что ищешь («использует», «интегрируется с», «поставляет»); {NotARelation} — явный список того, что похоже, но не считается; критерии — по одной проверяемой мысли в каждом.
🚀 Быстрый старт — вставь в чат:
Вот шаблон трёхшагового извлечения фактов с цитатами (извлекатель → разрешение ссылки → судья из 5 голосов).
Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие связи ты ищешь, что похоже на них, но не считается, и где доказательство бывает разорвано. Эти ответы нужны, чтобы написать список «не считается» и критерии судьи. На них держится точность метода. По остальному она возьмёт паттерн из шаблона.
Ограничения
⚠️ Цитата ≠ истина: цитата доказывает только, что страница это заявила. Актуальность и реальность связи она не проверяет. Вендор мог написать про клиента, который давно ушёл.
⚠️ Потеря верных фактов: даже финальная схема пропускает примерно каждый третий верный факт. Чаще всего их отсекает судья, который видит лишь кусок страницы и не видит заголовок «Нам доверяют» над рядом логотипов.
⚠️ Оценка зависит от эталона: против ручного списка компании метод набрал низкую точность, потому что список неполон. Большинство «ошибок» оказались реальными связями, которых в списке нет. Свои результаты сверяй со страницами, а не с чужой таблицей.
⚠️ Разметка делалась моделями: «правильные ответы» проставила одна сильная модель, перепроверила другая. Часть вердиктов пришлось переворачивать, человек читал только выборку.
⚠️ Интеграции хуже клиентов: связи «продукт — продукт» проверяются заметно менее точно, чем «организация — продукт».
⚠️ Цена и масштаб: пять голосов на каждую связь и несколько вызовов на страницу — это много запросов. В чате вручную метод годится для десятков страниц, для тысяч нужна автоматизация.
⚠️ Опасные источники: три сайта-агрегатора выдавали выдуманные связи, и их пришлось запретить. Сторонние страницы дают меньше полноты, а часто и доказательств нет вовсе.
⚠️ Часть статьи недоступна: текст оборван на разделе про доверительный балл. Выводы о длинном контексте, разбросе между запусками и подборе промптов (раздел 6) здесь не разобраны.
Как исследовали
Идея была простой: пусть любая связь попадает в граф знаний только с цитатой. Команда взяла 61 продукт для здравоохранения и каталог маркетплейса Elion с ручным списком клиентов и интеграций. Конвейер прошёл по всем страницам: 3284 страницы, 6428 кандидатов. Каждого кандидата разметила сильная модель (читала страницу целиком), а вердикт перепроверила другая модель. Из-за этого 14% вердиктов перевернули.
Метрик две. Против разметки по страницам точность 0.94, полнота 0.71. Против ручного списка каталога всего 0.34 и 0.41. Но из 803 пар, которых нет в списке, 716 (89%) подтверждены страницей. Значит, список неполон, а не метод плох.
Самый наглядный эксперимент был на 266 страницах 21 вендора. Без шага «разрешение ссылки» метод находил 133 связи, с ним — 291. Полнота выросла с 0.36 до 0.81, а точность тоже подросла (0.89 → 0.93). Ручной список этот выигрыш не заметил. Вывод для практики: если меряешь не тем, полезный шаг покажется бесполезным.
Агент поиска по вебу стоил $2.19 на все 61 вендора и нашёл доказательства для 37% клиентов, которых нет на сайте вендора. Из доли голосов панели авторы собрали доверительный балл (простая логистическая регрессия). При той же точности 0.94 он удерживает 0.77 верных связей против 0.63 у жёсткого правила. Одна лишь доля «да» среди пяти вызовов даёт почти тот же результат, что и вся модель. Для практика это значит, что считать голоса важнее, чем придумывать сложные формулы.
Неожиданности: чаще всего верные связи теряет критерий «страница представляет организацию как пользователя». Он зависит от контекста вне цитаты. А примерно одна цитата из одиннадцати оказывалась склейкой из двух кусков: модель пропускала символы между ними.
Адаптации и экстраполяции
🔧 Техника: расширь контекст судьи → меньше потерь верных фактов
Среди связей, отклонённых панелью, 594 уже подтвердил шаг «разрешение ссылки» по всей странице, и 391 из них были верными. Если судья отклоняет то, что уже подтвердило чтение всей страницы, давай ему вместе с фрагментом:
Дополнительно: предыдущий шаг прочитал страницу целиком и подтвердил связь. Его аргумент: {аргумент}. Его доказательная фраза: {фраза}. Учти это, но проверь, что фраза действительно есть в фрагменте или логична с ним.
Авторы так и делали: передавали судье аргумент и фразу с пометкой «утверждение предыдущего шага».
Экстраполяция: правила агента-исследователя в системном промпте или CLAUDE.md
В статье такой промпт не проверяли, это перенос идей агентного шага на инструкции:
Ты исследуешь клиентов компании {компания} в вебе.
Лимиты: не больше 25 поисков и 15 прочтений страниц.
Каждый вызов инструмента начинай с одной строки «Причина: …».
Читай только страницы, URL которых вернул поиск.
Не читай: соцсети, сайты вакансий, магазины приложений, агрегаторы {список}.
Каждую найденную связь записывай с дословной цитатой и URL.
Если цитаты нет — связь не записывай.
В конце верни страницы, которые стоит сохранить, и причину по каждой.
Ресурсы
- Работа: Every Edge Needs a Quote: Building a Quote-Grounded Knowledge Graph of Healthcare Software Adoption with Language-Model Agents — Juan Felipe Duran, Arthur Tobler, Martin Vallières (McGill University, Montreal; Toboggan Labs). Препринт.
- Каталог: Elion — elion.health
- Атрибуция: Rashkin et al. (идея привязки утверждений к источникам)
- ReAct-агент: Yao et al.
- Инструменты: LangGraph, OpenRouter, Braintrust, Firecrawl, Graphiti, Neo4j