"Бесит. Вот пришла мне в голову идея, я хожу с ней, обдумываю, но стоит выйти в другую комнату - и всё, ЗАБЫЛ. Приходится возвращаться на старое место, в знакомую обстановку. Иногда это помогает, но никаких гарантий. С нейросетями в длинных проектах происходит нечто похожее. Мои студенты, работающие с большими массивами файлов - главным образом с медицинскими и юридическими кейсами - удивляются: коворк может несколько раз за день попросить перезапустить рабочую среду, а новый чат внутри проекта не воспроизводит содержание предыдущих диалогов во всех подробностях. «Не могут же обновления выходить по десять раз на дню?» Не могут. Просто снаружи не видны несколько системных ограничений, которые напрямую влияют на производительность и качество результата. Контекст конечен. Модель одновременно видит ограниченный объём информации. В затяжной работе ранние детали сворачиваются в пересказ, пересказ теряет нюансы, и в какой-то момент мы уже жонглируем обмылками прежних выводов. Проектная память помогает, но она не равна полному протоколу предыдущей работы. Рабочая среда тоже конечна. Код выполняется в изолированной среде с ограниченным диском. Место занимают не только исходники, но и система, библиотеки, распакованные архивы, изображения страниц, результаты OCR, кэш и временные файлы. Каталог на 10 ГБ в процессе обработки легко может породить в несколько раз больше данных. Переполнение диска - одна из частых причин отказа рабочей среды, хотя не единственная. Доступ к файлам проходит через слой разрешений. Коворк видит только подключённые папки, а файловые операции проверяются отдельно. Различия в абсолютных путях, ссылках, юникоде и канонической форме пути могут привести к парадоксу: один вариант пути читается, другой не записывается. У меня, например, имя пользователя Windows было записано кириллицей, и один из элементов инструментальной цепочки постоянно ошибался при работе с этим путём. В итоге оказалось проще завести отдельного пользователя с латинским именем. Отдельные команды имеют таймауты. Долгая обработка не должна зависеть от одного инструментального вызова. Её нужно разбивать на этапы, запускать как отдельный процесс и регулярно сохранять прогресс. Иначе программа может выполнить почти всю работу, упасть на последней операции, и не оставить результата. Модель не ведёт строгую базу доказательств автоматически. Она строит наиболее правдоподобное продолжение текста. Если раннее ошибочное утверждение попало в контекст, оно начинает влиять на следующие выводы и постепенно размножает мусор. 🏥 Как это лечить: 1. Для больших локальных архивов перенести основной конвейер в Клод Код. Это не устранит ограничения памяти и ошибки модели, но даст прямой доступ к файловой системе, управляемые процессы, журналы, возобновляемые сессии и контроль над промежуточными результатами. 2. До начала анализа создать структуру проекта в папках и файлах. 3. Провести программную инвентаризацию архива: пути, типы, размеры, хеши и статусы обработки. 4. Отделить извлечение данных от их смыслового анализа. 5. Не ставить задач типа ""прочитай 4200 файлов"", а сначала поручить AI построить воспроизводимый конвейер, обрабатывающий небольшие партии и продолжающий работу после сбоя. 6. Строить сводку из утверждений, связанных с конкретными источниками и страницами. Противоречия не сглаживать, а маркировать. 8. Вести журнал ошибок и очередь документов, которые требуют повторной или ручной проверки. 🫡Но главное здесь - не конкретный продукт, а проектная дисциплина. Перед тем как ворваться в новый проект, стоит остановиться, выдохнуть и вернуться на два шага назад: сначала спроектировать процесс, а уже потом запускать обработку. Для большой работы заранее выяснить объём, стоимость, формат результата, критерии готовности, допустимый уровень ошибок и то, чем можно пожертвовать при нехватке времени. Иными словами: чем мощнее агент, тем важнее не просто дать ему задачу, а построить среду, в которой ошибки обнаруживаются, работа возобновляется, а каждый вывод можно проверить."