Чому meeting notes мені виявилося недостатньо

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

У мене ADHD, і під час мітингів мені іноді складно втримати в голові всі деталі розмови, особливо коли одночасно потрібно слухати, думати над відповіддю й стежити за контекстом. А іноді я просто дуже сильно фокусуюся на одній частині розмови й пропускаю іншу.

Через це мітинги часом бувають для мене досить стресовими. І я далеко не завжди почуваюся на них настільки продуктивним, наскільки хотілося б.

Тому одна з категорій продуктів, яка з’явилася завдяки AI і яку я реально люблю — це meeting note takers.

Спочатку я просто дивився, що вже є на ринку, і пробував різні варіанти.

Наприклад, мені подобалася Granola, але для мене було важливо мати інструмент, яким я можу користуватися не тільки в межах компанії, а й для своїх особистих речей.

Були open-source альтернативи, але частина з них, скажімо так, не викликала великого бажання ними користуватися.

Ну і є Cluely, про який, думаю, багато хто чув. Я трохи ним користувався, але весь вайб навколо продукту, який багато в чому й зробив його відомим, просто не дуже збігається з моїми цінностями. Тому платити за нього мені не хотілося.

У якийсь момент я подумав: окей, чому б не зробити щось своє.

Спочатку я просто закривав власні потреби. Але досить швидко зрозумів, що мені цікаво зробити щось трохи більше, ніж просто ще один AI note taker.

З технічної точки зору записати мітинг, зробити транскрипт і дати LLM його підсумувати — не надто складна задача.

Але майже всі такі продукти збирають контекст тільки під час самого мітингу.

А далі залишається великий шматок роботи між мітингами.

Ти щось обговорив, про щось домовився, закрив дзвінок і пішов далі працювати. Пишеш комусь у Slack, відкриваєш документацію, дивишся код, створюєш таску, щось гуглиш.

І весь цей контекст уже нікуди не потрапляє.

Я подумав: а що, якщо спробувати закрити і цей gap?

Так з’явився Ambient Context.

Контекст між мітингами

Ідея Ambient Context досить проста: збирати невелику кількість інформації про те, над чим я працюю між зустрічами.

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

Одна з перших речей, яку я додав — можливість повністю виключати окремі застосунки.

Бо очевидно, що далеко не все, що відкривається на комп’ютері, ти хочеш бачити в якомусь робочому контексті.

Але в повсякденному використанні сама ідея виявилася для мене дуже корисною.

Наприклад, наприкінці дня я можу сказати агенту:

«Подивись, що сьогодні відбувалося, і скажи, чи я щось не забув».

І він може відповісти приблизно так:

«Ти говорив із Джошем у Slack. Він сказав, що після третьої напише тобі апдейт по фічі й наступні кроки».

Начебто дрібниця.

Але протягом дня таких речей накопичується дуже багато. І до частини з них ти просто не повертаєшся.

У якийсь момент я зрозумів, що цікава проблема тут уже не в тому, як записати мітинг.

Набагато цікавіше — як зібрати достатньо робочого контексту, не перетворюючи комп’ютер на систему постійного запису всього, що відбувається на екрані.

Як працює Ambient Context

Назва може трохи збивати з пантелику, тому важливий момент: Ambient Context не робить скріншот екрана кожні кілька секунд і не відправляє його в якусь vision-модель.

Основний механізм побудований на Accessibility API в macOS.

Приблизно раз на п’ять секунд застосунок дивиться, який application зараз активний. Якщо він не входить у список виключень, застосунок читає Accessibility tree поточного вікна.

Тобто замість того, щоб дивитися на пікселі екрана, я отримую структуру вікна й текст, який application сам віддає через Accessibility API.

При цьому я обходжу тільки focused window. Не всі відкриті вікна і не весь екран.

Для браузерів є ще одна оптимізація: обхід починається з AXWebArea.

Так не потрібно витрачати час на tabs, toolbar, bookmarks та інший browser chrome — можна одразу перейти до контенту сторінки. Звідти ж я дістаю URL.

