Від мрій про агентів 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 та AI-агента стане серйозною альтернативою.

Отже, поки що така послідовність: спроба створити агента на основі RAG, потім Excel, кілька днів на визначення меж даних, а потім система типу «чорна дошка». Розробка програмного забезпечення просувається добре.