Нужную книгу больше не обязательно искать: как ИИ меняет сам принцип работы с информацией

Эдуард Ланчев · «Ланчев PRO ИИ»

В разработке мы давно отделили данные от интерфейса. Теперь то же самое начинает происходить со знаниями. И в этой статье я покажу это на своём примере.

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

Чтобы проверить, насколько это работает за пределами красивого демо, я построил такой конвейер на реальном корпусе: 206 длинных видео, 160 часов 56 минут, 2,15 млн слов. В процессе пришлось решать вполне инженерные задачи — приоритизацию, дедупликацию, прослеживаемость происхождения выводов, проверку фактов, сохранение состояния, регрессии агента и критерий, по которому можно перестать читать оставшиеся источники.

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

Дальше покажу, как это работает на практике и почему последствия этой перемены гораздо больше, чем просто «ИИ быстрее читает».

Мы привыкли получать знания через готовые информационные продукты.

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

Автор книги решил, что теме нужно 400 страниц, — у нас есть 400 страниц.

Автор записал трёхчасовой подкаст — перед нами три часа разговора.

Курс состоит из сорока уроков — значит, материал организован в сорок уроков.

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

Но меняется экономика этой работы.

То, что раньше требовало недель или месяцев ручного исследования, а на большом масштабе — нескольких специалистов, теперь всё чаще может организовать один человек, усиленный AI-агентами и обычными программными инструментами.

Именно поэтому речь не просто об ускорении чтения.

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

Можно начинать не с поиска готовой книги.

А с собственного вопроса.

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

И только после этого решить, в каком виде нужен результат.

Например, в виде книги.

Причём не обязательно той книги, которую кто-то уже написал.

Можно получить материал именно той глубины, с той последовательностью и с теми акцентами, которые нужны конкретно мне. Сегодня — подробную книгу. Завтра на той же основе — обзор на двадцать минут. Для поездки — аудиоверсию. Для работы — сравнительную таблицу. Для повторения — карточки. Для другого читателя — тот же материал, но с совершенно другой глубиной и языком.

То есть меняется сама последовательность:

Сначала вопрос. Потом источники. Потом структура знания. И только в конце — форма его потребления.

Именно эту модель я и решил проверить на практике.

Не на пяти PDF-файлах и не на демонстрационном наборе документов, где любой результат можно получить за несколько минут.

Я взял корпус, ручная последовательная обработка которого уже сама по себе была серьёзной задачей: 206 длинных видео, почти 161 час материала и 2,15 млн слов транскриптов.

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

По дороге выяснилось несколько вещей, которых не видно в обычном разговоре про «LLM умеют читать большие тексты».

Часть из 206 публикаций на самом деле оказалась производными одного и того же материала.

Читать оставшиеся источники подряд в какой-то момент стало бессмысленно — полезнее было искать конкретные пробелы в уже построенной модели знаний.

Хорошо структурированный результат оказался совсем не равен достоверному: из первых десяти проверенных важных числовых утверждений половина потребовала исправлений.

А на стадии написания текста сам AI-агент начал создавать уже другой класс проблем: терять ранее принятые требования, ссылки на первоисточники и части корректно собранного материала.

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

И в какой-то момент стало очевидно ещё кое-что:

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

Именно об устройстве этой системы — и о том, что она меняет в нашем способе получать и использовать информацию, — дальше и пойдёт речь.

Вместо готовой книги я решил собрать свою

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

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

Как разработчик IT- и AI-решений с более чем двадцатилетним опытом, я изначально не рассматривал это как задачу вида «загрузить всё в чат и попросить написать книгу».

Меня интересовала другая архитектура: можно ли построить воспроизводимый информационный конвейер, в котором ИИ выполняет масштабную смысловую работу, обычный код делает то, что должен делать обычный код, а человек остаётся заказчиком, архитектором и редактором результата.

Исходный массив оказался таким:

161 час видео — это больше двадцати восьмичасовых рабочих дней только на непрерывное воспроизведение.

Без конспектирования.

Без возврата к старым материалам.

Без сопоставления разных версий одной мысли.

Без поиска повторов.

Без проверки фактов.

И без написания результата.

В одном из ранних отчётов проекта фигурировали 239 часов. Это число получалось из другого показателя: 2,15 млн слов, пересчитанных при условной скорости речи 150 слов в минуту.

