Режим агентських відео Gemini: проектування схеми та зсув часових міток

Нещодавно Google випустив функцію розуміння відео типу „агент“ для Gemini, що створює чудову можливість провести практичні експерименти з складним тестовим випадком – повнометражним китайськомовним фільмом Secret (2007) режисера Джей Чоу. Експерименти зосереджені на одному питанні: якщо запитати модель про моменти у відео, де з’являються ключові ідеї, наскільки точними є часові позначки, та наскільки спосіб проектування схеми результату впливає на кінцевий результат?

Вам знадобиться GOOGLE_API_KEY, який AI Studio надає у рамках пристойного безкоштовного тарифу. Деталі налаштувань наведені в додатку в кінці.

Чому китайський фільм є гарним тестом

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

Є попередження про спойлери: те, що йде далі, розкриває центральну таємницю фільму. Вихідне відео для тестування — це аналіз фільму на YouTube, де розповідається сюжет приблизно до моменту 16:23, після чого оповідач переходить до аналізу того, як сюжет був натхненний власним життям Джей Чоу. Сам фільм все одно вартий перегляду завдяки музиці та тонким виразам облич головної актриси, і на Bilibili існує принаймні дві версії фільму.

Те, що робить цей тест справді складним, — це мова. У китайських відео значно менше автоматично створених транскрипцій, ніж у англійських, тому модель з самого початку має обмеження та повинна показати, на що здатна без цієї підтримки. Щоб розібратися, не обов’язково читати китайську мову, хоча це допомагає краще оцінити результати.

Чому важлива зміна часових позначок

Як у навчанні, так і у розвагах існує спільна потреба у локалізації часових позначок – можливості переходу безпосередньо до важливих моментів. Студенти використовують це для повторного ознайомлення з поясненням певної концепції. Глядачі роблять це для пошуку „прихованих елементів“ та повторного перегляду якісних історій.

Проблема поступової зміни часових позначок у аудіо-транскрипціях Gemini була широко описана на форумі розробників Google. Надійним рішенням є використання старішої моделі, яка не є ШІ, але це майже не є цікавим експериментом; тому сподівалися, що режим агента дозволить досягти кращих результатів.

Коротко кажучи: відхилення все ще спостерігаються. Приблизно у 95% випадків похибка залишається в межах однієї секунди, але в деяких випадках спостерігаються значні відхилення на рівні 10–20 секунд. Цікаво, що відхилення концентруються в одних і тих самих місцях, що достатньо гарно, щоб це не турбувало користувачів під час повсякденного використання. Розробники також можуть пізніше видалити некоректні часові позначки шляхом порівняння з текстом, позначеним часом, у певному часовому проміжку, за умови наявності такого тексту.

Дизайн схем кращий за дизайн запитів

Схеми ШІ зазвичай пишуться у форматі JSON Schema. Бібліотеки на кшталт Pydantic у Python або Zod у TypeScript дозволяють визначати їх на рівні додатку та автоматично компілювати у JSON Schema перед вставкою до запиту. Вже з назв та типів змінних зазвичай можна передбачити, що поверне модель.

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

Існує паралель із моделюванням даних у інженерії даних, з тією різницею, що схеми вихідних даних великих мов моделювання більше нагадують дизайн NoSQL, такий як MongoDB, ніж реляційне моделювання, як Postgres. Одне цікаве рішення стосується рекурсивних структур: їх можна кодувати як плоскі таблиці з самопосиланнями, де child_id та parent_id дозволяють безлічі ланцюгів. Провайдери різняться у тому, чи дозволяють вони взагалі рекурсивні JSON Schema, тож цей вибір може бути нав’язаний вам.

Читання схеми

Як і у моделюванні даних, важлива кардинальність. Один фільм має багато концепцій, які представлені у вигляді масиву. У освіті тема має передумови, застосування, розширення, припущення та обмеження. У фільмі є події, розвиток персонажів, кульмінація та розв’язка.

Одна концепція має багато часових позначок. У навчанні це трапляється, коли кілька концепцій порівнюються для розвитку вищих рівнів мислення після їхнього введення. У фільмі це відбувається, коли режисери використовують відлуння минулого або розповідають історію не в порядку.

Елементи часових позначок мають кілька властивостей:

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

quote — це фрагмент тексту, вилучений дослівно за допомогою технології розпізнавання мовлення.

