STORM от Стэнфорда: ИИ-исследование, которое сначала ищет точки зрения

STORM Stanford — это открытая система, которая собирает отчёт по теме не одним запросом к модели, а в несколько шагов: находит разные точки зрения, задаёт от их имени вопросы, отвечает на них по интернет-источникам, строит план и только потом пишет текст. Для руководителя ценна сама идея: ИИ для исследований работает лучше, когда его заставляют сомневаться и спрашивать, а не сразу писать гладкий ответ.

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

Что такое STORM Stanford и откуда он взялся

STORM расшифровывается как Synthesis of Topic Outlines through Retrieval and Multi-perspective Question Asking. Систему сделала группа Stanford OVAL: Ицзя Шао, Юйчэн Цзян, Теодор Канелл, Питер Сюй, Омар Хаттаб и Моника Лам. Статья «Assisting in Writing Wikipedia-like Articles From Scratch with Large Language Models» вышла на конференции NAACL 2024 (arXiv 2402.14207).

Задача в статье узкая и честно сформулированная: научить модель писать с нуля длинные статьи уровня Википедии — со ссылками на источники. Авторы сосредоточились на этапе до письма (pre-writing): что выяснить, у кого спросить и как это упорядочить.

Через полгода та же команда выпустила Co-STORM (EMNLP 2024): там к разговору ИИ-агентов подключается человек. Обе системы лежат в открытом репозитории stanford-oval/storm под лицензией MIT и собраны на фреймворке DSPy — о нём есть отдельный разбор DSPy.

STORM — один из восьми методов кластера о продуктовых решениях при неопределённости. В цикле решения он стоит в самом начале — на шаге «понять задачу».

STORM vs deep research в одном промте

Типичный запрос «сделай исследование рынка X» даёт связный текст за минуту. Проблема в том, что связность — не признак полноты. Модель выбирает одну рамку, которая кажется ей самой вероятной, и аккуратно заполняет её фактами.

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

Авторы STORM формулируют это прямо в README репозитория: если просто попросить модель задавать вопросы, это работает плохо. Нужна структура, которая заставит вопросы быть разными.

	Один промт «deep research»	Подход STORM
Рамка	одна, выбранная моделью неявно	несколько явных перспектив
Вопросы	модель задаёт себе сама или не задаёт	каждая перспектива задаёт свои, раунд за раундом
Источники	подтягиваются под уже готовый текст	ответ на каждый вопрос строится по найденным источникам
План	появляется вместе с текстом	собирается отдельно из всех разговоров
Что видно руководителю	готовый вывод	кто что спросил, что нашли и откуда

Как работает STORM: четыре шага

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

Поиск перспектив. Модель называет смежные темы, система забирает оглавления соответствующих статей Википедии и по ним выделяет точки зрения. В экспериментах статьи — пять перспектив плюс обязательная перспектива «автор базовых фактов»; в коде пакета по умолчанию три плюс та же обязательная (engine.py, параметр max_perspective).
Симуляция разговоров. Для каждой перспективы «автор» задаёт вопрос, «эксперт» превращает его в поисковые запросы, ищет в интернете и отвечает только по найденному. В экспериментах — до пяти раундов на разговор, в коде пакета по умолчанию три (max_conv_turn). Источники проходят фильтр по правилам Википедии о надёжных источниках.
План. Сначала модель пишет черновой план по одной теме, затем переделывает его с учётом всех разговоров.
Текст. Статья пишется по разделам плана, каждый раздел — из собранных источников со ссылками. Потом идёт полировка: убираются повторы, добавляется вводная часть.

Главная мысль: точки зрения появляются до вопросов, вопросы — до текста, а текст — после плана. Каждый следующий шаг опирается на артефакт предыдущего, и этот артефакт можно проверить глазами.

Что исследование STORM измерило, а что нет

