Observer - бесплатное приложение с открытым кодом для iOS и Android, которое запускает локальные модели прямо на смартфоне и превращает камеру в систему мониторинга событий. Автор, разработчик под ником Roy3838, показал демо в r/LocalLLaMA: приложение смотрит на сцену через камеру, само определяет, случилось ли заранее описанное событие, и выполняет действие - отправляет фото, пишет в Telegram или звонит на телефон. Обработка идёт на устройстве, облачный сервис распознавания не нужен.
По умолчанию в приложении две модели: OneJev-0.8b для принятия решений и qwen-0.8b в роли LLM-наблюдателя. По словам автора, обе работают даже на старых телефонах, которые обычно лежат в ящике стола. Независимых замеров скорости и точности на момент публикации нет, так что это обещание, а не результат теста.
Код лежит в открытом репозитории на GitHub, сборки доступны в App Store и Google Play. Ниже - как устроен цикл мониторинга, что реально ждать от моделей на 0.8b, как формулировать свои сценарии и где подход ломается.
Что такое Observer и зачем он нужен
Задача узкая и понятная: не пропустить событие, которое видно в камеру. Пользователь описывает ситуацию словами, приложение следит за кадром и в нужный момент присылает сигнал. Всё делает одна программа на телефоне, без сервера и без API-ключей.
Кто стоит за проектом и где его взять
Проект ведёт один разработчик под ником Roy3838. Демо и ссылки на сборки он выложил в сабреддит r/LocalLLaMA: пост с демонстрацией и приглашением попробовать. Исходники опубликованы на GitHub в репозитории Observer, готовые сборки - в App Store под именем observer-ai и в Google Play под идентификатором com.observer.ai. Приложение бесплатное.
Открытый код здесь не формальность. Инструмент постоянно смотрит через камеру и запускает модели на телефоне, поэтому возможность проверить, что именно происходит внутри, весит больше обычного.
Какие сценарии показаны в демо
В ролике пять примеров, и все бытовые:
- уведомление с фотографией, когда к машине подходит человек, кроме владельца;
- сообщение в Telegram с фото, когда птица садится в гнездо;
- звонок, когда стиральная машина начинает цикл полоскания;
- уведомление, когда собака доела корм;
- звонок, когда в спортзале освободился тренажёр.
Это личные примеры автора, а не каталог поддерживаемых функций. Ни в демо, ни в обсуждении не раскрыто, какие сценарии приложение отработает стабильно, а какие рассыплются на первом похожем кадре.
Качество картинки в ролике автор сам называет плохим и объясняет спешкой: хотелось выпустить демо к релизу, об этом он пишет в том же посте. Для оценки точности распознавания это плохая новость: смотреть на демонстрацию и делать выводы о надёжности агента нельзя.
Как устроен локальный AI-агент на телефоне
Схема цикла читается по названиям моделей. Камера даёт поток кадров. LLM-наблюдатель (qwen-0.8b) смотрит на сцену и соотносит её с условием сценария. Модель принятия решений (OneJev-0.8b) получает результат наблюдения и решает, наступило событие или нет, а если наступило - какое действие запускать. Дальше срабатывает действие: пуш с фотографией, сообщение в Telegram, звонок.
Точные детали не раскрыты. В источниках нет ни промптов, ни частоты обработки кадров, ни данных о том, как кадры попадают в модель и в каком виде наблюдатель передаёт результат решающей модели. Не описано и то, на чём работает инференс: собственный рантайм, обёртка над готовой библиотекой или что-то ещё. Схему выше стоит воспринимать как логику, восстановленную по назначению двух моделей, а не как документацию архитектуры.
Разделение на наблюдателя и решающую модель экономит ресурсы: работа с изображением достаётся одной модели, вторая отвечает за короткий вывод «сработало / не сработало» и выбор действия. Приём типичный для локальных агентов. На десктопе Observer развивается по той же логике, только следит за экраном и работает через llama.cpp или браузерный рантайм на transformers.js - детали в разборе веб-версии и десктопного клиента.
Роль LLM-наблюдателя и модели принятия решений
Наблюдатель отвечает на вопрос «что происходит в кадре». Решающая модель - на вопрос «пора реагировать». Для сценария «птица в гнезде» наблюдатель фиксирует наличие объекта в зоне, решающая модель проверяет, совпадает ли это с условием, и выбирает канал уведомления.
Практический смысл разделения в том, что сценарий меняется без переобучения: новое условие - это новый текст задачи, а не новая модель. Насколько хорошо такой подход работает на 0.8b, зависит от формулировки условия и от того, насколько признак различим на картинке.
Почему выбраны модели на 0.8b
0.8b - меньше миллиарда параметров. Такие модели влезают в память телефона, работают без сервера и не требуют GPU уровня десктопа. Плата за компактность очевидна: меньше знаний, слабее рассуждения, выше шанс ошибки на непривычной сцене.
Заявление автора о работе на старых телефонах логично следует из размера моделей, но остаётся заявлением. Требований к устройству, объёму RAM и версии ОС в источниках нет.
Модели OneJev-0.8b и qwen-0.8b: что важно знать
Известно немного. Обе модели имеют размер 0.8b, обе стоят по умолчанию, обе, по словам автора, запускаются на старых телефонах (пост с демо). Про OneJev-0.8b в источниках нет данных о происхождении, обучении и метриках: непонятно, кто её выпустил и на каких данных она готовилась. qwen-0.8b упоминается без указания версии, а у семейства Qwen поколений несколько, и по качеству они различаются заметно.
Практический вывод: прежде чем строить на Observer что-то важное, откройте репозиторий и посмотрите, какие файлы моделей скачиваются и под какой лицензией. Это единственный способ получить точные ответы вместо догадок.
Что это значит для точности распознавания
Простые визуальные события даются маленьким моделям лучше: объект появился в кадре, объект исчез, в зоне началось движение, человек подошёл к машине. Тонкие сценарии сложнее: «цикл полоскания» нужно отличить от стирки и отжима по индикаторам, а «собака доела корм» - от «собака мордой в миске». Чем больше в условии скрытых признаков, тем выше шанс ложного срабатывания.
Оценить точность по демо нельзя: автор сам говорит, что качество камеры в ролике плохое из-за спешки. Плохой кадр усложняет задачу и модели, и зрителю.
Как настроить собственные сценарии мониторинга
Логика сценария описывается фразой «когда X - сделай Y». X - наблюдаемое через камеру событие, Y - действие. Процедура добавления своего сценария в источниках не расписана: автор ограничился утверждением, что так можно мониторить почти всё. Конкретные шаги в интерфейсе нужно смотреть в самом приложении и в README репозитория.
Как формулировать условия, чтобы не ловить ложные срабатывания
Правила простые и работают для любой маленькой модели. Условие описывает один объект и одно изменение. Зону кадра лучше ограничить: «птица в гнезде» надёжнее, чем «птица во дворе». Признак должен быть виден на картинке, а не подразумеваться: «машина на месте» проверить проще, чем «машину никто не трогал».
Второе правило касается действия. Для регулярных, но некритичных событий подходит уведомление с фото или сообщение в мессенджер. Звонок стоит оставить для ситуаций, где нужна немедленная реакция: он прерывает пользователя и плохо переносит поток ложных срабатываний.
Какие действия поддерживаются
В демо показаны три варианта: push-уведомление с фотографией, сообщение в Telegram с фото и звонок на телефон. За пределы демо список не расширяется, других интеграций автор не показывал. Telegram в этой схеме - обычный канал доставки: кадр покидает устройство, если пользователь сам выбрал такой сценарий.
| Событие из демо | Что видит камера | Действие в демо |
|---|---|---|
| Человек подошёл к машине | появление объекта в заданной зоне | уведомление с фото |
| Птица в гнезде | объект в ограниченной зоне | сообщение в Telegram с фото |
| Стиральная машина на полоскании | индикаторы и положение переключателя | звонок |
| Собака доела корм | пустая миска, отсутствие собаки у миски | уведомление |
| Освободился тренажёр | отсутствие человека в зоне | звонок |
Таблица раскладывает сценарии автора по сложности наблюдаемого признака. Это оценка подхода, а не результат замеров: как поведёт себя конкретная сборка на конкретном телефоне, показывает только запуск.
Ограничения и риски локального мониторинга на смартфоне
Ограничения вытекают из самой идеи: постоянная работа камеры, модели на 0.8b и один разработчик в роли команды.
Нагрузка на смартфон и нагрев
Камера плюс инференс моделей - ресурсоёмкая связка. При долгой работе телефон греется, а система снижает частоту процессора и яркость, чтобы не перегреться. На практике это означает падение частоты обработки кадров и пропущенные события. Замеров энергопотребления и температуры в источниках нет, поэтому проверять придётся на своём устройстве и в реальном режиме: сутки на зарядке, сутки на батарее.
Приватность: что значит «100% local»
Автор называет приложение на 100% локальным: кадры обрабатываются на телефоне. Схема с моделями на устройстве с этим согласуется, облачный сервис распознавания в такой архитектуре не нужен.
Граница приватности проходит по каналам доставки. Сценарий с Telegram отправляет фото во внешний сервис, и это выбор пользователя, а не особенность Observer. Отдельно стоит проверить разрешения приложения в настройках ОС: доступ к камере и уведомлениям. Код открыт, так что сетевую активность можно посмотреть самостоятельно.
Ещё один риск - сам сценарий. Камера, направленная на улицу или в подъезд, снимает людей, которые согласия не давали. Локальная обработка снимает вопрос передачи данных в облако, но не отменяет вопросов о том, куда смотрит объектив.
Кому подходит Observer, а кому нет
Подходит тем, кто уже возится с локальными моделями и хочет увидеть агента на устройстве, а не в терминале. Вторая аудитория - владельцы запасных телефонов: если приложение правда работает на старом железе, телефон с полки превращается в камеру с аналитикой. Разработчикам интересен сам подход: две маленькие модели, разделение наблюдения и решения, действия в реальном мире.
Не подходит тем, кому нужна охрана с гарантией. Пропущенное событие здесь вероятно: камера телефона уступает специализированной, модель на 0.8b ошибается, требований к устройству автор не публиковал. Для критичных задач вроде протечки или пожара такой мониторинг не заменяет датчики.
Статус проекта и чего ждать от текущей версии
Это проект одного разработчика, показанный через демо в r/LocalLLaMA. Сборки в App Store и Google Play есть, код открыт, но демо выпускалось в спешке, о чём автор говорит прямо. Ожидания стоит выравнивать по этому факту: перед нами эксперимент, а не продакшн-система.
У Observer есть и другие ветки развития - слежение за экраном вместо камеры, с уведомлениями в мессенджеры и локальной обработкой. Как проект менялся за год и что там с архитектурой, разобрано в материале об эволюции Observer.
Итог: стоит ли запускать Observer на своём телефоне
Observer даёт то, что редко встречается в готовом виде: бесплатное приложение с открытым кодом, где локальные модели крутятся на телефоне и сами запускают действия. Порог входа низкий - поставить сборку и описать событие словами. Дальше начинаются компромиссы: модели на 0.8b, качество камеры, нагрузка на устройство и нераскрытая архитектура.
Разумный первый шаг - один простой сценарий и одно действие. Например, уведомление с фото, когда в кадре появляется человек в заданной зоне. Погоняйте его сутки, посмотрите на долю ложных срабатываний и на температуру телефона. Устраивает результат - добавляйте Telegram и звонок. Перед запуском загляните в репозиторий: там видно, какие модели скачиваются, и это снимает вопросы про локальность и лицензии.