visual вказує, чи можна зобразити цю мить.

visualDescription — це підпис з тим, що відбувається на екрані в цей момент.

Існують також точки контролю, кожна з яких має conceptLabel, question та answer. У освіті вони перевіряють рівень розуміння учня. У розважальних цілях вони спонукають глядачів звернути увагу на те, що було пропущено під час перегляду, або переглянути події з іншої точки зору. Модель виявилася достатньо розумною, щоб повторно використати абсолютно той самий текст як conceptLabel, так і відповідний label під concepts — це невеликий, але значущий ознака внутрішньої послідовності.

Що було змінено

Типовий час виконання становив близько 20 секунд. Деякі виконання закінчувалися за 9 секунд, ймовірно, тому що Google зберігав запит у кеші та повторно використовував результати. Одне виконання зайняло 50 секунд одразу після зміни запиту, ймовірно, ще до того, як утворився кеш.

Режим обробки — агентний проти статичного — сам по собі майже не впливав, і більшість часів запису все одно залишалися в межах однієї секунди. Агентні виконання іноді займали вдвічі більше часу (близько 40 секунд), а іноді — менше. Час виконання скрипту справді впливав на якість: при довшому часі виконання знаходилося більше часів запису на кожну концепцію, що призводило до довших описів та цитат.

Запит містив вказівку знайти принаймні три часові позначки для кожної мітки концепції. Без неї модель часто знаходила лише одну позначку на концепцію. З нею часові позначки виявилися трохи точнішими, і робоча гіпотеза полягає у тому, що підвищення щільності пошуку мало побічний ефект на точність. Варто спробувати змінити число три, щоб побачити, що станеться.

Додатковий запит просив модель знайти момент, коли була сказана певна китайська фраза — кульмінацію фільму, коли величезна залізна куля летить прямо на головного героя. Це змушує модель порівнювати аудіо з точною фразою та визначати момент її вимови.

Перший етап: статичні волонтери додають додаткові поля, агентні моделі їх ігнорують

Під час першої спроби статичний режим мав тенденцію додавати ключі visual та visualDescription, які схема ніколи не вимагала. Це відбувалося непослідовно – у межах однієї обробки ці ключі додавалися до деяких часових позначок, а ігнорувалися для інших. visualDescription є корисним для забезпечення доступності та для заповнення баз даних пошуку, адже ключові моменти можна було знаходити за допомогою створеного опису, і цей елемент був точним у кожному перевіреному прикладі.

Лише ключ quote завжди залишався у оригінальній китайській версії. Усі інші ключі могли з’являтися ані китайською, ані англійською мовою, що було непередбачуваним у різних варіантах обробки – чи то в режимі агентів, чи статичному. У обох режимах часові позначки були акуратно впорядковані всередині та між концепціями, що полегшувало ручну перевірку.

Режим агента створював довші описи, і ця тенденція повторилася під час другої спроби. Він також вперше показав сцену, яка постійно з’являється знову: режим агента позначив певний момент як 10:41, але насправді він відбувається о 10:50 у відео. Якби у цьому результаті був поля visualDescription, він би показав, чи справді модель дивилася на 10:41 чи на 10:50.

У description статичного запуску для одного запису просто повторювався його позначений заголовок (“Механіка подорожей у часі”), що майже нічого не додавало, хоча пізніші запуски показали більш значущі відмінності. З позитивного боку, статичний режим чудово розпізнав стару книгу з піаніно та героїню, яка заплющує очі, у visualDescription, і навіть правильно ідентифікував персонажа. Режим агента просто ігнорував необов’язкові візуальні позначки.

Другий запуск: статичний режим правильно визначив момент о 10:50

Static знову додав необов’язкові візуальні клавіші, тоді як agentic — ні. Static також правильно визначив момент 10:50, який перша спроба agentic неправильно позначила, хоча в тій спробі був правильний текст. Static позначив visualDescription цього моменту як „сцена відлуння“, що породило запитання: як Gemini зрозуміло, що це відлуння, а не поточна часова лінія?

Часові позначки залишалися в порядку всередині кожної позначки в обох режимах. Між позначками Static просував аналіз оповідача вперед, тоді як agentic чергував такі часи, як 10:41, 17:00, 15:00 та 17:51.