Для этой статьи я использую фактическую длительность исходных видео из метаданных — 160 часов 56 минут.

Книга в этом эксперименте создаётся как мой личный исследовательский материал и не предназначена для распространения. В статье я обсуждаю технологию работы с публичной информацией, а не содержание самих источников.

Сначала весь корпус нужно увидеть — но не обязательно весь глубоко прочитать

Первым этапом я получил транскрипты и метаданные всех 206 длинных материалов. Но сразу отправлять два миллиона слов в LLM не было никакой необходимости. То, что можно надёжно посчитать программно, лучше считать программно. Поэтому первый проход сделал обычный Python.

Он собирал по всему корпусу, например:

• числовые выражения;

• денежные значения;

• проценты;

• плотность профессиональной терминологии;

• тематические маркеры;

• повторяющиеся выражения;

• некоторые характеристики содержания и структуры.

Темы на первом приближении определялись простыми словарями:

TOPICS = {
    "цена": ["offer", "price", "pricing", "guarantee"],
    "трафик": ["lead", "traffic", "ads", "content"],
    "продажи": ["sales", "close", "objection", "script"],
    "люди": ["hire", "employee", "team", "manager"],
    "операции": ["process", "system", "sop", "scorecard"],
}

Это довольно примитивный анализ.

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

После этого материалы можно было расставить по приоритету.

В первой группе оказались 24 разбора конкретных ситуаций с высокой плотностью практической фактуры.

Во второй — 55 технических и тематических выступлений.

В третьей — остальные 127 материалов.

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

При последовательном чтении единицей работы остаётся источник:

у меня 206 видео, значит надо посмотреть 206 видео.

В моём случае единицей работы был вопрос:

какие источники сейчас дадут максимальный прирост ответа на мой вопрос?

Это уже совсем другая задача.

ИИ не пересказывал видео. Он пополнял модель знаний

Если просто последовательно делать summary каждого ролика, через какое-то время получится папка из сотни прекрасных конспектов. Но сопоставлять их будет почти так же неудобно, как сопоставлять сами видео. Поэтому у агента была другая задача.

Каждый глубоко разбираемый материал превращался в структурированную выписку одинакового формата.

Я разделил содержимое, например, на несколько типов.

Принцип — утверждение о том, как устроен мир.

Правило — что, по мнению автора, из этого принципа следует делать.

Приём — конкретное действие.

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

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

Несущее число — цифра, без которой конкретный аргумент заметно ослабевает.

Отдельно появился очень важный тип — реконструкция.

Например, в одном материале автор формулирует принцип, в другом показывает правило, которое фактически из него следует, но сам никогда прямо эти две вещи не связывает.

AI способен увидеть связь. Но эта связь уже принадлежит не источнику, а системе анализа. Поэтому её нельзя незаметно выдавать за слова автора.

Упрощённо одна сущность выглядела так:

Принцип
├── формулировка
├── чем он обоснован
├── какие правила из него следуют
├── связанные приёмы
├── случаи применения
├── ограничения и противоречия
└── источник + временная отметка

Это уже не summary.

Summary отвечает:

«Что было сказано в этом видео?»

А мне был нужен ответ другого типа:

«Что это видео добавляет или меняет в уже существующей модели?»

И вот с этого момента источник начинает терять свою первоначальную форму.

Фрагмент двухчасового интервью и три минуты из другого выступления могут оказаться частями одного принципа.

А два разных часовых видео — практически одним и тем же материалом.

Девять ссылок могут оказаться одним источником

Это оказалось одним из самых интересных эффектов всего эксперимента. Контент в интернете существует не так аккуратно, как книги на полке.

Одно большое выступление можно:

• опубликовать полностью;

• нарезать на пять роликов;

• один из них выпустить ещё раз под новым названием;

• собрать фрагменты в тематическую компиляцию;

• использовать тот же эпизод в другом материале.

На уровне площадки это разные URL, разные заголовки и отдельные счётчики просмотров. На уровне знания это может быть один и тот же текст.

Для поиска подобных случаев я использовал в том числе сравнение 12-словных последовательностей. В одном проходе девять видео оказались на 61–84% уже покрыты тремя ранее разобранными материалами.

Нет смысла снова отправлять их агенту как девять независимых источников. Вместо этого для них появились короткие указатели на уже существующие выписки. Затем нашёлся ещё более показательный пример.

