Мышление AI-письмом/моделированием/кодированием/онтологизированием и архитектуры AI-экзокортексов.

В апреле 2020 я сделал два программных поста: -- мышление письмом/моделированием, https://ailev.livejournal.com/1513051.html. Этот пост оказался удивительно популярным, и это "мышление письмом" широко практикуется у нас в мастерской инженеров-менеджеров. -- Мышление кодированием в IDE, мышление письмом в IWE, https://ailev.livejournal.com/1515735.html. Этот пост оказался менее популярным, вывод был в том, что в 2020 году ещё не было Obsidian как основы для собственного zettelkasten/wiki. Инструментальная часть текстописания с поддержкой zettelkasten обозначилась словом "экзокортекс", и лениво обсуждается в одноимённом чате https://t.me/exocortexssm (сейчас там чуть больше пятисот человек, "Группа для обсуждения инструментария усиления мышления для личного и рабочего использования"). За пять лет изменилось более чем всё: -- у нас появились AI-агенты, которые мыслят за вас кодированием в IDE, моделированием в самых разных моделерах (скажем, в coda.io или даже Excel) и письмом в появляющихся IWE, а ещё появились исследовательские агенты, где главное -- search. Этих агентов много! -- и у них всех, поскольку они стали "мыслить в S1" ну ровно как мы с вами, появилась проблема: искажения при редактировании, то есть искажения при agile процессе познания. Выдвижение гипотез, обоснование доказательствами и экспериментом, доработка гипотез, и т.д. А S2 у них нету, оно "внешнее", в обвязке. Все эти агенты суть одно и то же: поддержка agile работы со знаниями (моделями, теориями, текстами, алгоритмами, доказательствами и т.д.). Интересно, что проблемы одни и те же, решаются они примерно одинаково, но поскольку инструменты разные и аудитории разные, то собрать материал об этом очень тяжело. Ну, я собрал некоторое количество материала про деградацию текстов (на естественном языке, на языках программирования и т.д.) в самом разном инструментарии (Cursor тут только один из и хорошо поддерживает отнюдь не все потребные workflow со знаниями). Я с поддержкой группы нежити сделал некоторый обзорчик, за верность которого не ручаюсь ни разу, но зато он дал пищу размышлениям (полный текст на русском -- https://chatgpt.com/s/dr_686008d7d68c819191b2e66776f5e122):

Инструменты для коллективного редактирования точных текстов Аннотация. В техническом писательстве LLM-редактор полезен только тогда, когда гарантирует «без-усадочную» правку: ни одна неизменяемая строка не исчезает, каждая модификация снабжена объяснением и проходит верификацию. Мы сопоставляем «чистые» чаты (GPT-4o, Gemini 2, Claude 4) с системами, обёрнутыми инструментальной логикой (FineEdit, InkSync, Aider, Cursor, Continue) на четырёх открытых бенчмарках — InstrEditBench-25, Can-It-Edit-24, Laziness и Compression-ED. Переход к минимальному diff-формату, двухмодельному циклу Propose → Verify → Merge и CI-diff-тестам повышает точность сохранения текста примерно с 75 % до ≥ 95 % и вдвое сокращает время ручного ревью. Статья излагает пятислойную архитектуру защит (от constrained decoding до чек-сумм), показывает, как её реализуют современные IDE и плагины, и предлагает чек-лист по внедрению в корпоративные стандарты и регламенты. ЧАСТЬ I. Недопустимость "усадки текста" и как её можно измерить -- Сценарии, в которых «усадка» текста недопустима -- Типовые сбои «чистой» LLM-редакции, когда модель работает без дифф-обвязки, без проверки вторым агентом и без пост-тестов -- Как измеряют «съём» и точность LLM-правок -- -- 1 · Корпус с эталонным min-diff -- -- 2 · Lazy / Missing-patch измеряют отдельно -- -- 3 · «Сколько править руками» — Compression ED -- -- 4 · Полевой UX-замер -- -- 5 · Проверка инвариантов через Assertions -- Практический рецепт измерения в своей команде -- Кейсы-сравнения «чистая LLM» vs LLM + обвязка -- Стоимость ошибок, порождаемых «усадкой» и неконтролируемыми правками LLM ЧАСТЬ II. Методы решения на уровне архитектурных паттернов -- Аналогия «S1 / S2 мозга ⇔ LLM / обвязка»: то же самое, но полностью наоборот -- Слой 1. Контролируемое порождение -- Слой 2. Mask-and-infill («редактировать по месту») -- Слой 3. UI- и «физические» блокировки -- Слой 4. Программные гарантии и самопроверка -- Слой 5. Диалоговые протоколы и ревью-циклы -- -- 5.1. Minimal-diff как lingua franca -- -- 5.2. Двухмодельный цикл Propose → Critique → Merge -- Слой 6. Управление длинными контекстами -- Сводка по слоям защиты от деградации текста ЧАСТЬ III Инструментальный ландшафт и практические рецепты -- Редакторы «новой волны» -- IDE-экосистема (VS Code / JetBrains) -- Почему нельзя просто поставить Cursor IDE и считать задачу решённой -- Obsidian-стек -- CI/CD и терминал -- Матрица: паттерн → инструмент -- Результаты на практике -- Практический чек-лист внедрения ЧАСТЬ IV Что ещё осталось сделать — лакуны на конец 2025 г. -- Куда движется рынок -- Чего не хватает во всех обсуждённых "надёжных" инструментов из тех инструментов, которые есть в браузерном UI "чистой LLM" -- -- 1 - Он-лайн-поиск и «глубокое» веб-grounding -- -- 2 - Постоянная память и персональный контекст -- -- 3 - Мультимодальные входы: изображения, голос, файлы -- -- 4 - Расширяемость через плагины и Custom GPT-ы -- -- 5 - Шаринг и коллективная работа «по ссылке» -- -- 6 - Голосовой ввод и аудиовывод -- -- 7 - «One-click» deep research и Canvas-выводы -- -- 8 - Лёгкая мультиязычность и автоперевод -- -- 9 - Функции «плейграунда» и экспериментов -- -- 10 - Интеграция с внешними приложениями (Zapier-стиль) -- Почему так сложилось Заключение Минимальный diff и проверяемые патчи меняют парадигму: вместо «генерируй-всё-заново» LLM становится предсказуемым соавтором, чьи правки точны, объяснимы и ревизуемы. Практика доказывает, что переход к стеку **diff + двухуровневое ревью + assert/CI** повышает сохранность текста c ≈ 75 % до ≥ 95 % и почти на 40 % сокращает трудозатраты редактора.