У результаті виходить досить проста структура: title вікна, URL, якщо він є, і масив текстових рядків.

Після цього все обробляється локально: прибираються порожні значення, дублікати, зайвий browser chrome, а сам текст обрізається до розумного розміру.

І в більшості випадків на цьому все.

Скріншоти взагалі не потрібні.

Коли Accessibility API недостатньо

Звісно, Accessibility API працює добре не скрізь.

Наприклад, деякі Electron або canvas based applications можуть нормально віддати sidebar та інші елементи UI, але не показати основний контент, який користувач реально бачить у вікні.

Для таких випадків у мене є другий шлях — OCR fallback.

Він вмикається тільки тоді, коли Accessibility API повернув занадто мало корисного тексту.

Тоді через ScreenCaptureKit захоплюється конкретне вікно, а Vision framework витягує з нього текст.

Сам screenshot при цьому існує тільки в пам’яті під час цього виклику. На диск він не записується.

Для мене це важлива частина архітектури.

Screenshot capture тут не основний механізм, а саме fallback для застосунків, які погано працюють із Accessibility API.

І Accessibility API, і OCR у підсумку приводять до одного формату: plain text плюс трохи metadata про те, звідки цей текст взявся.

Потім контент дедуплікується й зберігається як searchable text із timestamp та metadata.

Тобто в базі немає відео мого робочого дня чи нескінченного потоку скріншотів.

А де тут взагалі AI?

Ще одна штука, яку я для себе вирішив досить рано: на етапі збору контексту LLM взагалі не потрібна.

Там немає VLM, немає embeddings, і кожен новий шматок тексту не відправляється в модель.

Пошук по Ambient Context — це звичайний full-text search у Postgres.

LLM з’являється тільки тоді, коли користувач реально ставить питання.

Система знаходить релевантний контекст, стискає його в короткий activity digest, і вже цей digest потрапляє в prompt.

Якщо дуже спростити, основний pipeline виглядає так:

А якщо Accessibility API не вистачило:

Для мене це й було головною архітектурною ідеєю: збирати достатньо контексту, щоб система реально допомагала, але не будувати для цього постійний запис усього, що відбувається на комп’ютері.

Що з цього вийшло

Я починав із дуже простої потреби: хотів інструмент, який допоможе мені не втрачати важливі речі під час мітингів.

Але коли почав користуватися ним щодня, стало зрозуміло, що самі мітинги — лише частина проблеми.

Велика частина роботи відбувається між ними.

Повідомлення в Slack. Документація. Код. Таски. Браузер. Якась маленька домовленість, про яку ти думаєш: «окей, повернуся до цього пізніше».

А потім не повертаєшся.

Саме цей контекст губиться найпростіше.

Ambient Context для мене став спробою закрити цю прогалину.

Мені дуже подобається сама ідея, що комп’ютер може пам’ятати контекст моєї роботи краще за мене.

Але мені зовсім не подобається ідея, що для цього він має постійно записувати мій екран або відправляти все, що я роблю, в LLM.

Тому доволі багато часу в цьому проєкті я витратив не на те, щоб додати більше AI.

Навпаки — я намагався зрозуміти, де він узагалі не потрібен.

Accessibility API замість постійних скріншотів.

OCR тільки як fallback.

Звичайний full-text search замість embeddings.

І LLM тільки в той момент, коли від нього справді потрібна відповідь.

Поки що я в першу чергу будую це як інструмент для себе.

І, мабуть, це одна з речей, які мені найбільше подобаються в цьому проєкті: протягом дня я можу помітити щось, що мене дратує або чого мені не вистачає, ввечері це зробити, а наступного дня вже перевіряти на власній роботі.

Не знаю, у що саме все це зрештою перетвориться.

Але сама ідея персонального робочого контексту, який не закінчується в момент, коли ти натискаєш Leave Meeting, мені здається дуже цікавою.

І поки що це саме та проблема, яку мені хочеться продовжувати копати.