Записи зустрічей — недооцінений інформаційний ресурс. У них важко шукати інформацію, їх довго переглядати повторно, а ще вони розпорошені по командних дисках, тому цінні висновки часто залишаються непоміченими.
Під час одноденного хакатону команда з трьох людей створила Callombia. Це внутрішня платформа, яка автоматично транскрибує записи дзвінків, додає теги й резюме, створює уривки та зберігає їх у доступному для пошуку репозиторії на кшталт YouTube, яким можуть користуватися всі міжнародні офіси.
Рішення, повністю створене за допомогою Codex, використовує семантичний пошук на основі ембедингів OpenAI та косинусної подібності, щоб знаходити доречні моменти навіть без точного збігу ключових слів. Його також доповнюють RAG-чатбот і система сповіщень.
Те, що раніше потребувало б кількох тижнів, вдалося реалізувати за сім годин. Це показує, як орієнтована на ШІ розробка з агентами програмування на кшталт Codex може суттєво скоротити цикл створення продукту й допомогти внутрішнім хакатонам приносити реальну користь бізнесу.
Якщо ви схожі на мене, то навряд чи маєте час (або терпіння), щоб переслуховувати записи зустрічей. Часто для цього доводиться шукати записи на невпорядкованих командних дисках, пропускати не надто змістовні розмови й намагатися справді слухати, паралельно відповідаючи на листи та повідомлення.
Але, можливо, усе може бути інакше? Можливо, ми могли б створити щось, що докорінно змінить роботу із записами зустрічей? Саме ця ідея лягла в основу нашого нещодавнього проєкту для хакатону.
Усього за день 50 фахівців із наших інженерних, проєктних та операційних команд узялися за низку завдань із різних напрямів бізнесу: масштабування рекрутингових операцій, спрощення створення SoW, оцінювання стану проєктів, генерування прототипів у реальному часі та пошук корисної інформації в записах зустрічей.
На цьому хакатоні з використанням Codex ми створили Callombia. Callombia — це YouTube нашої компанії, що перетворює кожен дзвінок на живий ресурс із можливістю пошуку. Кожен дзвінок автоматично транскрибується, отримує теги й резюме, після чого ділиться на тематичні уривки та додається до репозиторію, упорядкованого за каналами (клієнтами) і темами (напрямами спеціалізації у сфері ШІ). Завдяки цьому будь-хто з команди в Лондоні, Единбурзі, Сінгапурі чи Австралії може миттєво перейти до потрібних моментів у записах дзвінків.
Знайомий інтерфейс у фірмовому стилі робить пошук контенту інтуїтивним, а семантичний пошук і, звісно ж, RAG-чатбот зі ШІ допомагають знайти саме те, що потрібно. Система сповіщень також дає колегам змогу підписуватися на певні теми й отримувати повідомлення про нові актуальні для них уривки.
Але найцікавіше в Callombia — не сам продукт і не приз у £2 тис. за перемогу в хакатоні (можна й похвалитися), а те, що ми змогли створити все це лише за сім годин силами двох інженерів і керівника проєкту. Ще рік тому це було неможливо. Удосконалення агентів програмування значно прискорило весь процес розробки продукту, а цей хакатон став чудовим полігоном для дослідження мінливих меж їхніх можливостей. Отже, як саме ми використовували Codex?
Замість того щоб просто скласти довгий перелік вимог, ми спочатку описали в запиті наше спільне бачення проблеми та майбутнього Callombia. Ми навмисно не вдавалися в деталі, щоб модель самостійно виконала роботу й могла мислити творчо:
Після десяти хвилин обговорення ми ввімкнули режим планування, щоб конкретизувати вимоги та визначити технічну частину розробки. Режим планування нагадує розмову з настирливим другом, який (на щастя) заздалегідь продумав усі можливі сценарії. Узгодивши кількість відео, тип пошуку — семантичний чи за ключовими словами — та майбутню архітектуру, ми отримали файл markdown, який став основою подальшої роботи над проєктом.
Коли план був готовий, ми перейшли до створення основних компонентів, необхідних для роботи Callombia. Для цього потрібно було створити конвеєр, який перетворював би записи дзвінків на доступні для пошуку ресурси:
Завантаження відео й транскриптів,
Поділ їх на змістовні фрагменти,
Доповнення резюме й тегами,
Надання доступу до них через API, які міг використовувати фронтенд.
Ед переважно займався перетворенням необроблених записів і транскриптів на придатний для використання формат, а Ніко — рівнем пошуку, який давав змогу знаходити потрібні моменти. За допомогою Codex вони набагато швидше створили моделі даних, сценарії вилучення та серверну інфраструктуру, ніж змогли б це зробити вручну. У результаті ми отримали набагато більше, ніж просто транскрипт, прикріплений до відео. Ми отримали конкретні моменти: фрагмент про Tesco, оновлення стратегії, обговорення найму або саме ті 90 секунд дзвінка, які хтось справді хоче переглянути.
Саме на рівні пошуку почалося найцікавіше. Ми хотіли, щоб користувач міг ввести щось на кшталт “financial performance,” “Tesco roadmap,” або “conversation evals” і перейти до найдоречніших уривків, навіть якщо ці точні слова ніколи не звучали. Для цього ми створили фрагменти з часовими позначками, резюме, текстом транскрипту та метаданими. Маючи чітке бачення архітектури й заручившись значною допомогою Codex, ми об’єднали тему, резюме та транскрипт в одні вхідні дані й використали модель OpenAI text-embedding-3-small, щоб створити ембединги для кожного фрагмента. Ми зберегли ці ембединги в базі даних і використали косинусну подібність для порівняння запиту користувача з кожним фрагментом. Так ми отримали рівень семантичного пошуку замість простого пошуку за ключовими словами.
Цей підхід забезпечив надзвичайно високу точність і створив відчуття «магії» під час демонстрації продукту на хакатоні. Водночас ми розуміли, що зі збільшенням кількості відео цей підхід не зможе масштабуватися безкінечно, адже порівняння кожного запиту з кожним фрагментом зрештою стане надто дорогим. Наступним логічним кроком було б упровадження ефективніших стратегій пошуку, як-от Hierarchical Navigable Small World, щоб зменшити кількість порівнянь і зберегти низьку затримку зі зростанням корпусу. Коли ця функція запрацювала, Callombia стала більше схожою на систему знань, ніж на медіатеку.
Як і на будь-якому хорошому хакатоні, цю частину теж довелося вдосконалювати: початкові межі фрагментів були надто приблизними, деякі часові позначки потребували уточнення, частина тегів була занадто загальною, а файли транскриптів і записів не завжди точно збігалися. Але саме тут і проявилася цінність підходу. Codex дав нам змогу швидко вдосконалювати систему, не загрузнувши в налаштуванні та повторній роботі. Зрештою ми отримали бекенд, здатний підтримувати уривки, короткі фрагменти й справді корисний семантичний пошук. Саме тоді Callombia стала сприйматися як справжній продукт, а не просто демонстрація для хакатону.
Поки Ед і Ніко створювали рівні завантаження даних та інтелектуальної обробки, я займався фронтендом. Завдяки нашому шаблону повного стека я швидко запустив першу версію сайту, не написавши жодного рядка коду. Попросивши відкрити сайт локально в моєму браузері, я надавав прості відгуки у вигляді маркованого списку й поступово доводив дизайн до бажаного вигляду.
Приблизно за годину такого обміну я отримав результат, яким був цілком задоволений, хоча не мав жодного досвіду в розробці інтерфейсів чи дизайні. Кінцевий продукт, безумовно, не ідеальний, але це доволі вдала перша версія, яка дає людям змогу зрозуміти суть продукту.
Щоб до кінця дня гарантовано отримати результат, ми розподілили роботу між собою. Звісно, після кількох годин напівнезалежної роботи в кожного з нас була власна локальна гілка з безліччю конфліктів.
Замість того щоб витрачати час, якого в нас не було, на ретельне усунення конфліктів, ми вирішили надати Codex повний доступ до репозиторіїв і доручити йому самостійно все виправити. Поки що ми не радили б такий підхід до розробки корпоративного програмного забезпечення, але в середовищі з низькими ризиками його ефективність вражає — нам вдалося заощадити багато годин.
Останнім етапом хакатону був запис демонстрації Callombia для журі. Спершу нам інстинктивно хотілося відкрити Loom і записати демонстрацію, але ми вирішили, що це стане справжнім випробуванням для Codex і дещо виходитиме за межі його тодішніх можливостей. Тож… Ми написали запит, додали посилання на сайт Callombia та запис мого голосу на платформі OpenAI для розробників, а решту доручили йому.
Перша спроба неабияк вразила: Codex написав сценарій демонстрації, записав екран, додав моє озвучення й загалом виконав завдання. Єдине, що нас одразу не влаштувало, — синхронізація озвучення із записом демонстрації, тож ми попросили: “MANDATORY: align the voiceover exactly with what is being shown in the demo. There was misalignment (e.g. on the chat page). Triple check alignment of voiceover and the screen-recorded demo at the end. Match it up through whichever means possible.”
У відповідь Codex розділив озвучення та запис на менші фрагменти й виконав завдання майже бездоганно — саме вчасно, до 17:30, коли на нас уже чекали святкові пиво й піца.
Ми знаємо, що Callombia розв’язує проблему, знайому більшості компаній. У компанії, що стрімко зростає, важко бути присутнім на кожному дзвінку, але висловлені під час них цінні думки мають величезне значення. Тепер залишається лише запустити систему у виробничому середовищі.
Утім, тут є й важливіший урок про роботу на основі ШІ та користь від застосування інженерної й продуктової кмітливості для розв’язання спільних проблем. Вийшовши за межі звичного робочого циклу та об’єднавши зусилля різних команд у напівзмагальному середовищі, ми отримали низку рішень, які після невеликих доопрацювань можна впровадити у виробниче середовище. Регулярно проводячи такі заходи, ми зможемо зробити внутрішні процеси не менш досконалими, ніж рішення, які створюємо для клієнтів.