Как я добавил ИИ-ассистента в приложение Okhana

«Мы куда записали время тренировки?» Вроде простой вопрос. Только ответ может лежать в заметке, задача - в другом разделе, а человек уже пишет в общий чат. Мне хотелось, чтобы в Okhana с такими вещами можно было разобраться одним сообщением.

Okhana - мой собственный продукт для семейных дел: заметок, задач, календаря и памятных дат. Я добавил туда ИИ-ассистента, который может найти запись и выполнить действие внутри приложения. Рассказать, как это устроено, удобнее на конкретном запросе.

Допустим, пользователь просит: «Найди заметку про тренировку». Ассистент должен обратиться к данным этой семьи, получить подходящие записи и составить ответ по найденному. Если следующая просьба - поставить задачу, потребуется ещё и запись в базу. На каждом шаге есть прикладная работа: поиск, проверка доступа, разбор параметров, обработка ошибки.

Подробности самого продукта собрал в кейсе Okhana. Здесь разберу именно интеграцию ИИ и то, как этот подход можно применить в вашем приложении.

01 / НАЙТИ НУЖНОЕ

Начал с данных, которые уже были в приложении

У модели нет доступа к семейным заметкам «из коробки». Я дал ей отдельный инструмент поиска. Она передаёт поисковую фразу, сервер находит подходящие записи, возвращает ограниченную выборку, и уже по ней модель отвечает человеку.

В текущей версии поиск заметок работает через PostgreSQL ILIKE: ищет фрагмент текста в заголовке и содержимом без учёта регистра. Рядом в том же запросе стоят фильтр семьи и условия видимости записи. Саму SQL-команду модель не пишет.

Запрос пользователя
  → инструмент search_notes
  → фильтры семьи и доступа
  → ILIKE по заголовку и тексту
  → найденные записи
  → ответ ассистента

Поиск по фрагменту понятен и полезен, когда человек помнит слово из записи. Но «про стоматолога» и «приём у зубного» для ILIKE - разные формулировки. Здесь проходит граница, после которой стоит смотреть в сторону полнотекстового, векторного или гибридного поиска.

Где здесь RAG

RAG, Retrieval-Augmented Generation, - подход, при котором ответ модели дополняют найденными данными. В Okhana эту роль выполняют результаты инструмента поиска. Используется текстовый поиск по заметкам, без эмбеддингов и векторной базы.

Для корпоративной базы знаний механизм поиска можно расширить: загружать документы, разбивать их на фрагменты, искать по смыслу и возвращать ответ со ссылкой на источник. Задача та же: дать модели подходящие сведения, прежде чем просить её отвечать. Способ найти эти сведения выбирается под ваши данные.

02 / СДЕЛАТЬ ДЕЛО

«Готово» должно означать выполненную операцию

Красивый ответ мало помогает, если после него нужно вручную открывать календарь и повторять всё заново. Поэтому в Okhana я связал ассистента с инструментами для заметок, задач и календаря. Для них описаны допустимые параметры, а исполнение остаётся на сервере приложения.

1. Модель предлагает вызов инструмента

   Например, создание задачи с определёнными параметрами.

2. Приложение проверяет запрос

   Параметры проходят проверку по схеме. Пользователь и семья берутся из серверного контекста.

3. Сервер выполняет операцию

   Использует прикладную логику и возвращает результат или ошибку.

4. Ассистент отвечает по результату

   Получает сведения о выполнении, чтобы сообщить человеку, что произошло.

В цикле работы с инструментами у меня стоит ограничение на число итераций. Это помогает удержать один запрос в понятных пределах: ассистент не должен бесконечно вызывать сам себя и тратить лимит провайдера.

В бизнес-приложении таким действием может быть создание обращения, подготовка задачи менеджеру или изменение статуса. Для оплаты, удаления важных данных и других чувствительных операций я бы отдельно проектировал подтверждение человеком, журнал действий и защиту от повторного выполнения.

03 / ДОСТУП

Личная заметка не становится общей из-за чата

В семейном приложении есть общие дела и личные записи. Если обычный интерфейс скрывает заметку, поиск ассистента тоже должен её скрыть. Поэтому условия доступа применяются в запросе к базе, до получения результатов и отправки их модели.