Текст этот я получил следующим образом: -- позанимался пару дней экспериментами с разными промптами редактирования текстов (это я выполнял программу исследований, которую заявил в "Моих планах на лето", https://ailev.livejournal.com/1768862.html -- там я говорил, что начну с исследования инструментария, вот и начал). Эксперименты показали, что без внешнего по отношению к LLM контуру обработки текста -- никак, LLM всегда обманет. -- далее проделал немаленькую работу, пытаясь разузнать у LLM в чате ответы на мои многочисленные вопросы (я уже знал, что спрашивать). Появился чат, в котором было обсуждено много чего разного. -- далее я предложил сетке сделать аутлайн White Paper и написать отдельные куски по этому аутлайну. -- далее я смотрел на этот аутлайн и задавал вопросы, они приводили к появлению дополнительных кусков текста. Вот шаги процесса (их собрала o3 по всему чату): 1. Формулировка проблемы. Обсудили «усадку» текста, сложности diff-правок, критичные домены (регламенты, код). Первичный список болей LLM-редактирования 2. Сбор сценариев, где риск максимален. Перечислили 7 сфер (eCTD, контракты, код, инженерные wiki, научные статьи, SOC-логи, локализация). Таблица «Сценарии → риск» 3. Инвентаризация типичных сбоев «чистой LLM». Усадка, ленивые ответы, переписывание файла, галлюцинации, формат-loss, обрыв контекста, спуриозность. Таблица «Сбой → описание → источник» 4. Определение метрик и бенчмарков. Разобрали InstrEditBench, Can-It-Edit, Laziness, Compression-ED, UX-Warn/Verify, DSPy Assertions. Таблица классов метрик 5. Квантификация стоимости ошибок. Привели долларовые оценки FDA R2F, исков BigLaw, CISQ, IBM breach, UX-стоимость. Таблица рисков/стоимости 6. Проработали архитектурные решения. 6 слоёв: constrained decoding → mask-infill → UI-lock → assert → diff-протокол → контекст-mgmt. Слоёвая матрица «приём → защита → примеры» 7. Собрали инструментальный ландшафт. FineEdit, InkSync, Cursor, Continue, Windsurf, Cline, Aider, InlineAI + Obsidian, CI-hooks. Таблицы «Редакторы новой волны», «IDE-экосистема», «Obsidian-стек» 8. Составили расширенный аутлайн (20 k зн.). Выстроили структуру: постановка проблемы → методы → инструменты → лакуны → выводы. 20-пунктовый план 9. Заполнили ключевые разделы. Написали: аннотацию, сценарии, сбои, метрики, стоимость, часть II (методы), часть III (инструменты), часть IV (гепы), заключение. Черновой текст разделов 10. Сделали верификационный чек. Сравнили черновик с аутлайном; обнаружили отсутствие «живых» кейсов. Таблица соответствия, отметка пробела 11. Добавили живые примеры. 3 кейса: ГОСТ-абзац, SQL-миграция, Markdown-формула — clean LLM vs LLM+обвязка. Подраздел 4 с цифрами выигрыша 12. Уточнили когнитивную аналогию S1/S2. Перестроили таблицу на 5 колонок (S1, S2, LLM, обвязка) + инверсия эффективности. Новая таблица аналогий 13. Критически оценили Cursor-only подход. Составили список 7 ограничений Cursor (баги на больших файлах, отсутствие факт-чека…). Подраздел «Почему Cursor недостаточен» 14. Выявили, чего нет в “надёжных” IDE, но есть в браузерных LLM-чатах. Поиск/Browse, Memory, мультимодальность, GPT-Store, sharing, voice и т.д.. Таблица недостающих функций 15. Собрали финальную статью. Объединили все разделы, добавили недостающие кейсы, ссылки, оформленные таблицы. Итоговый черновик ≈ 20 k знаков 16. Финальный вывод / рецепт внедрения. 3-пунктовый чек-лист: требовать diff → Reviewer+assert → git-история. Заключение статьи После этого: -- я взял Obsidian и получил там черновик White Paper, просто собрав руками через cut/paste полный текст, но в нём не было литературы. -- я попросил сделать по этому черновику deep research, и o3 поблагодарила меня за предоставленный подробный черновик -- и почти ничего в нём не тронула, зато что-то там поправила и добавила литературу. Вот этот результат я даю я этим постом: release early, release often. Там по факту гибрид: большое количество моих идей (скажем, про S1 и S2 это я просил написать, про "почему нельзя просто поставить Cursor IDE и считать задачу решённой" - тоже я. Но LLM наполнила это всё текстом (конечно, с неизбежными галлюцинациями и искажениями) и привела ссылки на тексты, которые можно почитать по проблеме. -- на этом я оборвал процесс: дальше там нужно делать проверки и правки по итогам проверок. Но сам отчёт показывает, что с инструментами для этого более чем туго (хотя они уже есть). По итогам я долго думал -- и пришёл к выводу, что: -- нужно разобраться с тезисом "Моделирование/программирование/онтологизирование/документирование-в-большом: лаптем или coda.io" (https://ailev.livejournal.com/1578058.html, 2021), перед эти был заход на курс вычислительного мышления как работу с описаниями (программы -- это физические устройства по обработке информации согласно алгоритму, constructors распространяют эту идею на физический мир), это 2020 " Курс вычислительного мышления: надо делать!" https://ailev.livejournal.com/1537388.html, до этого -- "О предмете курса вычислительного мышления", https://ailev.livejournal.com/1477090.html, до этого древний текст 2012 года про информатику как работу агентов (людей и компьютеров) с текстами и кодами, https://ailev.livejournal.com/1008054.html. Всё это, конечно, нашло отражение в тексте "Интеллект-стек". -- но новая волна AI-инструментария показывает, что кроме локальных представлений есть ещё и распределённые представления, и они с обработкой информации с одной стороны справляются, а с другой -- нет. И ещё понятно, что всё там происходящее это часть общего agile процесса разработки описаний, где "всё есть текст", только этот текст разного уровня формальности и мы ему ещё и не очень верим (ибо по пути там на каждом шаге могут быть ошибки). -- чтобы решить проблему с инструментарием обработки чего-то найденного (данных, найденных AI-research agents), неформальных текстов художественных книг, формальных текстов регламентов и договоров, формальных текстов кодов и т.д., надо опять вспомнить, что алгоритмы, доказательства, теории -- это одно и то же, а предметом обсуждения является познание, всё для него. То есть разбираться надо не больше и не меньше, чем с эпистемологией. Для которой нет никакого продвинутого фреймворка, хотя довольно много интересных наблюдений, которые собраны в наших руководствах. Так что я сделал паузу в работе над проблемой инструментария -- и пошёл разбираться в эпистемологии, ибо мне нужно чётко понимать, что там за процесс получения какого-то знания, который поддерживают все эти виды удивительно похожих друг на друга, но таких разных AI-агентов. Нужен язык, позволяющий как-то компактно описывать важное в предметной области обработки информации, язык эпистемологии. Нужна какая-то верхнеуровневая онтология эпистемологии, а если уж совсем обобщать, то гносеологии (кроме научного познания надо же учесть ещё и художественное, религиозное, мифологическое племенное и всякое другое познание). И я занялся эпистемологией, по которой за пару дней в паре с LLM накатал прототип фреймворка на 270Кзнаков в Markdown, да ещё и сразу на английском. И шагов процесса там втрое больше. Там строятся вполне себе безбашенные эпистемологические Нью-Васюки, но рассказ про этот эпистемологический фреймворк уже совсем другая история.