Одна большая запись длиной 451 минуту включала материал, из которого были сделаны девять отдельных опубликованных нарезок. Их текстовое перекрытие с исходной записью составляло 71–96%. Совокупно эти девять URL получили около 13,27 млн просмотров.

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

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

Отсюда простой, но важный вывод:

URL — это не единица знания.

Новый заголовок — не обязательно новая мысль.

Повторная публикация — не независимое доказательство.

И это одна из причин, почему я говорю не просто об ускорении чтения.

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

Не «сколько ещё осталось прочитать», а «чего ещё не хватает»

Изначально в очереди стояли все 206 видео.

Но зачем обрабатывать их все одинаково глубоко?

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

На первом большом контрольном срезе система закрыла 125 из 206 видео:

• для 107 видео были сделаны полноценные структурированные выписки;

• ещё 18 видео оказались в значительной степени покрыты уже разобранными материалами, поэтому вместо повторного полного разбора для них были сохранены короткие указатели на основные источники.

На них приходилось примерно 78% суммарных просмотров исследуемого корпуса. Это именно доля суммарных просмотров, а не оценка того, что к этому моменту было извлечено 78% знаний корпуса.

Оставался ещё 81 материал. Можно было продолжить линейно: 126-й, 127-й, 128-й… Но к этому моменту уже существовала структура будущей книги. Поэтому я поменял направление поиска. Сначала смотрим на модель знания. Находим существенный пробел. И только потом возвращаемся в исходный корпус и выбираем несколько материалов, которые способны этот пробел закрыть.

Так действительно произошло: после остановки широкого прохода я адресно добавил ещё четыре полных разбора.

Сейчас обработано 129 записей из 206:

• 111 полных;

• 18 указателей.

Остаётся 77 материалов — ещё 690 425 слов.

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

Это, пожалуй, одна из самых чистых иллюстраций всей идеи статьи.

Старая модель говорит:

У меня осталось 77 непрочитанных источников.

Новая:

Какие существенные вопросы у меня ещё остались без достаточного ответа?

Не источник управляет исследованием.

Вопрос управляет выбором источника.

Из корпуса появляется новый слой — база знаний

На контрольном срезе из 125 обработанных записей промежуточный банк содержал:

Почему 321 принцип превратился в 282

На первом проходе из корпуса было извлечено 321 утверждение, классифицированное как принцип.

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

Сначала я попробовал решить эту задачу привычным техническим способом — через векторные представления и автоматическую кластеризацию по смысловой близости.

И здесь эксперимент дал полезный отрицательный результат.

Векторная кластеризация не сработала достаточно хорошо.

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

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

Поэтому вместо автоматического embedding → clustering → готовые группы пришлось сделать отдельный смысловой проход по банку: сопоставлять не близость формулировок, а саму модель, которая за ними стоит.

После этого:

321 исходный принцип → 282 самостоятельных принципа.

39 повторов были объединены в 28 смысловых групп.

И для меня это оказался важный результат проекта. Embeddings прекрасно помогают искать кандидатов на сходство. Но семантическая близость ещё не означает смысловую эквивалентность.

В таком исследовании векторный поиск может сказать:

«Вот эти утверждения стоит сравнить».

Но окончательный вопрос другой:

«Это действительно одна и та же мысль — или две похожие мысли с разными условиями и следствиями?»

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

У каждого вывода должен быть обратный адрес: что такое provenance

Здесь появляется ещё одно важное понятие — provenance.

В простейшем переводе это происхождение. Но применительно к такому проекту одной ссылки на первоисточник недостаточно.

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

Упрощённо:

исходное видео, 37:42
        ↓
структурированная выписка
        ↓
принцип / правило / случай / число
        ↓
связь с другими сущностями
        ↓
      глава
        ↓
конкретный абзац / таблица / схема

Предположим, в книге появляется утверждение:

при определённых условиях действует правило X.

Обычная ссылка отвечает на вопрос:

«Где автор говорил про X?»

Provenance должен позволять ответить на гораздо более широкий набор вопросов:

Из какого фрагмента появился этот вывод?
Был ли он сказан автором напрямую или реконструирован из нескольких материалов?
Какие другие источники его подтверждают?
Нет ли в более поздней записи другой версии?
На каких случаях он основан?
Какие главы и таблицы используют этот вывод?

И это становится особенно важно после любой ошибки.

Допустим, я выясняю, что число в одном из исходных материалов неверно.

