TL;DR
LLM-агенты для автоматизации UI (тестирование приложений, AI-помощники) тратят 80-99% всех токенов на UI-представления — деревья DOM и accessibility trees, описывающие структуру интерфейса. Одна простая кнопка поиска превращается в 8-12 узлов XML из-за того, как разработчики строят интерфейсы: отдельные слои для стилей, layout, обработки событий. Для LLM это избыточность, но вырезать её опасно — можно удалить важную информацию.
UIFORMER автоматически синтезирует программы-трансформации через domain-specific language (DSL) с тремя операциями: фильтрация (удалить ненужные узлы), слияние (объединить родителя с детьми), пропуск (оставить как есть). Программы работают локально — на парах родитель-ребёнок, а не на всём дереве сразу. Это снижает сложность и делает трансформацию безопасной.
Итеративная генерация через code LLM: создай программу → примени к UI-деревьям → оцени эффективность (сколько токенов сэкономили) и полноту (не потеряли ли важную информацию) → дай feedback → улучши программу. Цикл до сходимости. Результат: библиотека проверенных трансформаций, которые сокращают токены на 48.7-55.8% без потери качества работы агента.
Схема метода
ОФЛАЙН-ФАЗА (синтез программ):
ШАГ 1: Code LLM генерирует программу в DSL
→ Код с операциями FILTER/MERGE/PASS-THROUGH
ШАГ 2: Применить к тренировочным UI-деревьям
→ Трансформированные деревья
ШАГ 3: Оценить эффективность + полноту
→ Reward = сокращение токенов × сохранение семантики
ШАГ 4: Если reward низкий → feedback → вернуться к Шагу 1
→ Улучшенная программа
ШАГ 5: Если reward достаточный → в библиотеку
→ Проверенная программа добавлена
RUNTIME-ФАЗА (применение):
UI-дерево от приложения
↓
UIFORMER-плагин применяет программу
↓
Оптимизированное дерево → LLM-агенту
Контекст исследования
Проблема: LLM-агенты для автоматизации UI (автотесты, AI-ассистенты в приложениях) получают на вход UI-деревья — структурированное описание интерфейса. Простая кнопка = 8-12 XML-узлов. Поисковая строка содержит отдельные узлы для: контейнера, placeholder текста, границ input field, иконки, фона, обработки событий. 80-99% всех токенов агента уходит на UI-представления, остальное — инструкции, history, форматирование.
Почему так происходит: Разработчики строят интерфейсы иерархически для модульности и производительности. Один визуальный компонент = множество технических слоёв. Для LLM это семантическая избыточность.
Существующие решения не работают: - Пропустить UI через LLM для упрощения → парадокс: сначала потратили все токены на чтение сырого дерева, потом на упрощение. Токенов стало больше, а не меньше. - Эвристики (взять только leaf nodes, удалить "неважные" элементы) → теряют структуру и важный контекст, ломая работу агента.
Решение UIFORMER: синтез программ трансформации через DSL + итеративная оптимизация с проверкой эффективности и полноты.
Как это работает (механика)
Почему нельзя в лоб: 1. Комбинаторный взрыв: для дерева из _n_ узлов есть 2^_n_ вариантов удаления узлов. Перебор невозможен даже для средних интерфейсов. 2. Нет Boolean oracle: в обычном program synthesis есть чёткий критерий правильности (тесты прошли/не прошли). Здесь — multi-objective оптимизация: максимизировать эффективность (меньше токенов) + максимизировать полноту (сохранить семантику). Нет единого "правильного ответа".
Ключевой инсайт: UI-деревья сложны из-за кумулятивной фрагментации — множества избыточных поддеревьев, где каждое можно упростить локально. Не нужно оптимизировать всё дерево сразу. Достаточно рекурсивно применять простые операции parent-child снизу вверх.
DSL — ограниченное пространство операций:
Вместо генерации произвольного кода, code LLM создаёт функцию transform_node(parent, children) с тремя операциями:
- FILTER: удали узлы по условию (например, if node.type == "decoration": return [])
- MERGE: объедини родителя с детьми (например, если у контейнера один ребёнок — слей их в один узел)
- PASS-THROUGH: оставь структуру (если граница компонента семантически важна)
DSL делает задачу проще: LLM пишет не программу "как оптимизировать всё дерево", а правила "когда безопасно объединить два узла".
Итеративная генерация: 1. Code LLM генерирует программу в DSL 2. Применяем к тренировочным UI-примерам 3. Считаем reward = (токены сэкономлены) × (семантика сохранена) 4. Если reward низкий → feedback ("программа слишком агрессивна, удалила важные элементы" или "недостаточно сократила") → генерируем новую версию 5. Повторяем до сходимости
Runtime применение: UIFORMER работает как плагин-прослойка между приложением и агентом: - Перехватывает UI-дерево - Применяет синтезированную программу - Отдаёт агенту оптимизированное представление
Агент не знает про оптимизацию — для него это прозрачно.
Ограничения
⚠️ Требует инфраструктуру: UIFORMER работает как плагин в системе LLM-агентов. Нужен доступ к сырым UI-деревьям (accessibility trees, DOM), код для запуска трансформаций, интеграция с агентским фреймворком. Не применимо напрямую в чате ChatGPT/Claude.
⚠️ Офлайн-фаза требует примеров: синтез программ нуждается в тренировочных UI-деревьях для конкретной платформы (Android/Web). Для новых типов интерфейсов (например, desktop apps, VR) нужна пересинтезация.
⚠️ DSL ограничивает выразительность: только локальные операции parent-child. Если семантически нужно объединить узлы из разных частей дерева — DSL не справится.
Extractable-принципы для работы в чатах
Принцип 1: Оптимизируй структурированные данные ДО загрузки
Проблема из исследования: UI-деревья огромны из-за технической фрагментации. LLM получает массу избыточной информации.
Применение в чатах: Если работаешь с большими структурированными файлами (JSON, XML, CSV, логи), оптимизируй их перед загрузкой в чат:
ДО загрузки (вручную или простым скриптом): - Удали атрибуты/поля, не важные для задачи - Объедини дублирующиеся записи - Сократи глубину вложенности (если 5 уровней, а нужно 2) - Оставь только примеры, если данные повторяются
Пример: У тебя API response с 1000 полей, а задача — анализ только статистики продаж.
❌ Плохо:
Загрузить весь JSON (5000 токенов)
→ "Проанализируй продажи"
→ LLM обработает всё, включая мусор
✅ Хорошо:
1. Вручную убрать metadata, internal_ids, timestamps
2. Оставить только sales_count, revenue, product_name
3. Загрузить 500 токенов
→ "Проанализируй продажи"
Это прямая аналогия UIFORMER: фильтрация + слияние ДО передачи в LLM.
Принцип 2: Локальные правила вместо глобальной оптимизации
Проблема из исследования: Оптимизировать всё дерево сразу = комбинаторный взрыв. DSL работает локально — parent-child.
Применение в чатах: Когда упрощаешь сложные данные/тексты, дай LLM локальные правила, а не "упрости всё".
Пример: Большой документ с повторяющимися секциями.
❌ Плохо:
"Сократи этот документ"
→ LLM угадывает что важно
✅ Хорошо:
"Примени правила:
1. Если секция повторяет структуру — оставь одну как пример
2. Если абзац начинается с 'Как отмечено выше' — удали
3. Если список > 5 пунктов одного типа — сократи до 3 примеров"
Локальные правила = предсказуемость + контроль.
Принцип 3: Итеративная оптимизация с проверкой
Проблема из исследования: Нельзя определить "правильность" трансформации в один шаг. Нужна итерация: трансформация → проверка полноты → корректировка.
Применение в чатах: При сжатии информации используй двухшаговый процесс:
ШАГ 1: Попроси сократить
ШАГ 2: Попроси проверить, не потеряно ли важное
Промпт:
"Сократи этот текст до 30% от объёма, сохрани все ключевые факты.
Потом проверь: пройдись по оригиналу и выпиши факты, которые потерялись.
Если потеряно важное — добавь в сокращённую версию."
Это аналог reward функции UIFORMER: эффективность (сжатие) + полнота (проверка потерь).
Промпт: двухшаговое сжатие с проверкой полноты
Задача: сократить {текст/данные/документ} с сохранением ключевой информации.
ШАГ 1: ОПТИМИЗАЦИЯ
Сократи следующий {тип_данных} применяя правила:
- Удали: {что_удалить — например, "дублирующиеся примеры, метаданные, технические детали"}
- Объедини: {что_объединить — например, "однотипные секции в одну"}
- Сохрани: {что_важно — например, "все цифры, выводы, уникальные факты"}
Целевой объём: {X}% от оригинала или {Y} токенов.
{вставить данные}
---
ШАГ 2: ПРОВЕРКА ПОЛНОТЫ
Теперь сравни оригинал и сокращённую версию:
1. Выпиши информацию из оригинала, которая потерялась
2. Оцени: критична ли она для {задачи}?
3. Если критична — добавь в сокращённую версию
Финальный вывод: оптимизированные данные + список того, что намеренно удалено.
Пояснения плейсхолдеров:
- {текст/данные/документ} — что сжимаешь
- {тип_данных} — JSON, XML, статья, логи, таблица
- {что_удалить}, {что_объединить}, {что_важно} — конкретные правила для твоих данных
- {задачи} — зачем нужна информация (анализ продаж, резюме встречи, etc)
Как исследовали
Команда из Peking University и Tencent проверила UIFORMER на трёх бенчмарках: AndroidControl (навигация в Android-приложениях), Mind2Web (веб-навигация), реальное production-развёртывание в WeChat. Тестировали с пятью LLM (GPT-4o, DeepSeek-V3, Qwen-2.5 и другие) и тремя типами агентов (ReAct, AppAgent, Mobile-Agent-V2).
Дизайн эксперимента: 1. Сначала измерили baseline: сколько токенов тратят агенты на UI-представления в оригинале. Результат — 80-99% всех токенов уходит на UI (от 2,751 токенов на AndroidControl до 51,648 на Mind2Web). 2. Синтезировали программы трансформации через UIFORMER: code LLM (GPT-4) генерирует DSL-программы, итеративно улучшая их с feedback по эффективности и полноте. 3. Применили трансформации и замерили: сокращение токенов, качество работы агента (task success rate), runtime оверхед.
Результаты показали контринтуитивный эффект: токены сократились на 48.7-55.8%, а качество работы агента улучшилось в 60% случаев. Почему? Уборка "шума" из UI-представлений помогла LLM лучше фокусироваться на важном. В WeChat production UIFORMER дал +35% QPM (queries per minute) и -26.1% latency.
Ключевой инсайт: оптимизация UI — это не trade-off между эффективностью и качеством. Правильная оптимизация улучшает оба показателя, потому что убирает когнитивную нагрузку с LLM.
Ресурсы
From User Interface to Agent Interface: Efficiency Optimization of UI Representations for LLM Agents Dezhi Ran, Zhi Gong, Yuzhe Guo, Mengzhou Wu, Yuan Cao (Peking University), Haochuan Lu, Hengyu Zhang, Xia Zeng, Gang Cao, Liangchao Yao, Yuetang Deng (Tencent Inc.), Wei Yang (University of Texas at Dallas), Tao Xie (Peking University)