Промпт «не показывай чужие данные» не заменяет эту проверку. Пользователь может попросить показать всё, а модель может ошибиться при выборе инструмента. Сервер всё равно должен вернуть только разрешённое.

Для компании тот же вопрос возникает между отделами, филиалами и клиентскими аккаунтами. При разработке ИИ-ассистента я сначала выясняю, кто что вправе видеть и менять. После этого можно обсуждать модель, голосовой ввод и удобство диалога.

04 / ПОДКЛЮЧЕНИЕ МОДЕЛЕЙ

Зачем я написал Go AI Proxy

Когда ИИ появляется в нескольких продуктах, неудобно в каждом заново разбирать ключи, адреса API и особенности провайдеров. Ещё есть квоты, ошибки и доступность конкретной модели. Я вынес подключение в свой сервис Go AI, написанный на Go.

Приложение обращается к серверному шлюзу через интерфейс чата, совместимый с форматом OpenAI. Шлюз выбирает провайдера по алиасу модели. Ключи остаются на сервере. В связке есть потоковые ответы, передача вызовов инструментов и резервный маршрут через OpenRouter для части сбоев основного провайдера.

Так я убрал зависимость клиентского интерфейса от прямого подключения к каждому внешнему API. Ограничения удобнее разбирать в одном месте: какой маршрут доступен, где закончилась квота, какую модель можно переключить. При этом лимиты и правила самих провайдеров продолжают действовать; оборвавшийся поток тоже нельзя автоматически считать успешно восстановленным.

В Okhana шлюз передаёт запросы и результаты модели. Поиск заметок, проверка доступа и создание задач выполняются самим приложением. Благодаря этому смена AI-провайдера не требует переносить ему бизнес-логику продукта.

05 / КОГДА ДАННЫХ СТАНЕТ БОЛЬШЕ

Где пригодятся LlamaIndex, pgvector и LangGraph

Если у вас тысячи инструкций, договоров или карточек, поиска по совпадению текста может оказаться мало. Для такой задачи я предложу другой набор инструментов. Вот три варианта, которые стоит рассматривать под конкретные требования.

В текущем поиске заметок Okhana этих библиотек нет. Их имеет смысл подключать, когда появляется соответствующая задача. До выбора инструмента я бы собрал реальные вопросы сотрудников и проверил, какие сведения нужны для правильного ответа. На таком наборе уже можно сравнивать варианты поиска.

06 / ДЛЯ ВАШЕГО ПРОДУКТА

Что можно собрать по этому принципу

Семейное приложение хорошо показывает связь между вопросом, данными и действием. В компании источники будут другими, но сценарий можно построить так же. Вот несколько задач, с которыми ко мне можно прийти.

Помощник для сотрудников

Находит нужный пункт в инструкции или регламенте, показывает источник, помогает оформить внутренний запрос. Заранее определяем доступные документы и поведение, если ответа в них нет.

Ассистент в личном кабинете

Получает данные конкретного клиента, объясняет статус обращения, собирает недостающие сведения и создаёт заявку. Права пользователя сохраняются на каждом шаге.

Работа с задачами и обращениями

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

Для таких проектов я могу спроектировать интерфейс, подключить данные и API, реализовать инструменты агента и серверную часть. О подходе к работе подробнее написал на страницах ИИ-интеграций и разработки веб-приложений.

07 / ПЕРВЫЙ ШАГ

Начать можно с одного повторяющегося вопроса

Я бы не начинал внедрение с обещания «автоматизировать весь отдел». Лучше взять частую задачу, для которой уже есть данные и понятный результат. Найти условия в документе. Подготовить обращение. Поставить задачу из сообщения.

Пришлите несколько примеров таких запросов и покажите, где сейчас хранятся ответы. Я разберу, что можно подключить, какие права нужны ассистенту и что войдёт в первую рабочую версию. Проверять её будем на ваших вопросах: нашла ли нужное, не показала ли лишнего, выполнила ли действие.

Посмотреть мою реализацию можно в кейсе Okhana, а познакомиться с продуктом - на okhanahome.com.