От мечты о RAG-агенте до прототипа VBA: разделение сырых и обработанных данных

План был скромным: создать небольшую версию Merge — личного ИИ-агента. Эксперименты с технологиями RAG, LangChain, LangGraph, эмбеддингами и хранилищами векторов уже велись, и первоначальная идея заключалась в том, чтобы предоставить агенту долгосрочную память и доступ к внутренним документам. Однако появилась другая проблема: управление фриланс-проектами стало хаотичным, что побудило сначала написать небольшой инструмент на VBA. Это казалось простым, но на деле так оказалось не быть. По ходу работы прототип на VBA превратился во что-то другое — в средство для изучения бизнес-логики, которую однажды может унаследовать ИИ-агент.

Проекты, отказывающиеся от четкого жизненного цикла

Работа фрилансера не следует четкому пути. Сначала готовится лендинг-страница, затем клиент просит ее переработку. Меняется направление бизнеса, появляется необходимость в интеграции платежей, потом — автоматизация через LINE, а затем еще какой-то связанный проект. С финансовой точки зрения одно задание может быть уже завершено и зафиксировано в счете, в то время как общее сотрудничество все еще продолжается. Договоры на техническое обслуживание еще более неоднозначны, поскольку они обычно действуют до тех пор, пока клиент не скажет, что им больше не нужны.

Одно поле статуса не может описать всего этого. Несколько независимых параметров статуса могут это сделать:

billing_status = closed
task_status = active
invoice_status = pending

Как указано здесь, при совместном прочтении становится ясно, что сумма окончательно определена, задача по-прежнему активна, а счёт-фактура ещё не отправлена. В противном случае потребовалось бы двадцать ручно определённых комбинированных состояний. Благодаря независимым полям модель остаётся компактной.

Разделение обязанностей

После нескольких дней размышлений было сформулировано правило иерархии:

Raw Data
   ↓
Small Logic
   ↓
Secondary Data
   ↓
END

Первичные данные содержат факты. Вторичные данные хранят вычисленную или преобразованную информацию, предназначенную для человеческого восприятия. Существует одно строгое правило: никаких третичных данных. Вторичная таблица никогда не должна использоваться для проведения дополнительных расчётов. Когда требуется новый результат, необходимо вернуться к первичным данным и сгенерировать новый набор вторичных данных. Это может привести к появлению множества вторичных таблиц, и это допустимо. Двадцать независимых вариантов представления данных лучше, чем такая цепочка операций:

Raw
 ↓
Secondary A
 ↓
Secondary B
 ↓
Secondary C
 ↓
Dashboard

Потому что одна ошибка в центральной части распространяется повсюду. Основной принцип заключается в том, что большее количество листов — это нормально, но глубокие зависимости — нет.

Строгая структура рабочей книги

Листы делятся по областям ответственности с использованием конвенции префиксов:

D_ = Raw Data
M_ = Master Data
S_ = System Rules
V_ = Secondary Views

Таблицы с необработанными данными выглядят так:

D_Task
D_Point
D_Pharmacy

а основные листы выглядят так:

M_Company
M_Project
M_Contact
M_Product
M_GroupS_SystemV_TaskList
V_MonthlyBilling
V_CurrentSummary

Листы с обозначением D_ являются источником истинных данных. Листы с обозначением M_ представляют собой бизнес-словари, описывающие компании, продукты, проекты и контакты. В S_System хранится конфигурация, специфичная для VBA: ставки налогов, значение каждого статуса, часовая ставка и цели по доходу. Листы с префиксом V_ предназначены для временного вывода информации. Их можно воссоздать по требованию, и они существуют для чтения, а не для использования другими формулами.

Прямая редактирование запрещена

Соблюдается ещё одно правило: в процессе нормальной работы никто не должен вручную редактировать исходные данные или основные листы. UserForms отвечают за создание, обновление и логическое удаление записей. Удаление не является физическим — вместо этого запись помечается специальным образом:

record_status = deleted

Эта строка остаётся в системе, что должно облегчить отслеживание истории и снизить риск случайной потери данных.

VBA как инструмент наблюдения

Именно здесь весь проект претерпел изменения. Изначально VBA предназначался для автоматизации рабочего процесса. Однако его более подходящая роль может заключаться в наблюдении за ним. Система может рассчитывать ожидаемый доход проекта и ожидаемый доход фармацевта, сколько дополнительного дохода ещё требуется, что остаётся в каждом проекте, какие счёты-фактуры ещё не отправлены, на каком этапе находится каждый проект и сколько баллов было потрачено.