Перший фрагмент тексту від Static о 16:31 містив китайські дужки для назв книг, які також з’являлися на екрані, що свідчить про те, що модель створила це зображення, а не спиралась лише на аудіо. Як і раніше, Static використовувала коротші фрагменти тексту. Agentic розтягувала свої фрагменти до середини, після чого використовувала тире; її фрагмент для часу 15:00 насправді охоплює період з 15:01 до 15:38, а фрагмент для часу 17:51 — з 17:54 до 19:56.

Цей останній період є примітним, оскільки час з 17:54 до 19:56 включає повний опис усіх чотирьох кінцівок фільму. Це породжує запитання: а що, якби у запиті також просили вказати час кінця? Це запитання стимулює наступну зміну схеми.

Третя спроба: додавання діапазонів часу

Поле seconds спочатку було рядком, тому його довелося переробити. Існує два варіанти. Перший — це масив:

"seconds": {
    "type": "array",
    "description": "The start and end time range in HH:MM:SS or ISO format, structured as [start_time, end_time].",
    "prefixItems": [
        {
        "type": "string",
        "description": "Start time (e.g., '00:01:15' or ISO 8601 string)"
        },
        {
        "type": "string",
        "description": "End time (e.g., '00:02:30' or ISO 8601 string)"
        }
    ],
    "minItems": 2,
    "maxItems": 2
    }

Другий — це об’єкт:

"seconds": {
      "type": "object",
      "properties": {
        "start_time": {"type": "string"},
        "end_time": {"type": "string"}
      },
      "required": ["start_time", "end_time"]
    }

Масив використовує менше токенів, але йому потрібні незграбні межі min та max, щоб логіка початку та кінця залишалася працездатною, і його використовували у наведених нижче експериментах. Об’єкт забезпечує більш зрозумілі ключі та вимагає трохи більше коду для читання, але дозволяє наявність додаткових ключів, тому поза межами експериментів він є рекомендованим варіантом.

Цитата — це не лише аудіо

У режимі агента один діапазон тривав з 6:20 до 6:42, хоча цитата насправді починалася о 6:30. description збігався з аудіо слово в слово починаючи з 6:20 протягом восьми слів, перш ніж перейти до власного переказу. Здається, що завдання з формування цитати було розділене між quote та description.

У іншому діапазоні часу, з 8:13 до 9:00, цитата (приблизно «погляди зустрілися») почалася о 8:21, тоді як у описі було зазначено «з’явитися знову», і головна героїня справді з’являється близько 8:13. Це підтримує думку про те, що діапазони часу формуються не лише на основі аудіо. Цитата закінчилася о 8:55, за п’ять секунд до кінця діапазону, без очевидної причини.

Це свідчить про те, що під час аналізу відео аудіо має точно відповідати тому, що відбувається на екрані, інакше виникають проблеми з локалізацією часових позначок. Проте немає жодних очевидних факторів, які визначають, яку з модальностей багатомодальна модель буде враховувати більше під час створення часової позначки. Це справжня можливість для досліджень, і більш чіткі експерименти (повне аудіо та відео проти відео з приглушеним звуком проти відео без звуку) допоможуть це з’ясувати.

Два нові способи збою

Третє відтворення цієї постійно повторюваної сцени виявило нову помилку. У статичному режимі у діапазоні з 14:49 до 15:02 була цитата, яка насправді походить з 10:49 – це омана тривалістю чотири хвилини. Це той самий момент о 10:50, який система статичного аналізу точно визначила під час другої спроби, а система з агентом неправильно позначила як 10:41 під час першої.

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

Друга помилка: статична цитата з 15:07 до 15:17 (приблизно „він знайде Сяою“) зовсім не зустрічається у аудіо. Схоже, модель самостійно створювала узагальнення замість того, щоб транскрибувати текст.

Статичний метод перемагає у тесті „голка в купі сіна“

Щоб з’ясувати, чи можна знайти певний уривок, до запиту було додано умову про залізну кулю. До впровадження схеми часового діапазону алгоритм static знайшов момент 15:22, а алгоритм agentic — 15:00. Після цього алгоритм static виявив точний момент — 15:21, а навіть продовжив пошук до 15:26, саме тоді, коли куля влучає в будівлю та шум зникає. Алгоритм agentic показав гірші результати, визначивши діапазон від 15:00 до 15:37, що було занадто широким. У практичному використанні навіть трьохсекундна похибка може випробувати терпіння користувача.