Без provenance приходится искать вручную: куда мы успели протащить эту цифру, какие выводы на ней построили и в каких главах она появилась.

С provenance задача формулируется иначе:

ошибочный источник
        ↓
какие сущности от него зависят?
        ↓
какие главы используют эти сущности?
        ↓
какие абзацы, таблицы и схемы нужно пересмотреть?

То есть provenance — это не декоративные ссылки «для солидности».

Это механизм управляемости знания.

Он нужен не только для проверки, но и для обновления.

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

Ссылка и provenance — не одно и то же

Здесь важно разделить две вещи.

Ссылка говорит: вот исходный материал.

Provenance говорит: вот путь от исходного материала до конкретного элемента результата.

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

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

Сам provenance пока реализован частично — через структуру выписок, ссылки и реестры.

То есть provenance здесь — это не просто система ссылок. Это механизм, который позволяет не потерять происхождение знания после всех преобразований корпуса.

Почему это не просто RAG

На этом месте у технического читателя вполне может возникнуть вопрос:

А зачем вообще весь этот конвейер? Разве нельзя было просто проиндексировать транскрипты и сделать RAG?

Можно.

И для некоторых задач именно так я бы и поступил.

Если мне нужно спросить:

«Что в этих 206 видео говорилось о такой-то теме?»

то базового RAG по исходному корпусу вполне достаточно: разбить транскрипты на фрагменты, проиндексировать их — например, с помощью embeddings и векторного поиска, — найти релевантные фрагменты и передать их модели вместе с вопросом.

Упрощённо:

вопрос
  ↓
поиск релевантных фрагментов
  ↓
контекст для LLM
  ↓
ответ

Но моя задача была другой.

Мне нужен был не очередной ответ поверх исходного корпуса, а новый информационный объект, собранный из этого корпуса.

Поэтому между исходными транскриптами и будущей книгой появился отдельный слой — постоянная модель знаний, которая собирается в несколько этапов:

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

provenance — сквозной слой,
связывающий каждый уровень с исходными материалами

То есть provenance здесь не отдельный этап конвейера. Он должен сохраняться на всём пути преобразования информации.

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

Базовый RAG в первую очередь решает задачу:

«Какие фрагменты исходных материалов сейчас релевантны моему запросу?»

Этот конвейер решает ещё несколько других:

«Что этот фрагмент добавляет к уже известному?»

«Это новая идея или ещё одна формулировка существующей?»

«Противоречит ли она более ранней версии?»

«Какие практические случаи подтверждают или ограничивают правило?»

«Насколько можно доверять числу, на котором держится вывод?»

«В какую часть новой структуры знаний это должно попасть?»

И результат такой обработки сохраняется независимо от конкретного пользовательского запроса.

Это важное отличие.

В базовой RAG-схеме постоянным внешним слоем служит индекс или хранилище исходного либо предварительно обработанного корпуса. Для каждого нового вопроса система извлекает из него подходящий контекст и использует этот контекст при генерации ответа.

В моём случае появляется другой постоянный артефакт — сама модель знаний, которая существует независимо от конкретного запроса.

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

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

Такого объекта ни в одном из первоначальных видео не существовало.

Особенно хорошо отличие видно на дедупликации

Поиск в RAG может вернуть релевантные фрагменты из девяти разных публикаций.

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

То же относится к смысловым дублям. Embeddings хорошо помогают находить кандидатов на сходство, но сами по себе не отвечают на более строгий вопрос: действительно ли перед нами одна и та же идея. Поэтому векторная кластеризация не заменила смысловое сведение 321 извлечённого принципа до 282 самостоятельных.

Retrieval отвечает прежде всего на вопрос «что сейчас релевантно запросу?». Модель знаний должна дополнительно отвечать: «что это такое, является ли оно новым, с чем совпадает, чему противоречит и как связано с тем, что уже известно?»

Где RAG здесь всё-таки пригодится

Причём я вовсе не противопоставляю эту архитектуру RAG.

Наоборот: RAG логично поставить поверх уже построенной модели знаний.

Тогда retrieval будет работать не только по двум миллионам слов сырых транскриптов, но и по более качественному слою:

вопрос пользователя
  ↓
поиск по модели знаний
  ↓
принципы + случаи + утверждения со статусами проверки
  ↓
при необходимости — исходные фрагменты
  ↓
