Ад мараў пра RAG-агента да прататыпа на VBA: раздзяляем сырыя і вытворныя даныя

План быў скромны: стварыць маленькую версію Merge — персональнага AI-агента. Эксперыменты з RAG, LangChain, LangGraph, эмбедынгамі і сховішчамі вектараў вэсьлі ўжо трывалі, і первісная ідэя была даўці агенту дзейнае памяць і доступ да внутрашніх дакументаў. Але потым з’явілася іншая проблема. Управлінне фрыланс-праектамі стало хаотычным, што падсунуло ідэю спачатку напісаць маленькі інструмент на VBA. Гэта здавалася простым, але такім не было. У ходу протатэп на VBA ператворыўся на ўсё іншае — у спосаб даследжэння бізнес-логікі, яку агент на AI можа будзе ў будучыні успадкаваць.

Праекты, якія адмовяюцца ад чыстага жыцёвага цыклу

Работа фрылансерам не парадоксальна. Адмін-сторанца аплодуе, а потым кліент хочаць перадзялёваць ўзгляд. Напрамак бізнесу зменшваецца, з’яўляецца інтэграцыя платэжаў, потым автаматызацыя праз LINE, а потым яшчэ адны праект. З фінансовай точкі зору, адна задача можа ўжо быць завершанаяй і выставленайя рахунку, пакуль загальная спавяранне ўсё ўсё трывае. Контракты на тыпаванне ўсё болш дзівныя, таму што багато з іх працуюць проста да таго часу, пакуль кліент не скажа, што ўжо не патрэбуюць іх.

Адна ячэйка статусу не можа гэта опісаць. Калькі незалежных відзнак статусу можа:

billing_status = closed
task_status = active
invoice_status = pending

Чытаючы разам, можна зрозумець, што сума ўжо фіксаваная, задача застаецца актываюю, а рахунак-фактура ўсё ўсё не надаслана. Інакш былі бы патрэбны 20 ручна заданых сумарных статаў. Незалежныя поля дапамагаюць залічыць модэль маленькім.

Раздзелэнне адпаведнасцей

Пасля калькі дзён раздумаў з’явілася правіла шарування:

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, пасля калькі дзён на выкліканні меж дадзэнняў, а потым — сістэма на базе „чорнай дошкі“. Развіцце програмнага забезпечэння йдэ добра.