Що показують тести

Алгоритм static краще знаходить конкретні моменти, тоді як алгоритм agentic краще узагальнює ідеї, які розвиваються протягом тривалого часу. Розумний висновок — не обирати переможця. Вибирайте алгоритм залежно від завдання та тривалості медіаконтенту: static для точного пошуку чи коротких кліпів, де різниця в витратах майже не має значення, а agentic — для синтезу інформації з, наприклад, 90-хвилинної лекції, де економія ресурсів починає мати значення.

Судячи з експерименту з пошуком, перехід від позначки часу до діапазону часу не змінив початкової точки, тому доцільно завжди отримувати також кінцевий час, що надає додатку значно більше можливостей для проектування користувацького інтерфейсу. Це схоже на використання векторних ембеддингів у системі пошуку без фактичного включення будь-чого.

Діапазони часу можуть залежати від кількох факторів, а навіть у тексті — від кількох ключових елементів, як показує модель передачі цитат. Можливо, схема має бути простішою, щоб модель не плуталася, або ж взаємозв’язок між похідними та сусідніми полями слід уточнити, наприклад, вказавши, що description має походити від quote, або вирішивши, чи є концепції незалежними, чи мають вони пояснювати взаємозв’язок причинно-наслідкового характеру.

Ще один патерн заслуговує на згадку. Після того, як був заявлений діапазон часу, сервіс static повністю припинив генерувати поля visual та visualDescription. Однією з гіпотез є те, що модель зосередилась на обов’язкових полях та відкинула необов’язкові ключі під тиском навантаження. Зроблення їх обов’язковими може вирішити проблему, але, можливо, за рахунок якості в інших аспектах, оскільки для них залишиться менше ресурсів. Це схоже на те, як інструмент для створення слайдів може створювати відмінні слайди в одному запуску, а в наступному повертатися до примітивного дизайну, ніби йому потрібен відпочинок.

Куди це може розвинутися

Вивчення мов. У деяких експериментах, які не були оприлюднені, пропозиція виводити англійську та китайську мови поруч одна з одною в одному рядку працювала навіть без прямої вимоги.

Створення відео. Часові позначки та діапазони дозволяють інструментам на наступних етапах, таким як ffmpeg, вирізати та обрізати матеріал, щоб основні ідеї були спочатку. У цьому випадку штучні нейронні мережі мають втрати, тому для збереження всього контенту та видалення лише елементів, що заповнюють паузи, краще використовувати більш спеціалізовані інструменти перекладу мовлення в текст, такі як Descript, або новішу модель транскрипції Gemini від Google.

Що можливо завдяки точній локалізації:

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

Пошук за моментами у природній мові серед лекцій та зустрічей. Функція „знайти саме цей рядок“ у кульмінаційній частині відео — це та сама техніка, яку студент може використати під час перегляду записаної лекції: ввести напівзапам’ятане речення та перейти до місця, де воно було сказане.

Мислення про краї, а не лише про вузли

У поточній структурі більшість інформації щільно зосереджена в вузлах. Як можна сформувати ребра для подальшого покращення користувацького досвіду? Чи варто перенести частину інформації з вузлів у ребра, чи існують інші способи представлення знань окрім графа вузлів та ребер? Можна застосувати методи з книги Learn Like a Polymath: частина-ціле, причина-наслідок, об’єкт-функція, проблема-рішення, факт-думка та приклад-тип. Штучні інтелекти, ймовірно, вже можуть створювати такі аналогії, і секрет полягає у тому, щоб у правильний час запитати про потрібне та представити його у правильний спосіб.

Вже існує одна відповідь у додатку для навчання з текстовим форматом, який створює динамічну карту концепцій під час чату. Там агент сам генерує ребра. Запитайте про спів, а потім про техніку вокалу, і агент об’єднає їх у пов’язані вузли без необхідності вказування зв’язку; кольорова маркування для основної теми, абстракції, сестринських елементів та деталей виконує функцію інформації про ребра. Властивість checkpoints у цій схемі також має свій динамічний аналог, який позначає нерозв’язані запитання та можливі хибні уявлення під час чату, які потім вирішуються після прояву розуміння.

Експерименти, які ще потрібно провести

