Хватит объяснять себя заново каждый день
Если вам нужна инструкция, а не эссе. Вся настройка, о которой идёт речь в этой серии, расписана по шагам в отдельном гайде — то же самое, но как процедура, которую можно выполнить, а не рассуждение, которое надо прочитать.
Первая часть была о том, до чего дотягиваются ИИ-агенты на моём ноутбуке и какой контейнер не даёт им дотянуться дальше. Вторая — о том, во что этот контейнер мне обходится. Эта часть — о тревоге, которая на самом деле стоит денег и часов, и которую я починила бы первой, начиная заново: я объясняю один и тот же проект каждый божий день.
Короткий пересказ для тех, кто попал сюда первым делом. Я не инженер. Последние полтора года я строю настоящие вещи с кодинг-агентами, и техническая обвязка вокруг них — как раз то, чего вам никто не даёт: каждый продукт документирует свои настройки, и никто не документирует, каково жить с этой комбинацией месяцами. Речь о домашней настройке, для личных проектов, на одном ноутбуке.
Рядом с этими тремя частями есть две рабочие заметки, опубликованные незаконченными, потому что оба эксперимента идут прямо сейчас: библиотека навыков, которой я пользуюсь и попытка собрать помощника, который держит все проекты сразу. Ни одна не завершена, и мне важнее показать их состояние, чем ждать.
Задача, сформулированная как следует
На большом проекте контекст и есть работа. Какие решения уже приняты и почему. Что мы пробовали в марте и что из этого не сработало. Который из четырёх объектов, называемых «пайплайн», я имею в виду на этот раз. От какого подхода я отказалась и по хорошей ли причине.
Перепечатывать всё это в каждую новую сессию дорого в токенах и заметно дороже в моём собственном времени. И есть провал похуже, чем цена: каждый раз я пересказывала бы чуть иначе. А значит, агент действовал бы — уверенно, всегда уверенно — исходя из версии моего проекта, которой никогда не существовало. Это не галлюцинация. Это мои собственные несогласованные пересказы, добросовестно исполненные.
Я дважды починила это неправильно, прежде чем сделать правильно, и оба неверных поворота поучительнее ответа.
Попытка первая: сохранять всё
Очевидное лекарство от повторных объяснений — записывать всё. Так я и сделала: каждый разговор выгружался и индексировался в локальное векторное хранилище (MemPalace, работает целиком на машине — без ключа к API, ничего не уходит с ноутбука), а агент искал по нему в начале каждой сессии.
Это не работает, и проваливается так, что легко принять за проблему настройки. Каждая сессия начиналась с того, что токены сгорали на поиске ещё до всякой работы. Хуже того, возвращалась болтовня: недодуманные идеи, подход, от которого я отказалась через две недели, мой собственный сбивчивый первый заход на задачу, которую я с тех пор решила. Агент не мог отличить актуальное от неактуального, и поиск не мог, потому что релевантность и актуальность — разные вещи, а векторный поиск знает только про первую.
Я заменила повторные объяснения повторным чтением. Это хуже. Когда я объясняю сама, я хотя бы знаю, что сегодня это правда.
Урок, насколько прямо я могу его сформулировать: архив разговоров — это свидетельство, а не рабочая память. Он по-настоящему ценен для вопроса «когда мы это решили?», для восстановления потерянного, для разбирательств. Он не заменяет знание о том, как обстоят дела.
Попытка вторая: вики, которую ведёт агент
Работает же небольшой, намеренно составленный набор страниц, который агент читает в начале каждой сессии: текущее состояние, архитектура, решения с обоснованиями, рабочие процессы, эксплуатация, бэклог, извлечённые уроки. Плюс страница-указатель со списком того, что есть, — чтобы читать выборочно, а не заглатывать всё.
У этого приёма есть имя: Андрей Карпаты в апреле этого года опубликовал спецификацию «LLM Wiki», описывающую более или менее ровно это — сырые источники остаются неизменными, поверх них модель пишет и ведёт слой вики, а файл схемы задаёт соглашения. Его рамка в том, что знание надо компилировать со временем, как код, а не доставать по запросу. Я нащупывала это вслепую и путалась в деталях; именно его версия заставила меня перестать считать поиск целью.
Что я добавила сверху, если это чего-то стоит: письменные контракты рабочих процессов и журнал. Журнал оказался важнее, чем я ожидала, — это разница между «в вики написано X» и «в вики написано X, изменено такого-то числа, вот почему».
Различение, после которого всё встало на места:
| Векторное хранилище | Вики | |
|---|---|---|
| Откуда берётся | Автоматически, из файлов и расшифровок | Пишется намеренно, мной или агентом |
| На какой вопрос отвечает | «Где это упоминалось?» | «Как обстоят дела прямо сейчас?» |
| Как попадает в контекст | Никогда целиком — только результаты поиска | Целиком, каждую сессию |
Как только эти двое разделены, проблема с токенами растворяется. То, что попадает в контекст, мало́ и отобрано. То, что огромно, ищется — редко и осознанно.
Ещё одна деталь: формальные схемы процессов я держу, но агенты работают не по ним. Они работают по письменному контракту: шаги, точки контроля, ветвления, кто что решает, где остановиться и спросить. В схемах модели теряют детали: исчезает точка согласования, две ветки сливаются в одну, испаряется разница между «решает оркестратор» и «делает подзадача». Схема — для меня. Контракт — для агента.
Есть версия всего этого, вообще не про код, и её я показала бы не-инженеру первой. Та же структура работает для самой настройки: у меня есть проект, всё содержимое которого — как устроена моя среда и почему, и когда что-то ломается, работающий в нём агент уже знает историю, а не гадает. Годится любая область, где вам иначе пришлось бы объяснять себя заново.
Две истории про отладку
Поиск, который работал только по-английски. Качество поиска скакало так, что я не могла ухватить закономерность, поэтому поставила контролируемый опыт: тот же индекс, тот же проект, тот же вопрос, заданный один раз по-русски и один раз по-английски.
| Проект | Язык запроса | Близость | Результат |
|---|---|---|---|
| Первый | Русский | 0,58 | Мимо |
| Первый | Английский | 0,65 | Точный ответ |
| Второй | Английский | 0,885 | Точный ответ |
| Второй | Русский | 0,76 | Мимо |
Решающая деталь: во втором проекте русский запрос не нашёл заметку, написанную по-русски, которую английский запрос нашёл сразу. Это не проблема данных. Индекс был построен на модели эмбеддингов по умолчанию, обученной только на английском, — её собственная документация оценивает межъязыковую близость примерно в 0,35 против примерно 0,88 у многоязычной модели. Основная часть моего материала на русском. Я построила русскоязычную базу знаний на англоязычном индексе и несколько недель винила свои заметки.
Вывод, который я уже сделала — неправильно. До этого опыта я уверенно записала, что файлы проекта индексируются хорошо, а разговоры плохо, и начала на этом строить планы. Это было неверно. Один проект я проверяла по-английски, другой по-русски, так что «файлы против разговоров» с самого начала было спутано с языком запроса. Главной переменной был язык вопроса, а режим сбора — шумом.
Я оставляю это здесь, потому что обычно такое тихо удаляют. Если у вас плохо ищется, проверьте, на каких языках обучалась ваша модель эмбеддингов, прежде чем что-то перепроектировать. А если вы сделали вывод из двух опытов, отличавшихся больше чем одним, вы не сделали вывода.
Три правила, которые переносятся
Всегда ищите с фильтром по проекту. Без него отвечают сразу пять несвязанных проектов, и лучший результат уверенно приходит из чужой вселенной.
Измерьте корпус, прежде чем его индексировать. Я чуть не проиндексировала большую папку в облаке, ориентируясь на её размер в гигабайтах. Картинки, видео и архивы не индексируются вовсе, так что реального текста там была малая доля. Сначала посчитайте файлы по расширениям, потом решайте.
Оригиналы не переезжают. Индексация читает файл на месте, извлекает текст в памяти, сохраняет фрагмент, вектор и путь. Копировать всё в одну центральную папку незачем, а я спроектировала такую, не проверив. Это «озеро» было бы чистыми расходами на обслуживание.
Чего память так и не решила
Всё описанное работает внутри одного проекта. Чего у меня нет — так это помощника, который держит все проекты разом: что в приоритете, что заблокировано, что я три недели назад обещала сделать по проекту, который с тех пор не открывала. Кодинг-агенты прекрасны внутри репозитория и понятия не имеют, что есть ещё четыре.
Несколько недель я тестировала оркестратор, сделанный ровно для этого, — меня привлекла его слоистая модель памяти, — и упаковала его в контейнер так же, как всё остальное. Промежуточный результат честный и незаконченный: хорош в узких разовых исследованиях, не то, на что я надеялась, а половина про делегирование намеренно выключена, пока я не спроектирую вокруг неё точки подтверждения.
У этого эксперимента своя рабочая заметка — попытка собрать личного администратора, опубликованная как заметки, а не как выводы, потому что выводов пока нет. Вопрос, который она оставляет открытым, мне и хотелось бы закрыть больше всего: что вы используете как помощника поверх проектов, если не хотите быть привязанным к подписке одного поставщика?
Что я сказала бы себе в начале
Повторные объяснения: в основном решено, и на это ушли две неверные попытки. Вики читается каждую сессию и обычно оказывается права. Её всё ещё сносит, когда я тороплюсь и не записываю, — но это проблема дисциплины, а не архитектуры.
Остальное, сжато:
- Архив — это свидетельство, а не память.
- То, что попадает в контекст, должно быть маленьким и отобранным. То, что огромно, должно искаться — редко и осознанно.
- Проверьте языки обучения своей модели эмбеддингов, прежде чем винить данные.
- Если два опыта отличались больше чем одной переменной, результата у вас нет.
- Всегда ищите с фильтром по проекту.
- Измерьте корпус, прежде чем его индексировать.
- Ведите журнал, а не только состояние. «Изменено такого-то числа, вот почему» стоит больше самого факта.
- Прямо называть то, что вы не решили, — часть системы, а не признание в слабости.
И то, что я больше всего хотела бы передать себе назад: сначала соберите маленькую вики, а поиск добавьте потом, когда поймёте, что вы на самом деле ищете. Я построила дорогое первым, и дорогое оказалось не той формы.
Источники и кого стоит читать
- Андрей Карпаты, LLM Wiki — приём, на котором держится вся эта часть: сырые источники остаются неизменными, вики компилируется поверх них, и знание накапливается, а не достаётся заново каждый раз. Если читать из этого списка что-то одно, читайте это.
- MemPalace — локальное векторное хранилище и архив разговоров, которые я использую как холодный слой. Работает на машине, ключ к API не нужен.