Исследование STORM показало одно надёжное улучшение: редакторы Википедии сочли хорошо организованными 70% текстов STORM против 45% у базовой системы, а проверяемость ссылок не изменилась. В аннотации авторы пишут о росте «на 25% в абсолютном выражении» по организованности и на 10% по охвату — это процентные пункты, а не рост в четверть.

С чем сравнивали. Базовая система — RAG по плану (outline-driven RAG, oRAG): она тоже сначала строит план и ищет источники, но без перспектив и разговоров. Темы взяли из датасета FreshWiki — это свежие статьи класса B и выше из 100 самых редактируемых страниц Википедии за каждый месяц с февраля 2022 по сентябрь 2023; для экспериментов взяли 100 из них, для оценки редакторами — 20.

Кто и как оценивал. Десять опытных редакторов Википедии, каждую пару текстов — два редактора. Шкала от 1 до 7, «хорошо» — 4 и выше.

Критерий	Доля «хорошо», oRAG	Доля «хорошо», STORM	p-value
Интересность	57,5%	70,0%	0,077
Организованность	45,0%	70,0%	0,005
Релевантность	62,5%	65,0%	0,347
Широта охвата	57,5%	67,5%	0,084
Проверяемость	67,5%	67,5%	0,843

Источник: таблица 6 статьи Shao et al., 2024.

Что из этого следует:

Организованность — единственный уверенный результат. Рост с 45% до 70% (+25 процентных пунктов) — единственный с уверенной статистической значимостью, p = 0,005.
+10% по охвату — тоже пункты, и при p = 0,084 на 20 темах это осторожный сигнал, а не доказанный эффект.
Проверяемость не изменилась. Перспективы делают текст структурнее и шире, но не делают ссылки честнее.
Автоматическая проверка ссылок — оценка модели Mistral 7B-Instruct — дала полноту цитирования 84,83% и точность 85,18%. Около 15% предложений не подтверждались своими же ссылками. По разбору авторов, это не выдуманные источники, а неверные выводы из найденного и неточный пересказ.
Перенос перекоса источников. Семь из десяти редакторов назвали тексты STORM «эмоциональными» или «ненейтральными» — тон источников переходил в статью.

Чего статья не измеряла вовсе: бизнес-исследования, закрытые корпоративные данные, качество решений, принятых по такому отчёту, экономию времени аналитика. Эксперименты шли на моделях GPT-3.5 и GPT-4 (статья 2024 года). Перенос на ваш рынок — гипотеза, а не вывод.

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

Co-STORM: когда в разговор вмешивается человек

Co-STORM (Jiang, Shao и др., EMNLP 2024) решает другую задачу — поиск «неизвестных неизвестных»: того, о чём вы не догадались бы спросить. Несколько ИИ-экспертов обсуждают тему, отвечая по внешним источникам. Модератор подбрасывает вопросы из найденного, но ещё не использованного материала.

Человек может молча наблюдать или вмешаться и развернуть разговор. Система ведёт динамическую карту знаний (mind map) и в конце собирает отчёт. В пользовательском исследовании авторов (20 участников) 70% предпочли Co-STORM поисковику, 78% — RAG-чатботу.

Для продуктовой команды это ближе к живой работе: продакт сидит в обсуждении и направляет его в сторону своих сегментов, а не ждёт готовый отчёт.

Как провести кабинетное исследование с помощью ИИ без установки

Идею STORM можно повторить в любом чат-ассистенте с веб-поиском. Это не воспроизведение системы, а ручной пайплайн из пяти промтов, где шаги 2 и 3 идут циклом. Ценность в том, что между шагами вы видите и правите промежуточный результат.

Роли. Попросите назвать 5 стейкхолдеров темы с разными интересами и шестую роль «базовые факты».
Вопрос. Роль задаёт один вопрос; со второго раунда он опирается на прошлый ответ.
Ответ с источниками. Ответ только по найденным источникам, со ссылкой на конкретную страницу; нет источника — пишется «не найдено». Шаги 2–3 повторяются пять раундов для каждой роли, как в экспериментах статьи.
План. Сначала план без опоры на ответы, затем переработанный с учётом всех ответов, с пометкой, какие ответы его изменили.
Черновик. Текст по разделам плана, каждое утверждение — со ссылкой, отдельный раздел «противоречия и пробелы».

