Иногда нужно для теста использовать API чатботов . С помощью Github можно получить бесплатно некоторые модели, до 150 запросов в день.

Ниже небольшой чат-клиент на Python для работы с моделями через GitHub Models (бесплатное API). Для работы с API нужен аккаунт на сервисе, карта не нужна.

Как получить API доступ
Идем сюда
https://github.com/marketplace/models
Выбираем модели. Если думаете какую выбрать - перейдите сюда.
Тут описаны лимиты и как использовать.


Небольшой пример по запросам к API gpt-4o
https://github.com/Devvver/gemini_csv_parser/blob/main/githubchatgptapi.py


Что реализовано в приложении:

➡️ ввод GitHub Personal Access Token в боковой панели
➡️ выбор модели: gpt-4o / gpt-4o-mini / o1-mini
➡️ обработка ошибок и лимитов (в т.ч. 429)

Подходит как готовый шаблон для:
➡️ быстрого тестирования GitHub Models,
➡️ внутреннего AI-чата для команды,
➡️ прототипов ассистентов под свои сервисы.

▶️ Неудачный опыт создания чатбота на локальных данных.

Обычно никто не пишет о своих неудачах, но тут мой опыт важен, так как возможно кто то пойдет моим путем и не потратит время как я.

Я попытался построить RAG (Retrieval-Augmented Generation) на своем ноутбуке без мощной видеокарты и проца.

Что я делал:
👉 беру документы (в моём случае - HTML-файлы, около 3000)
👉 режу текст на чанки
👉 считаю для каждого chunks embeddings (векторы)
👉 сохраняю эти векторы в векторное хранилище
👉 при запросе в чатботе:

▶️считаю embedding запроса
▶️ищу по векторной базе самые похожие фрагменты
▶️передаю найденные куски в LLM как контекст для ответа

Реализовал все это на AnythingLLM , векторизация иногда создавалась до 6 часов (зависит от параметров ноута).

➡️Результаты:
Как я не тестил, с какими параметрами не пробовал, результаты отрицательные. Основная проблема кроется в нехватке LLM токенов для анализа информации.
Данные в html содержат более 20К текста в среднем и даже после резки на чанки не хватает контекста.

При использовании локальных LLM (LLama 4 и другие, перебрал с полдесятка) чатбот неизбежно галлюцинирует из за объема текста который в него подается.
Если в настройках ограничивать поиск, устанавливая более высокий порог сходства документов (>0.75) контекта иногда хватает, но режется большее количество данных и чатботу не хватает данных для анализа.

Пробовал использовать API доступ к моделям GROK которые доступны по API (не локальные), поиск улучшается, можно уменьшать порог сходства, но проблему галлюцинаций это не решает.

Итог отрицательный. Если кому то удалось - напишите в личку, поделитесь опытом.

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

Вот основные аспекты работы, описанные языком поисковой оптимизации и анализа пользовательского пути:

➡️1. Интент как последовательность действий (User Journey)

В SEO мы привыкли работать с интентом поискового запроса. Авторы исследования идут глубже и формализуют задачу извлечения интента (Intent Extraction) из целой «траектории» действий пользователя.
Траектория — это последовательность скриншотов и конкретных кликов/свайпов.
Цель — сгенерировать описание того, что пользователь на самом деле пытался достичь (например, «купить билет в Лувр»).
Для SEO это важно, так как подчеркивает: интент — это не статичное слово, а динамический процесс, который Google учится восстанавливать даже по обрывочным действиям.

➡️2. Двухэтапная архитектура: от микро-действий к макро-цели

Исследователи предложили метод декомпозиции, который позволяет даже малым моделям (small models), работающим на устройствах, превосходить по качеству понимания гигантские LLM (такие как Gemini 1.5 Pro).

Этап 1: Структурированное суммаризирование взаимодействия. Модель анализирует каждый отдельный шаг (скриншот + действие) и выделяет только важные детали экрана и суть клика.

Этап 2: Извлечение итогового интента. На основе агрегированных мини-отчетов со всех шагов формируется финальное описание цели.
SEO-инсайт: Точность понимания повышается, когда алгоритм сначала «сканирует» отдельные блоки/этапы страницы (структуру), а затем синтезирует их в общее понимание ценности страницы для пользователя.

➡️3. Критерии «качественного» интента

В работе четко определены три параметра, по которым оценивается, насколько правильно модель поняла пользователя.

Эти критерии можно переложить на оценку качества контента:

☑️Faithfulness (Достоверность): описание должно соответствовать только тем действиям, которые реально произошли.
☑️Comprehensiveness (Полнота): наличие всей информации, необходимой для воспроизведения действий.
☑️Relevance (Релевантность): отсутствие лишнего «шума», не относящегося к достижению цели.

➡️4. Борьба с «галлюцинациями» и шумом в данных

Авторы столкнулись с проблемой: при обучении модели часто «додумывают» детали, которых не было на экране (галлюцинируют). Чтобы решить это, они использовали Label Refinement — очистку обучающих данных от любой информации, которую нельзя напрямую вывести из скриншотов.
Это напоминает работу с поисковыми сниппетами: если в описании (description) указано то, чего нет на странице, это снижает доверие и качество опыта. Google стремится к тому, чтобы описание интента было максимально очищено от субъективности.

➡️5. Метрики понимания: BiFact vs BLEU

Интересен подход к оценке. Традиционные SEO-метрики (вроде текстового совпадения ключей) здесь сравниваются с лексическими метриками (BLEU/ROUGE), которые работают плохо, так как оценивают только совпадение слов. Вместо них Google использует семантические метрики, такие как BiFact, которые разбивают интент на атомарные факты и проверяют их точность и полноту. Это подтверждает тренд на Entity-based SEO и переход от анализа «ключевиков» к анализу «смысловых сущностей».

Почему это важно для будущего SEO?

Поиск становится агентским: Google активно развивает модели, которые смогут не просто выдавать ссылки, но и выполнять действия за пользователя (UI Automation). Понимание интента — фундамент для этого.

Визуальный контекст решает: Модели теперь «видят» структуру сайта (DOM, иерархию, кнопки) почти как человек. Оптимизация интерфейса (UI/UX) становится прямой частью поисковой оптимизации.

Локальные модели: Акцент на малых моделях, работающих on-device (прямо в браузере или телефоне), означает, что понимание пользователя будет происходить мгновенно и приватно, без обращения к облачным серверам, что ускоряет персонализацию выдачи.