Вони достатньо конкретні, щоб кожен міг їх спробувати, а також щоб зрозуміти, що вони можуть розкрити.

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

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

Чи залежить відхилення від змісту чи позиції? Якщо воно зумовлене характеристиками самого моменту, такими як швидкі переходи, перекривання голосів або гучна музика, то де б він не виникав, це є незалежним від перекладу збоєм, який супроводжує зміст. Якщо він погіршується у довгому відео, це щось інше, можливо, пов’язане з явищем „загубленості посередині“, коли продуктивність LLM знижується через інформацію, розташовану посеред контексту.

З’єднання записів між сегментами схеми. Чи може модель розпізнати, що два позначення концепцій, створені під час окремих викликів або розділені довгим контекстом, позначають одну й ту саму реальну концепцію? Це класична проблема з’єднання записів або резолюції ентитетів, схожа на проблему когеренції, коли вона виникає в межах одного покоління. Це спрацювало один раз, коли модель використовувала ідентичний текст для conceptLabel та label, але залишається відкритим питанням, чи зберігається послідовність під час окремих викликів.

Міжмовне обґрунтування. Вимірюйте, наскільки точно Gemini перетворює усну китайську мову на англійські поля схеми, зберігаючи при цьому точність таймінгу.

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

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

Лекції, фільми та пам’ять

Лекція та фільм вимагають від глядача різних речей. Лекція потребує уваги, а фільм — емоцій. Персонажі в історії — це не розв’язані проблеми, як у концепціях з підручника; їх створюють як справжніх людей, мотивація яких може тлумачитися по-різному. Часто не існує правильної відповіді чи навіть чіткого рішення, лише компроміси та зусилля для того, щоб врятувати якомога більше з ситуації, яка викликає жаль, — урок життя, який поширюється далеко за межі одної теми.

Невролог Олівер Сакс описав пацієнта на ім’я Клайв Верінг, у якого амнезія не дозволяла зберігати спогади довше кількох секунд, за винятком музики, яку він все ще міг виконувати, читати та повністю згадувати. Сакс сформулював це так: сила музики мусить застати людину зненацька та спонтанно з’явитися як благословення.

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

Співпраця може відбуватися і в обох напрямках. Схеми можна вдосконалювати, щоб максимально використати потенціал ШІ, а в свою чергу ШІ можуть змінити наші світогляди та здібності, допомагаючи нам критично мислити щодо певної теми, розвивати емпатію та соціальні навички шляхом розуміння причин поведінки персонажів, дослідження «що, якби» та навчання тому, як розповідати чудову історію. У фільмі у героїні, мабуть, було чотири можливі кінцівки, і ШІ також міг би надати доступ до багатьох варіантів знань, дозволяючи прискорювати, уповільнювати, повертати назад та обирати шлях.

Схожим напрямком є дослідження агента, який дивиться лекцію разом з вами, зупиняється за запитом та відповідає, ґрунтуючись саме на моменті зупинки. Це та сама проблема локалізації за часовими мітками, яка тестувалась тут, але в реальному часі та у складнішій формі. Якщо навіть у режимі агента виникають похибки у кілька хвилин для завершеної, контрольованої відеоінформації, то версія у прямій трансляції стикнеться з ще складнішою формою тієї ж проблеми. Ці експерименти є початковою основою для цієї ідеї, а не описом готового продукту.

Додаток: налаштування та відтворення експериментів

Отримайте GOOGLE_API_KEY у AI Studio, а потім експортуйте його у своєму шеллі:

export GOOGLE_API_KEY=<your key>

Щоб уникнути експорту після кожного перезапуску терміналу, помістіть ключ у файл .env та додайте це до скрипту:

from dotenv import load_dotenv
load_dotenv()

Проблеми з API

Незнання функції client.models.generate_content() було однією з причин проблем, а на сторінці представлення продукту Google був наведений код, який використовував новішу API Interactions (client.interactions.create()), що свідчило про те, що функція агентських відео не підтримується у старішій API generate_content, поки документація не підтвердила протилежне. Також не було зрозуміло, як і чи можна вказувати певні параметри, такі як резюме міркувань. До цього додалися зміни в API Interactions у травні 2026 року, а також циклічні відповіді від веб-чату Gemini, через що початок роботи зайняв кілька годин спроб та припущень.

Порожні резюме міркувань

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