Анализ этих цифр приводит к принятию решений, например, к выводу о том, что в следующем месяце не требуется дополнительных смен фармацевтов. Если спросить у Merge, как было принято это решение, честный ответ сегодня звучит примерно как «опыт». Именно поэтому решение пока не автоматизировано. Система должна последовательно отображать одну и ту же информацию, и после достаточного количества реальных использований могут стать заметными определенные закономерности в принимаемых решениях. Эти закономерности затем могут быть перенесены в Python, а в конечном итоге — в агента. Возможная последовательность развития:

Raw Data
   ↓
Python Logic
   ↓
Secondary Information
   ↓
AI Agent
   ↕
Human adjustment through Slack

Следовательно, версия на VBA не обязательно является окончательным приложением. Она служит своего рода лабораторией для выяснения того, что необходимо знать в окончательной версии приложения.

Разные инструменты — разные задачи

Попытка объединить всё в одну систему была бы ошибкой. Excel предназначен для работы с числами, счетами, статусами, записями и финансовыми данными. Notion используется для хранения подробных задач, заметок и информации о проектах. Физическая доска для заметок помогает запоминать или отмечать важные моменты.

Долгосрочная концепция сочетает два подхода: один представлен в виде отчета, а другой — в виде временной шкалы, причем основным местом для общения будет Slack с интеграцией Merge. В будущем физическое устройство Merge сможет читать важные сообщения из Slack вслух с использованием технологии текста в речь. Сначала оно будет выдавать только текстовый вывод, а ответы будут вводиться в Slack, поскольку распознавание речи неэффективно на открытом воздухе, а предыдущие эксперименты приводили к чрезмерно громкой речи у компьютера. Для прямого голосового общения с физическим устройством снова может понадобиться Raspberry Pi.

Интерфейс превращается в доску

После нескольких дней обсуждений архитектуры началась работа над первым UserForm, который отвечает за управление группами, компаниями, проектами, контактами и товарами. Изначально считалось, что он предназначен только для личного использования, и внешний вид не имел значения. Затем был выбран забавный шрифт, изменился фон, появились белые разделительные линии, и серьезная форма для управления основными данными превратилась в интерфейс в стиле доски. Merge сочла, что это напоминает MergeLab, а честная реакция заключалась в том, что интерфейс довольно приятен.

Внутри всё строго регламентировано: зависимости, права собственности на сырые данные, логическое удаление и запрет на использование вторичных данных. Визуально это выглядит как если бы кто-то объяснял нормализацию баз данных на доске посреди ночи. VBA по-прежнему не работает, но интерфейс, по крайней мере, последователен.

Уроки

Самый важный урок заключается в том, что автоматизация не должна начинаться с самой автоматизации. Сначала необходимо выяснить, какая информация является фактической, а какая — вычисленной, и какие решения всё ещё требуют человеческого суждения.

Меньшее количество таблиц автоматически не означает меньшей сложности. Множество независимых вспомогательных представлений может быть легче для понимания, чем компактная структура с длинными цепочками вычисленных данных.

Разные виды состояний должны находиться в разных полях. Вместо множества комбинированных статусов независимые поля могут описывать гораздо более сложные реальные ситуации:

task_status
billing_status
invoice_status
record_status

Бизнес-логика не должна влиять на интерфейс пользователя. Форма UserForm собирает вводные данные и вызывает повторно используемую логику, рабочая таблица инициирует обновления и отображает результаты, а вычисления находятся в небольших модулях, готовых к повторному использованию. Это облегчает последующую миграцию прототипа.

Самое главное — прототип может раскрывать скрытые правила принятия решений. Ему не обязательно принимать все решения сразу; достаточно сделать эти решения видимыми.

Следующие шаги

Непосредственная задача — заставить VBA выполнять какие-либо действия, начиная с формы MasterManagementForm, которая регистрирует и управляет группами, компаниями, проектами, контактами и товарами. Ее основной алгоритм работы:

Input
 ↓
Validation
 ↓
Generate ID
 ↓
Create / Update / Logical Delete
 ↓
Master Data

Как только основные данные будут готовы, следуют отдельные формы ввода для исходных таблиц:

D_Task
D_Point
D_Pharmacy

После этого можно сгенерировать первые вторичные представления. Самые важные на данный момент:

V_TaskList
V_MonthlyBilling
V_CurrentSummary

Когда эти решения станут применимыми в реальной работе, станет ясно, какие варианты действительно используются, а какие были лишь предположениями. Только тогда, когда такой рабочий процесс станет стабильным, возможность полноценной переработки с использованием Python, интеграции с Slack и ИИ-агента станет реальной альтернативой.

Итак, пройденный путь: попытка создания агента на основе технологии RAG, затем использование Excel, несколько дней на определение границ данных, после чего появилась концепция «доски знаний». Разработка программного обеспечения идет хорошо.