Шаблон промтов

Шаг 1. Тема: <тема>. Контекст: <продукт, сегмент, решение, которое мы принимаем>.
Назови 5 ролей, которые смотрят на эту тему по-разному
(покупатель, пользователь, регулятор, конкурент, отраслевой аналитик…),
и шестую роль «базовые факты». Для каждой — чего она боится и чего хочет.

Шаг 2. Ты — <роль>. Задай один вопрос по теме, который важен именно тебе.
Если это не первый раунд, вопрос должен опираться на прошлый ответ:
уточнять его, оспаривать или идти глубже. Только вопрос, без ответа.

Шаг 3. Ответь на этот вопрос только по источникам из веб-поиска.
Для каждого утверждения дай ссылку на конкретную страницу.
Если источника нет — напиши «не найдено», не додумывай.
Отдельно пометь источники с коммерческим интересом (вендор, PR, реклама).

Повтори шаги 2–3 пять раз для каждой роли: каждый новый вопрос
опирается на прошлый ответ. Затем переходи к следующей роли.

Шаг 4. Составь план отчёта без опоры на ответы. Затем переработай его
с учётом всех ответов и перечисли, какие ответы изменили план и как.

Шаг 5. Напиши отчёт по плану. Каждое утверждение — со ссылкой.
Последний раздел — «Противоречия и пробелы»: что источники не подтверждают
и какие вопросы нужно задать живым людям.

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

Тот же пайплайн лежит отдельным материалом — промт «Исследование по перспективам в стиле STORM», его можно скопировать одной кнопкой.

Как запустить STORM локально

Для технической команды полный пайплайн ставится пакетом knowledge-storm из PyPI (Python 3.10+): модели подключаются через litellm, поиск — через Bing, Serper, Tavily и другие модули, а для своих документов есть VectorRM. Команды запуска, параметры и настройку ключей смотрите в README репозитория. Посмотреть без установки можно в демо storm.genie.stanford.edu — это исследовательская витрина университета, а не корпоративный сервис, поэтому внутренние данные туда не загружают.

Пример: кабинетное исследование перед интервью с клиентами

Пример условный. B2B SaaS для бухгалтерии малого бизнеса думает об ИИ-фиче, которая сама разносит банковские выписки по статьям учёта. Решение на столе: стоит ли выделять под неё квартал команды.

Однопромтовый «ресёрч» выдаст обзор рынка ИИ в бухгалтерии и список конкурентов. Пайплайн в стиле STORM начнётся с ролей: главный бухгалтер, владелец бизнеса, аудитор, налоговый регулятор, конкурент-интегратор, «базовые факты».

Роль аудитора спросит, кто отвечает за ошибку автоматической разноски; роль регулятора — какие требования к хранению первичных документов. Владелец — сколько времени это реально съедает сейчас. Ни один из этих вопросов не появился бы в рамке «рынок ИИ-решений».

На выходе команда получает не вывод «рынок растёт», а раздел «пробелы»: источники не говорят, как бухгалтеры сейчас проверяют разноску и кто несёт ответственность за ошибку. С этими вопросами продакт идёт на интервью по правилам Mom Test — спрашивать о прошлом поведении, а не о мнении про фичу. Так кабинетное исследование отделяет просьбу от боли ещё до первого звонка.

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

Риски корпоративного использования

