В посте про Hermes я рассказывал, как у «второго мозга» появилась вторая голова — Ви, агент в облаке, с которым я общаюсь через Telegram. Ви знает, кто я, чем занимаюсь и какие у меня проекты.
Но знает довольно своеобразно.
Записная книжка вместо памяти
У языковой модели нет памяти в человеческом смысле. Есть контекстное окно — рабочий стол, на который выкладываются текущий разговор, документы и инструкции. Что не лежит на столе, того для модели не существует. Закончилась сессия — стол убрали.
Чтобы агент не знакомился с тобой каждое утро заново, у Hermes есть встроенная память. Устроена она как записная книжка: записал факт — достал факт. Для «Константин пьёт кофе без сахара» хватает. А вот найти запись по смыслу, разложить память по темам или держать под рукой библиотеку документов записная книжка не умеет. Скормить агенту все заметки целиком тоже не выйдет: файлы памяти не резиновые.
Провайдер памяти
Hermes умеет подключать внешних провайдеров памяти. Это отдельная база, которая работает рядом с агентом: агент думает и действует, база обеспечивает хранение, категоризацию и поиск. Как если бы к сотруднику с хорошими навыками анализа и синтеза знаний приставили библиотекаря.
Я выбрал OpenViking — open-source проект Volcengine. Не хотелось, чтобы моя память уезжала куда-то в облака, учитывая нынешнюю нестабильность коммуникаций, так что выбирал из того, что можно развернуть локально.
Что он умеет, если по-человечески:
- Семантический поиск (по смыслу). Как он устроен, я разбирал в посте про цитаты. Тогда пришлось колхозить своё решение, тут он уже встроен. Но подключить по-нормальному получилось не сразу.
- Трёхслойная индексация. У каждого документа три уровня: одно предложение «о чём это», обзор на страницу и полный текст. Агент пролистывает аннотации, у четырёх-пяти читает обзор и целиком открывает один-два документа. Экономия контекста. Современные модели умеют искать нужное без чтения файлов целиком, но без семантического поиска это не так эффективно.
- Из разговора выделяются знания. При переключении, завершении сессий, а также при накоплении большого объёма контекста включается механизм асинхронного извлечения значимых фактов и рабочих договорённостей в долговременную память.
- Категоризированная память. Без категоризации память похожа на длинную переписку: чтобы вспомнить предпочтение или решение, нужно заново искать и понимать его среди множества реплик. Категории задают структуру и назначение информации. Также есть механизм связей между категорями, сессиями и связанными документами.
Условный пример:
| Сказано в разговоре | Категория |
|---|---|
| «Я работаю архитектором» | профиль |
| «Пью кофе без сахара» | предпочтения |
| «Новый проект — Ребрендинг снапшотов в бэкапы» | сущности: проекты, люди и т.д. |
| «Сегодня решили перенести запуск» | события и решения |
| «Этот подход не работает» | опыт |
Разовая проверка эффективности показала, что
69 из 84 обращений к памяти — не поиск, а прямой URI: browse по категориям (46) и read по конкретному файлу (23)
— Ви
Пример использования в рабочем контексте
Как сказано выше, к OpenViking можно подключать ресурсы — директории или git-репозитории с документами для семантического поиска. Что мог придумать библиоманьяк, обнаружив такой механизм в своей песочнице? Правильно, сделать базу знаний на основе книг. Рассудив, что не на базе всех вообще книг, а хотя бы на одной категории — техническая литература.
Оказалось, книгу целиком в базу не загрузишь: индексация падала уже на средних заметках. Её нужно разобрать на небольшие документы по главам. Для этого я написал маленький инструмент ovbook. EPUB и FB2 он разбирает по собственной разметке книги: оглавление, разделы. С PDF сложнее, разметки там часто нет, и заголовки пришлось угадывать по шрифту: строка заметно крупнее основного текста — скорее всего, начало главы. Не все PDF читабельны для агента, так что некоторые пришлось распознавать через OCR. После этого — чистка мусора: колонтитулы, служебные страницы, кракозябры после распознавания. На выходе каждая глава лежит отдельным md-файлом рядом с карточкой книги.
Для проверки я накидал туда несколько книг: «Чистую архитектуру», учебники по ООП и Python, «Пользовательские истории» Паттона, «Системное мышление». И тут сама модель обратила моё внимание на один момент. Базовые темы — ООП, синтаксис языка, лучшие практики — она знает и так. Уверенно галлюцинирует она в другом: в хардкорных описаниях механизмов, протоколов и особенностей реализации конкретных решений. Там она сочиняет детали, которые звучат правдоподобно.
У библиотеки немного поменялся профиль. В неё пошли всякие спецификации Fibre Channel, SCSI, архитектура SAS, дедупликация в высокопроизводительных хранилищах.
Дальше нашлось логичное прикладное применение. В работе я использовал конвейер, в котором ИИ-агенты по краткому описанию фичи и моим ответам на вопросы готовили продуктовую документацию: требования (PRD), критерии готовности, архитектурный набросок. В каждом PRD есть раздел анализ конкурентов, и было бы логично, чтобы агент сам находил похожий функционал у AWS и Google Cloud. Причём опирался на их документацию, а не на свои представления о том, как они могли бы это сделать.
К концу июля в ov-lib было 22 источника и 4527 файлов, примерно 95% — документация AWS и Google Cloud. Справочник API Amazon EC2 пришлось не просто нарезать, а прям нашинковать: по файлу на каждый из 1376 методов.
Как это использовалось
Я пишу короткий бриф: что за фича, зачем, контекст, ожидаемый результат, что в скоупе. Суть такая: дать пользователю возможность создавать диски, зашифрованные собственным ключом из сервиса управления ключами (KMS), а не системным ключом платформы. Это нужно банкам, медицине, госу: ротация по своему графику, отзыв ключа — данные недоступны, аудит использования.
Дальше работает конвейер. Первым идёт агент-аналитик. В его промпте прописан порядок исследования: подключить инструменты OpenViking, прочитать оглавление и глоссарий базы знаний, искать по ключевым терминам из брифа, читать найденное. ov-lib подключена к тому же OpenViking как ресурс, так что поиск захватывает и документацию облаков.
Шаг 1. Термины из брифа уходят в поиск по смыслу: «шифрование дисков», «ключ клиента», «отзыв ключа».
Шаг 2. Аннотации. Возвращается десяток однострочных описаний — пара сотен слов вместо тысяч страниц:
gcp-compute-engine-docs/disks/customer-managed-encryption— шифрование дисков и снимков ключами клиента в Cloud KMSgcp-compute-engine-docs/disks/customer-supplied-encryption— шифрование ключом, который клиент передаёт самgcp-compute-engine-docs/disks/disk-encryption— обзор вариантов шифрования дисковamazon-elastic-compute-cloud-api-reference/535-modifyebsdefaultkmskeyid— смена ключа шифрования по умолчаниюamazon-elastic-compute-cloud-api-reference/443-enableebsencryptionbydefault— включение шифрования по умолчаниюamazon-elastic-compute-cloud-api-reference/141-createvolume— создание диска, в том числе с указанием ключа- …
Шаг 3. Обзоры и полный текст. Обзоры — у пяти подходящих, целиком — два документа.
Шаг 4. После моих уточнений пишет PRD. В разделе «Анализ конкурентов» появляется:
AWS. В каждом регионе есть ключ, которым диски шифруются по умолчанию; клиент может заменить его своим. Поддерживаются только симметричные ключи. Если клиент удалит или отключит свой ключ, новые виртуальные машины перестанут запускаться. (EC2 API Reference, ModifyEbsDefaultKmsKeyId)
Google Cloud. Своими ключами шифруются диски, образы машин и снимки дисков. Сервис ключей можно держать в том же проекте, что и машины, или в отдельном. Есть второй вариант — клиент передаёт ключ сам, без сервиса ключей. (Compute Engine docs, customer-managed-encryption, customer-supplied-encryption)
Последний шаг — ровно то, ради чего всё затевалось.
Чем закончилось
В июле закончилась моя работа в MWS. Вместе с ней ушли бесплатные ресурсы песочницы, в которой жили Ви и OpenViking, потребность анализировать документацию конкурентов и доход. Пришлось перейти в режим экономии. Ви переехала в другое облако, сетап урезан до необходимого, OpenViking пока там не поднимал. Конвертер и ov-lib лежат на GitHub: вернётся задача — будет с чего начать.
Выводы
Агенту можно расширить память. Встроенной хватает, чтобы он знал, как тебя зовут и как ты предпочитаешь общаться. Провайдер памяти значительно увеличивает её (памяти) возможности.
Сам «второй мозг» — Obsidian-хранилище с заметками — по сути, тоже является расширением памяти агента, потому и называется «вторым мозгом». Но провайдеры памяти — как импланты — добавляют возможности и снижают затраты (время, контекст, токены).
Наполнять базу знаний стоит тем, чего модель не знает. Учебники по Python ей не нужны. Нужна документация, в которой она без источника начнёт фантазировать.