ответ с provenance

Например, я смогу спросить:

«Покажи все случаи, где это правило не сработало».

Или:

«Как позиция по этому вопросу менялась с 2022 по 2026 год?»

Или:

«Какие выводы книги зависят от утверждений со статусом “не подтверждено”?»

Это уже гораздо интереснее базового поиска релевантных фрагментов в исходном корпусе.

Поэтому я бы сформулировал различие так:

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

Поэтому RAG вполне может быть частью этой системы. Но retrieval — не та основная работа, ради которой она строилась: основная работа здесь заключается в преобразовании корпуса в новое, связное и проверяемое представление знаний.

Знать происхождение утверждения ещё не значит знать, что оно верно

С provenance мы уже знаем, откуда взялся конкретный вывод и как он попал в итоговый материал. Но происхождение утверждения ещё ничего не говорит о его истинности.

Можно точно знать, что определённая цифра прозвучала в конкретном видео на конкретной минуте, — и при этом сама цифра может быть ошибочной.

Поэтому поверх provenance нужен отдельный контур — проверка утверждений.

Причём ошибка может появиться на разных уровнях.

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

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

Первую десятку я проверил отдельно.

Получилось:

То есть только три из первых десяти прошли проверку без существенных оговорок.

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

При этом часто общий тезис источника оставался вполне разумным. Ломалась конкретная числовая подпорка, которой он был усилен.

В одном случае одинаково звучащий показатель в разных источниках оказался рассчитан по разным определениям. В другом яркая цифра много лет переходила из публикации в публикацию, хотя надёжного первоисточника у неё обнаружить не удалось.

Это важное различие:

provenance позволяет понять, откуда утверждение взялось. Проверка должна ответить, насколько ему вообще можно доверять.

ИИ не делает исходную информацию истинной. Он позволяет работать с гораздо большим количеством источников — а значит, вместе с полезной информацией масштабирует и содержащиеся в них ошибки.

Но даже если исходное утверждение достоверно, остаётся ещё одна проблема: при преобразовании самого источника можно потерять часть содержащейся в нём информации.

Текст — это ещё не весь источник

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

Но транскрипт — это не само видео.

Транскрибация — преобразование с потерями.

Она сохраняет произнесённые слова, но не обязательно сохраняет всё содержание источника.

Человек может нарисовать на доске схему, показать таблицу, провести стрелку между двумя элементами, изменить рисунок по ходу объяснения — а в расшифровке останется только что-нибудь вроде:

«Вот здесь у нас это, а сюда идёт вот это».

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

С этой проблемой я столкнулся при подготовке схем для книги.

Ещё в начале проекта было зафиксировано правило: если автор объясняет мысль с помощью рисунка, нельзя восстанавливать этот рисунок только по тексту. Сначала нужно увидеть оригинальный кадр.

Но в ходе длинной агентной работы это требование потерялось.

В плане книги появились схемы, логически реконструированные исключительно по транскриптам.

Выглядели они вполне убедительно.

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

Я решил системно найти места, где визуальный слой потенциально содержит часть объяснения.

Простой машинный поиск по фразам вроде «сейчас нарисую», «вот здесь», «слева», «справа», «сотру» обнаружил 841 потенциальный эпизод в 183 записях.

Разумеется, это не значит, что книге нужны 841 иллюстрация. Большинство таких эпизодов после просмотра окажутся несущественными.

Предварительный план — отобрать примерно 25–40 кадров-эталонов, из которых в книгу в итоге могут попасть около 15–25 действительно полезных схем.

Процесс теперь выглядит так:

транскрипт + временная отметка
        ↓
короткий фрагмент исходного видео
        ↓
  кадр-эталон
        ↓
проверка того, что именно изображено
        ↓
самостоятельно перерисованная схема

Первый же тест показал, зачем всё это нужно.

По словам в транскрипте и общему смыслу объяснения напрашивалась лестница.

Я открыл исходный фрагмент.

На доске была пирамида.

Общий тезис по тексту был понят правильно. Но пространственная структура объяснения — нет.

Это хороший пример более общей проблемы:

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

Поэтому разные типы информации приходится обрабатывать по-разному.

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

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

И это касается не только видео.

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

Поэтому приведение разных источников к общей форме всегда требует осторожности.

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

Хороший информационный конвейер поэтому должен хранить не только извлечённый текст, но и возможность вернуться к оригиналу.

