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

> STORM от Stanford OVAL: как вести кабинетное исследование с помощью ИИ через роли, вопросы и источники, что доказала статья NAACL 2024 и где риски для компании.

Статья · Алексей Ишманов · 18 октября 2026 · https://aleksishmanov.ru/blog/storm-ii-issledovanie-stanford/

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](https://github.com/stanford-oval/storm) под лицензией MIT и собраны на фреймворке DSPy — о нём есть отдельный [разбор DSPy](/blog/dspy-kompilyator-dlya-llm-zaprosov/).

STORM — один из восьми методов кластера о [продуктовых решениях при неопределённости](/blog/produktovye-resheniya-pri-neopredelennosti/). В цикле решения он стоит в самом начале — на шаге «понять задачу».

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

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

Руководитель получает документ без видимых дыр. Дыры есть, но о них никто не знает: не спросили юриста, не посмотрели глазами закупщика, не проверили, кто уже пробовал и провалился. Команда идёт на интервью с готовой гипотезой и слышит в ответах то, что ожидала, — классическая [предвзятость подтверждения](/blog/confirmation-bias-v-dannyh-komanda-6-mesyatsev-validiruet-to-vo/).

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

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

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

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

1. **Поиск перспектив.** Модель называет смежные темы, система забирает оглавления соответствующих статей Википедии и по ним выделяет точки зрения. В экспериментах статьи — пять перспектив плюс обязательная перспектива «автор базовых фактов»; в коде пакета по умолчанию три плюс та же обязательная ([engine.py](https://github.com/stanford-oval/storm/blob/main/knowledge_storm/storm_wiki/engine.py), параметр `max_perspective`).
2. **Симуляция разговоров.** Для каждой перспективы «автор» задаёт вопрос, «эксперт» превращает его в поисковые запросы, ищет в интернете и отвечает только по найденному. В экспериментах — до пяти раундов на разговор, в коде пакета по умолчанию три (`max_conv_turn`). Источники проходят фильтр по правилам Википедии о надёжных источниках.
3. **План.** Сначала модель пишет черновой план по одной теме, затем переделывает его с учётом всех разговоров.
4. **Текст.** Статья пишется по разделам плана, каждый раздел — из собранных источников со ссылками. Потом идёт полировка: убираются повторы, добавляется вводная часть.

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

## Что исследование 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 идут циклом. Ценность в том, что между шагами вы видите и правите промежуточный результат.

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

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

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

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

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

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

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

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

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

Тот же пайплайн лежит отдельным материалом — промт [«Исследование по перспективам в стиле STORM»](/prompts/storm-issledovanie-po-perspektivam/), его можно скопировать одной кнопкой.

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

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

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

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

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

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

На выходе команда получает не вывод «рынок растёт», а раздел «пробелы»: источники не говорят, как бухгалтеры сейчас проверяют разноску и кто несёт ответственность за ошибку. С этими вопросами продакт идёт на интервью по правилам [Mom Test](/blog/mom-test-intervyu-s-klientami/) — спрашивать о прошлом поведении, а не о мнении про фичу. Так кабинетное исследование отделяет [просьбу от боли](/blog/pain-vs-customer_request/) ещё до первого звонка.

Найденные факты удобно сразу раскладывать на атомы — «нашли это, в источнике таком-то» — по схеме [атомарных исследований](/blog/atomic-research-atomarnye-issledovaniya/). Тогда интервью добавят новые атомы к тем же темам, а не родят отдельный отчёт.

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

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

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

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

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

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

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

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

1. **День 1.** Выбрать одно реальное решение на ближайший квартал и сформулировать тему исследования под него.
2. **День 2.** Прогнать пайплайн из пяти промтов, сохранить все промежуточные артефакты.
3. **День 3.** Проверить источники под ключевыми выводами, отметить неподтверждённые ссылки и вендорские материалы.
4. **День 4.** Сравнить с однопромтовым отчётом на ту же тему: какие вопросы и риски появились только в пайплайне.
5. **День 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*](https://arxiv.org/abs/2402.14207). 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*](https://arxiv.org/abs/2408.15232). EMNLP 2024.
- [stanford-oval/storm](https://github.com/stanford-oval/storm) — репозиторий STORM и Co-STORM, README, лицензия MIT.
- [knowledge-storm на PyPI](https://pypi.org/project/knowledge-storm/) — версия пакета и требования к Python.
- [STORM research preview](https://storm.genie.stanford.edu/) — демо Stanford OVAL.