Качество источников. Фильтр STORM построен на правилах Википедии, ваш ручной пайплайн — на суждении модели. В нишевых B2B-темах первые страницы выдачи заняты вендорскими статьями и пресс-релизами. Отчёт унаследует их оптимизм — это и есть перенос перекоса, который отметили редакторы.
Неподтверждённые ссылки. Даже в исследовании каждое седьмое предложение не подтверждалось своей ссылкой. По разбору авторов, это не выдуманные источники, а неверные выводы из найденного и неточный пересказ. Правило без исключений: перед решением кто-то открывает каждый источник, на котором держится вывод; для этой проверки подходит промт «Исследование и проверка фактов».
Утечка данных. Как только в промт попадают внутренние документы, планы или данные клиентов, они уходят к провайдеру модели и поиска. Для VectorRM и внутренних баз нужен согласованный с безопасностью контур: какая модель, где она работает, что логируется.
Ложная полнота. Пять ролей — это пять ролей, которые придумала модель. Если в теме важна роль, о которой модель не знает, её не будет и в отчёте.
Устаревание. Результаты статьи получены на GPT-3.5 и GPT-4 и на жанре энциклопедической статьи. Ваш эффект нужно проверить на своей задаче.

Когда STORM не нужен

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

Что спросить у команды и как внедрить за неделю

Чек-лист для руководителя, которому принесли «ИИ-исследование»:

Какие перспективы рассматривали и кто их выбрал — модель или человек?
Какая перспектива дала больше всего неожиданных вопросов?
Сколько ключевых утверждений проверено открытием источника?
Какие источники коммерчески заинтересованы?
Что попало в «пробелы» и какие из них идут в интервью?
Какие внутренние данные отправлялись во внешнюю модель?

План на неделю:

День 1. Выбрать одно реальное решение на ближайший квартал и сформулировать тему исследования под него.
День 2. Прогнать пайплайн из пяти промтов, сохранить все промежуточные артефакты.
День 3. Проверить источники под ключевыми выводами, отметить неподтверждённые ссылки и вендорские материалы.
День 4. Сравнить с однопромтовым отчётом на ту же тему: какие вопросы и риски появились только в пайплайне.
День 5. Превратить «пробелы» в сценарий интервью и решить, нужен ли команде локальный STORM или хватает промтов.

Частые вопросы

Чем STORM отличается от обычного deep research?

Обычный запрос сразу пишет ответ в одной рамке. STORM сначала выделяет несколько точек зрения, от их имени задаёт вопросы, отвечает по источникам и только потом строит план и текст. Промежуточные шаги видны, их можно проверить и поправить.

Насколько STORM лучше других подходов?

В статье NAACL 2024 доля текстов, которые редакторы Википедии сочли хорошо организованными, выросла с 45% до 70% против RAG по плану (oRAG), по охвату — с 57,5% до 67,5%. Оценивали 20 тем, проверяемость ссылок не изменилась. Это результат на энциклопедических статьях, а не на бизнес-исследованиях.

Можно ли использовать STORM для внутренних документов компании?

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

Бесплатен ли STORM?

Код открыт под лицензией MIT и ставится через pip install knowledge-storm. Платить придётся за вызовы языковой модели и поискового API, ключи к которым вы подключаете сами.

Можно ли доверять ссылкам в отчёте STORM?

Не без проверки. В самой статье около 15% предложений не подтверждались приведённой ссылкой. Ключевые выводы, от которых зависит решение, проверяют открытием каждого источника.

Источники

Yijia Shao, Yucheng Jiang, Theodore A. Kanell, Peter Xu, Omar Khattab, Monica S. Lam. Assisting in Writing Wikipedia-like Articles From Scratch with Large Language Models. NAACL 2024.
Yucheng Jiang, Yijia Shao, Dekun Ma, Sina J. Semnani, Monica S. Lam. Into the Unknown Unknowns: Engaged Human Learning through Participation in Language Model Agent Conversations. EMNLP 2024.
stanford-oval/storm — репозиторий STORM и Co-STORM, README, лицензия MIT.
knowledge-storm на PyPI — версия пакета и требования к Python.
STORM research preview — демо Stanford OVAL.