И даже этого недостаточно.

Можно правильно извлечь информацию, сохранить её происхождение и проверить важные утверждения — а затем потерять часть уже собранного знания на следующем этапе работы самого агента.

А дальше агент начал ломать уже нашу собственную работу

Когда содержательная база начала превращаться в связные главы, появилась новая группа проблем.

LLM очень хорошо умеет улучшать текст. Она может убрать повторы, соединить абзацы, сделать повествование естественнее. Но красивый текст и надёжный исследовательский артефакт оптимизируются по разным критериям.

В одном из редакторских проходов глава действительно стала лучше читаться. Одновременно количество уникальных ссылок на источники уменьшилось с 24 до 8. При последующем восстановлении ссылок потерялись ещё три содержательные мысли.

Это уже обычная регрессия.

После этого перед крупной редактурой стал создаваться снимок Markdown-файла, а Git позволял видеть, что именно изменилось.

Возник version.py.

У глав появились сохранённые варианты «до переписывания», «связный текст», «потеряны ссылки» и так далее.

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

Исчезли.

Например:

• диагностические вопросы для глав;

• словарь важных терминов;

• обратный указатель «какой источник куда вошёл»;

• правила подписывания таблиц и схем;

• требования к количеству полноценных случаев;

• правило восстанавливать визуальные схемы по оригинальному кадру, а не придумывать их исключительно из транскрипта.

После этого появился отдельный протокол написания главы.

Важное требование всегда существует не в «памяти диалога», а в файле проекта. Но самого наличия правила в файле недостаточно: агент всё равно может его не применить. Поэтому критичные требования нужно по возможности встраивать в обязательный процесс или автоматическую проверку.

Чем длиннее AI-проект, тем больше он похож на обычную программную систему

Это ещё один результат, который мне кажется принципиальным.

В длинном агентном процессе неизбежно появляются:

• состояние;

• артефакты;

• версия;

• очередь;

• протокол;

• повторный запуск;

• миграции формата;

• регрессионные проверки;

• тесты.

Например, состояние обработки видео вообще не зависит от памяти модели.

Правило простое:

есть book/extracts/<id>.md — материал обработан;

нет файла — находится в очереди.

После перезапуска скрипт заново вычисляет состояние по файловой системе.

А сборщик книги постепенно превратился из обычного Markdown→HTML конвертера в quality gate.

Он проверяет, например:

• не утекла ли внутренняя разметка;

• не остались ли служебные идентификаторы;

• закрыты ли специальные блоки;

• не повреждена ли структура документа.

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

Мне здесь нравится очень простое правило:

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

Основная агентная работа в проекте выполнялась Claude Opus 5.

Локальный журнал основной длинной сессии содержит 1 145 отдельных запросов модели и 1 077 обращений к инструментам.

Современная агентная разработка может превращаться в длительный производственный процесс, в котором агент многократно читает состояние, вызывает инструменты, создаёт артефакты, проверяет результат и продолжает с того места, где остановился.

Что здесь делает ИИ, что делает детерминированный код и что остаётся человеку

В результате граница получилась примерно такой:

Здесь нет противостояния «ИИ против человека» или «ИИ против обычного программирования». Наоборот. Самые сильные системы получаются, когда каждая часть делает то, в чём она хороша.

Python отлично считает 206 файлов одинаковым способом.

LLM отлично сопоставляет смысл сотен разных формулировок.

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

Человек определяет, зачем вообще всё это делается.

Здесь важно не смешивать автора кода и способ его выполнения. Python-скрипты в этом проекте в основном пишет ИИ-агент. Но после написания такой скрипт работает детерминированно: одинаково применяет заданный алгоритм ко всему корпусу. Именно поэтому Python и LLM в таблице находятся в разных категориях, хотя фактически работают в одной связке.

И книга здесь — только один из возможных интерфейсов

Это, ещё один важный вывод работы над проектом.

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

То, что пришло из видео, не обязано оставаться видео.

То, что пришло из статьи, не обязано оставаться статьёй.

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

На одной и той же основе можно собрать:

И даже внутри одной книги можно изменить параметры.

Например:

Сделай версию для разработчика.

Или:

Объясни ту же тему руководителю без технического бэкграунда.

Или:

Убери всё вводное и оставь только практические механизмы.

Или:

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

Раньше мы покупали знание вместе с формой, выбранной автором.

