У меня есть руководитель, который очень хорошо ревьюит документы. Настолько хорошо, что один его проход по моим текстам породил 73 комментария. За один день.
Первая реакция была ожидаемая: сесть и править. Вторая пришла минут через десять и оказалась продуктивнее: это же датасет.
Дальше — история о том, как замечания одного конкретного человека превратились в чек-лист из 16 правил, чек-лист — в этап конвейера, а следующая партия документов ушла без единой правки по старым паттернам. С кодом, промптами и одним неудобным вопросом в конце.
Контекст: что за документы
Я работаю в крупной организации и среди прочего пишу справки о технической целесообразности ИИ-проектов. На входе — бриф: «хотим ассистента для внутренних специалистов», «хотим распознавать дефекты по фото». На выходе — документ на 7–10 страниц: реализуемо ли это, какими силами (своими или подрядом), какие риски, какие вопросы надо задать заказчику до старта.
Таких справок — поток. Структура одинаковая, дисциплина оценки одинаковая, проекты разные. Классический кандидат на автоматизацию, и она у меня есть: пайплайн на LLM-агенте, который собирает документы проекта, извлекает текст, заполняет структурированный JSON и собирает из него .docx по шаблону. Человек (я) правит содержание и отвечает за результат.
Пайплайн работал, справки выходили быстро, я был доволен.
Потом пришло ревью.
73 комментария за один вторник
Руководитель прошёлся по накопившейся пачке — девять справок — и вернул их с комментариями. 73 штуки. От четырёх до семнадцати на документ.
Выглядело это, если честно, как разгром. Вот реальные формулировки (я их слегка перефразировал, но дух сохранён):
«Откуда такая оценка?»
«Источник?»
«Нет такой опции в брифе»
«Нет такой опции в брифе» (другой абзац)
«Нет такой опции в брифе» (третий)
«Мимо»
Отдельные были развёрнутыми и болезненно точными:
«Вывод о реализуемости 9 из 10 перенесён из предварительного скоринга как установленный факт. Фактическая загрузка команды, инфраструктура и ресурсы не подтверждены»
«Утверждение "проект невозможен без GPU" противоречит рекомендуемому в этом же документе варианту с CPU-инференсом»
«Точные сроки, штрафы, проценты и цены лицензий не имеют источников»
Последний вообще вошёл в личный зал славы:
«Сроки и обязательства включены вопреки назначению справки»
То есть документ не просто содержал ошибки — он местами не понимал собственного жанра.
Можно было обидеться. Можно было сесть и молча всё поправить — что я в первый момент и начал делать. Но на третьем документе стало видно то, что видно на любом достаточно большом логе ошибок: они повторяются.
Комментарии — это данные. Достаём их
Замечания жили в .docx как обычные вордовские комментарии. Мало кто помнит, но .docx — это zip, и комментарии в нём лежат отдельным XML-файлом word/comments.xml, с автором, датой и привязкой к тексту. Достаются они скучным скриптом без единой зависимости:
import zipfile import xml.etree.ElementTree as ET W = "{http://schemas.openxmlformats.org/wordprocessingml/2006/main}" def extract_comments(path): with zipfile.ZipFile(path) as z: if "word/comments.xml" not in z.namelist(): return [] root = ET.fromstring(z.read("word/comments.xml")) result = [] for c in root.findall(f"{W}comment"): author = c.get(f"{W}author", "?") date = c.get(f"{W}date", "?") text = "".join(t.text or "" for t in c.iter(f"{W}t")).strip() result.append((author, date, text)) return result
Прогнал по всем файлам, собрал в один маркдаун: документ → комментарии → к какому фрагменту привязаны. Получился аккуратный корпус: 73 записи, один автор, одна дата.
Кстати, привязка к фрагменту важна не меньше текста комментария. «Источник?» сам по себе бесполезен; «Источник?» напротив фразы «обработка займёт 40 минут» — уже обучающий пример.
Кластеризация: 73 → 16 → 6
Дальше корпус поехал в LLM с примерно таким промптом:
Вот все замечания рецензента к девяти документам одного типа, с фрагментами текста, к которым они привязаны. Задача — не пересказать их, а найти СИСТЕМУ: 1. Сгруппируй замечания в повторяющиеся паттерны. Паттерн = одна и та же претензия к разным местам разных документов. 2. Для каждого паттерна сформулируй ПРАВИЛО САМОПРОВЕРКИ — императив, по которому можно проверить черновик ДО отправки. 3. Правило должно быть проверяемым: не «пиши лучше», а «каждое число имеет источник или помечено как допущение». 4. Отдельно выпиши замечания, которые НЕ легли ни в один паттерн, — их нельзя терять молча. 5. Ранжируй паттерны по частоте.
Пункт 4 — самый важный в этом промпте. LLM обожает натянуть всё на красивую схему; явное требование «покажи остаток» — единственное известное мне противоядие. Остаток, кстати, был: несколько замечаний оказались разовыми и в чек-лист не пошли.
Из 73 комментариев получилось 16 паттернов в шести группах. Привожу целиком, потому что подозреваю: они не только про мои справки.
A. Верность источнику
Не выходить за бриф. Если заказчик просил инструмент для внутренних специалистов, в документе не должно появиться мобильное приложение для граждан — даже если оно логично напрашивается. Три комментария «нет такой опции в брифе» — это всё сюда.
Термины — ровно из брифа. В брифе «контролируемая среда» — значит, в справке не «изолированная». Синоним кажется безобидным, пока не оказывается термином с другим юридическим смыслом.
B. Доказательность
Каждое оценочное суждение — либо с источником и расчётом, либо с явной пометкой «допущение». Особый подвид: оценки из предварительных прикидок («реализуемость 9/10») нельзя проносить в документ как установленный факт.
Каждое число — с источником и датой. Сроки, объёмы, цены, проценты. Нет источника — есть пометка.
Не давать обязательств там, где документ их давать не должен. Сроки, стек, объёмы датасетов — это гипотезы до подтверждения прототипом, и называться они должны гипотезами.
Метрики — раздельно по компонентам. «Точность системы 90%» не значит ничего, если внутри распознавание, извлечение и классификация с разными профилями ошибок.
C. Границы компетенций
Матрица вместо самооценки. Не «команда потянет», а таблица: компонент → кто делает → кто в организации держатель этой экспертизы → чем подтверждена его доступность.
Сначала внутренние платформы, потом внешние. Если в организации уже есть готовый движок под задачу — он в приоритете, с честным разбором плюсов и минусов, а не молчаливым игнором.
Переиспользование существующих наработок — обязательный вариант. «Собрать с нуля» без рассмотрения reuse — красный флаг.
Не завышать сложность своей части. Если ваша роль — API и оркестрация поверх готовой модели, не нужно писать про найм команды компьютерного зрения.
D. Архитектурные развилки
Никогда не фиксироваться на одном стеке. Не «делаем на YOLO», а набор проверяемых вариантов: готовая внутренняя модель / rule engine / внешний подряд / вообще без обучения. С условиями выбора: «если есть X, то...; если нет — то...».
Ноль внутренних противоречий. Документ, который на странице 3 объявляет проект невозможным без GPU, а на странице 5 рекомендует CPU-вариант, не переживёт первого внимательного читателя.
Рыночные выводы проверять самому. «Аналогов нет» из брифа — это позиция брифа. Пять минут поиска обычно находят три аналога, и уникальность оказывается не в технологии, а в контуре внедрения.
E. Глубина вопросов
Вопросы к заказчику должны менять решение. «Уточнить требования» — не вопрос. Вопрос — это «кто юридически владеет данными, на которых мы собираемся обучаться, и есть ли право передачи их подрядчику».
Регуляторику не трактовать прямолинейно. Ни автоматическое «персональных данных нет — защита не нужна», ни перестраховочное «всё запрещено». Квалифицировать данные и выносить в явный вопрос профильному подразделению.
F. Этапность
Stage-gate между фазами. Переход от MVP к полной версии — не по календарю, а по критериям: что должно быть подтверждено (эффект пилота, согласование безопасности, метрики выше порога), чтобы двигаться дальше.
Момент, ради которого стоило это делать
Разложив 73 замечания по 16 полкам, я увидел то, чего не видел за отдельными правками.
Почти ни одно замечание не было про предметную область. Руководитель не спорил с выбором модели и не поправлял мою оценку сложности OCR. Претензии были эпистемологические — к статусу утверждений: откуда ты это знаешь? это факт или мнение? если мнение — почему оно выглядит как факт?
И вот тут пазл сошёлся. Документы-то собирает LLM. А LLM генерирует текст с равномерной уверенностью: факт из брифа, экспертная оценка и чистая экстраполяция выходят из неё одинаково гладкими, в одном тоне, без швов. Человек, когда пишет, невольно маркирует сомнение — «по всей видимости», «навскидку», «надо проверить». Модель — нет. Она пишет «обычного сервера будет достаточно» с той же интонацией, что и «в брифе указано 10 000 документов в месяц».
Опытный рецензент детектирует эту немаркированную уверенность мгновенно. По сути, все 73 комментария — один комментарий, повторённый 73 раза: «покажи статус этого утверждения».
Чиним систему, а не документы
Дальше три изменения в пайплайне.
1. Маркировка источника у каждого утверждения
Теперь каждое содержательное утверждение в документе несёт явную метку:
[Б] — факт из брифа или приложенных документов, с указанием источника;
[Э] — экспертная оценка, с коротким обоснованием;
[Д] — допущение, требующее проверки. Все [Д] дополнительно собираются в отдельный раздел «что нужно подтвердить до старта».
Было:
Для обработки потока достаточно одного сервера без GPU.
Стало:
Для обработки заявленного потока (10 000 документов/мес [Б: бриф, п. 3]) предположительно достаточно одного CPU-сервера [Д: требует нагрузочного прототипа на репрезентативной выборке].
Звучит менее уверенно? Да. В этом и смысл. Документ, который знает границы своего знания, читается медленнее, а принимается быстрее.
2. Чек-лист как этап конвейера
16 правил стали буквально этапом пайплайна: после сборки черновика отдельный проход агента прогоняет текст по всем пунктам и выдаёт таблицу: правило → нарушения → где. Нарушения чинятся до того, как документ увидит человек.
Это не «попросить модель проверить себя» в одном промпте с генерацией — так не работает, проверяющий контекст должен быть чистым. Отдельный вызов, на входе только текст черновика и чек-лист, на выходе — структурированный отчёт.
3. Чек-лист в постоянной памяти агента
Самое важное — правила легли не в проектную папку, а в постоянную память агента, которая подтягивается в любую сессию. У большинства агентных инструментов сейчас есть такой механизм (файлы памяти, инструкции проекта — названия разные, суть одна). Теперь при работе над любым документом этого типа правила уже в контексте — их не нужно вспоминать, вставлять руками или надеяться, что я не забуду.
Фактически у рецензента появился цифровой двойник, который успевает к черновику раньше него.
Результат
Следующая партия — четыре документа за две недели — ушла и была принята без замечаний по старым паттернам. Ноль повторов из тех шестнадцати.
Замечания вообще? Были, по делу, новые — по содержанию конкретных проектов, там, где рецензент реально незаменим. Исчез именно повторяющийся слой: «источник?», «откуда цифра?», «нет в брифе».
Честные оговорки, куда без них:
Выборка маленькая. Четыре документа — это четыре документа. Может, мне попались простые проекты. Ещё через десять будет видно.
«С первого раза» из заголовка — про отсутствие итераций правок, а не про то, что рецензент перестал читать. Читает. Просто теперь его проход по документу не превращается в археологию одних и тех же ошибок.
Часть эффекта — не от чек-листа, а от маркировки [Б]/[Э]/[Д] как таковой. Подозреваю, она сместила и восприятие: документ, который сам сдаёт свои слабые места, вызывает другой уровень доверия, чем документ, в котором слабые места надо искать.
Это вообще честно?
Предвижу комментарий: «то есть ты натренировался обходить конкретного проверяющего».
Нет — и разница принципиальная.
Замечания хорошего рецензента — это не его вкусовщина. Это несформализованный стандарт качества, который существует у него в голове и нигде больше. В нормальном мире такой стандарт передаётся годами: джун получает правки, обижается, привыкает, через три года сам ставит те же правки следующему джуну. Изустная традиция, как в средневековом цехе.
Я эту традицию просто записал. 73 комментария оказались достаточной обучающей выборкой, чтобы извлечь стандарт почти целиком — не потому что LLM гениальна, а потому что хороший рецензент систематичен: он не выдумывает новые претензии к каждому документу, он последовательно применяет одни и те же принципы.
Руководитель, к слову, в курсе и не против: его стандарт теперь применяется до него, а не вместо него. Время его ревью тратится на то, что действительно требует его головы.
Тест на честность здесь простой: стало бы хуже, если бы про схему узнали все? Очевидно нет — стало лучше: стандарт из головы одного человека превратился в артефакт, доступный каждому. Это ровно то, что произошло с код-ревью, когда типовые придирки уехали в линтеры, а люди остались думать об архитектуре.
Как повторить у себя
Рецепт короткий, инструментонезависимый:
Соберите корпус. Комментарии из .docx (скрипт выше), из pull request'ов через API, из переписки — что есть. Важно сохранить привязку: не только «что сказали», но и «к какому фрагменту».
Кластеризуйте с LLM. Промпт из статьи как отправная точка. Обязательно требуйте выделить остаток — замечания вне паттернов.
Каждый паттерн переформулируйте в проверяемое правило. Императив + признак нарушения. «Писать понятнее» — не правило. «Каждая аббревиатура раскрыта при первом употреблении» — правило.
Вшейте туда, где правила не смогут потеряться. Постоянная память агента, инструкции проекта, шаблон документа, pre-commit — по вкусу. Правило, которое нужно вспоминать, не работает.
Прогоняйте проверку отдельным вызовом, а не в том же промпте, что генерация. Генератор не видит своих ошибок — это верно и для людей, и для моделей.
И один неочевидный совет: не выбрасывайте остаток из шага 2. Замечания, которые не легли в паттерны, — это либо будущие паттерны (мало данных), либо то самое незаменимое экспертное, что автоматизации не подлежит. И то и другое стоит знать в лицо.
Вместо вывода
Есть старая истина: хороший ревьюер ценен не тем, что находит ошибки, а тем, что распространяет стандарт. Ошибки в конкретном документе умирают вместе с документом. Стандарт остаётся и работает дальше.
Проблема была в том, что стандарт жил только в головах и передавался только через боль — итерациями правок, от человека к человеку, с потерями. LLM неожиданно оказалась инструментом решения ровно этой проблемы: 73 разрозненных комментария за вечер превратились в артефакт, который можно версионировать, передавать и исполнять машинно.
Мой руководитель потратил день на 73 комментария. Это был последний раз, когда ему пришлось писать их все.
Лучшая благодарность рецензенту — не исправить замечания. Лучшая благодарность — сделать так, чтобы он больше никогда не писал их снова.