Теперь постепенно появляется возможность разделить эти вещи.

В терминах разработки это очень знакомая архитектура:

  данные
    ↓
  модель
    ↓
разные представления

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

Значит ли это, что книги больше не нужны?

Нет.

Потому что книга — не всегда контейнер фактов.

Художественную литературу бессмысленно превращать в таблицу тезисов.

В философском тексте ценность может находиться в самом ходе рассуждения.

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

Иногда человек хочет пройти путь вместе с автором — и никакой персональный информационный конвейер этого не заменяет.

Поэтому речь не об отмене традиционных книг.

Речь о том, что появляется ещё один способ создавать и потреблять знания.

Особенно там, где задача носит информационный характер:

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

• изучить массив технической документации;

• разобрать большое количество интервью;

• сравнить позиции экспертов;

• исследовать рынок;

• проанализировать нормативные документы;

• собрать корпоративное знание;

• подготовиться к новой роли или проекту.

В подобных задачах нам часто нужна не книга конкретного автора.

Нам нужен ответ определённого качества и глубины на собственный набор вопросов.

Почему я считаю это серьёзным сдвигом

Персональные исследования существовали всегда.

Можно было нанять аналитика.

Заказать обзор.

Собрать исследовательскую группу.

Заплатить редактору и написать книгу по техническому заданию.

Новизна не в том, что до появления LLM человечество физически не умело создавать персональные информационные продукты.

Меняется экономика этого процесса.

Работу, которая раньше требовала нескольких специалистов и месяцев времени, всё чаще способен организовать один человек.

Сегодня это ещё не кнопка «Сделать мне идеальную книгу».

Для проекта такого масштаба пока нужны:

• понимание архитектуры;

• агентные инструменты;

• работа с кодом;

• декомпозиция;

• контроль качества;

• умение правильно строить проверяемые промежуточные состояния.

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

И продолжает снижаться.

То есть массовой становится не только возможность получить ответ от ИИ.

Массовой постепенно становится возможность построить собственную систему производства знания.

Вот это уже изменение другого порядка.

А что получилось с самой книгой?

Здесь важно не выдать промежуточный результат за законченный.

Содержательная основа в основном собрана.

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

В полноценный связный текст сейчас превращены первые семь глав и приложение.

То есть корректная формулировка выглядит так:

материал книги в основном собран; сама книга ещё находится в процессе редакторского синтеза и оформления.

И это тоже показательно.

Собрать знание и написать хорошую книгу — не одна задача.

С помощью ИИ первая часть стала радикально масштабируемее.

Вторая всё ещё требует авторской работы.

Что я хочу изменить в следующей версии такого конвейера

Текущий проект уже показал, чего ему не хватает.

Во-первых, я с самого начала буду вести полноценную телеметрию: модель, операция, input/output tokens, cache, время, стоимость, какие артефакты были прочитаны и какие созданы.

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

Во-вторых, текущую частичную реализацию provenance хочется превратить в настоящий граф зависимостей:

source → extract → entity → chapter → paragraph

Тогда при обнаружении ошибки в источнике система сама сможет показать:

какие абзацы, таблицы и выводы потенциально нужно пересмотреть?

В-третьих, extraction и writing я бы развёл ещё жёстче.

Сначала формируется скучная, структурированная и проверяемая модель.

Только потом к ней допускается литературный редактор.

Потому что задача хорошего автора — сделать текст связным.

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

Иногда эти цели конфликтуют.

Вместо вывода

Когда я начинал этот проект, передо мной был большой архив материалов.

Можно было сформулировать задачу традиционно:

Мне нужно посмотреть 206 видео.

Сейчас эта формулировка кажется мне неправильной.

Мне не нужны 206 видео.

Мне нужен ответ на мой набор вопросов.

Видео — всего лишь один из типов сырья, из которого этот ответ может быть построен.

Поэтому новая формулировка выглядит иначе:

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

И здесь меняется вся цепочка.

Было:

автор → готовый источник → читатель

Становится возможным:

вопрос человека → множество источников → персональная структура знаний → нужная человеку форма

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

ИИ постепенно перестаёт быть только интерфейсом для получения ответов.

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

И тогда нужная нам книга действительно больше не обязана существовать заранее.

Мы можем начать с вопроса.

Автор: Эдуард Ланчев · «Ланчев PRO ИИ» · t.me/lanchev_pro_ai