[Офигеваю с того, как расширяется функционал для ИИ-агентов]

Раньше думал, что LLM просто всё знает из своих данных. Оказалось, можно подключить её к интернету через готовые тулы!

Tavily - это поисковик для ИИ, который ищет по надежным источникам и отдает факты модели. А ещё есть тулы для Википедии и даже Python REPL, чтобы ИИ мог выполнять код.

Выглядит как магия, но под капотом - просто инструменты, которые делают агента функциональнее.

P.s.
у Tavily есть 1000 запросов в месяц бесплатно.

——
Ссылки:
https://www.tavily.com/

[Интеграция ИИ и Википедии]

Попробовал тул WikipediaQueryRun, с помощью которого ИИ-агент может ходить в Википедию и получить актуальную информацию.
Проверил работу 2-х модей: "mistral-large-latest" и локальной "llama3.2:3b".

Была задача ответить на 2 вопроса:
"Сколько лет прошло с появления передачи Топ Гир в эфире? Кто её ведущий сегодня?"

Обе модели отправили запросы в Википедию, получили по 3 страницы на изучение. И на основании полученных данных дали ответ.

Мистраль дала верный ответ:

С момента первого выхода передачи *Топ Гир* в 1977 году прошло **48 лет**.

Что касается ведущих, то на данный момент производство британской версии *Top Gear* приостановлено на неопределённый срок. Последние известные ведущие включали Криса Харриса, Фредди Флинтоффа и Рори Рида. Однако после аварии Фредди Флинтоффа в 2023 году съёмки были приостановлены, и будущее шоу остаётся неопределённым.

llama3.2:3b дала абсолютно неверный ответ (предполагаю из-за плохой поддержки русского языка и малого размера контекста)

Сколько лет прошло с появления передачи Топ Гир в эфире - 13 лет.

Кто ведет передачу Топ Гир сегодня? - Ведущим передачи Топ Гир является Дарья Поварникова.

Для llama3.2:3b задал вопрос на английском языке и указал искать в английской Википедии.
Ответ получил связанный с Top Gear, но не тот, что ожидалось.

The Top Gear program first appeared on the air in 2002. As of 2024, the current presenter is Paddy McGuinness, along with Freddie Flintoff and Chris Harris.

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

Решил проверить работу с en-версией Википедии модель от Мистраль.
Вот результат

The original *Top Gear* program first appeared on TV in **1977**, but the modern and most well-known version of the show premiered on **20 October 2002**.

Calculating the years since 2002:
**2025 - 2002 = 23 years**

So, **23 years** have passed since the relaunch of *Top Gear* in 2002.

---

### Current Presenters (as of the latest available information):
The most recent presenting lineup of the British *Top Gear* (before the show was paused) included:
- **Chris Harris**
- **Andrew "Freddie" Flintoff** (though he left after an accident in 2023)
- **Paddy McGuinness**

However, the BBC announced that *Top Gear* would not return for the "foreseeable future" after Flintoff's departure. If there are updates or changes, I can check for the latest information.

Модель дала более развернутый ответ по сравнению с локальной моделью с некоторыми важными комментариями.

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

[RAG]

Познакомился с Retrieval-Augmented Generation (RAG).

Это технология, которая сочетает большие языковые модели (LLM) с внешними источниками информации для создания более точных и актуальных ответов. Вместо того чтобы полагаться только на данные, на которых была обучена модель, RAG сначала ищет релевантную информацию во внешних базах знаний, а затем использует её для генерации ответа.

Это что-то типа того, что писал ранее про тулы. Мы в модель передаем актуальную информацию из внешнего источника (например, Википедия или страницы из Интернета).

Ключевые преимущества
1) Актуальность:
RAG позволяет получать ответы на основе самой свежей информации, даже если она была добавлена в базу данных после обучения модели.
2) Точность:
Это снижает вероятность выдумывания ответов (галлюцинаций), поскольку модель опирается на проверенные внешние источники.
3) Специализированные знания:
RAG подходит для решения задач, требующих знаний в конкретной области, так как можно подключить LLM к специализированным базам знаний.

P.s.
Успел сегодня познакомиться с векторным поиском.
О векторах, векторизации, эмбеддингах и векторных базах данных напишу позже.

Пока успел реализовать простой пример с 2-я документами и 1 запросом, используя langchain_mistralai, model="mistral-embed" и langchain_core.documents.

Более релевантный документ имеет большее значение:

Relevant document score: 0.9297172135511551
Irrelevant document score: 0.7505634502492585

[Мониторинг AI-приложений]

Познакомился с open-source решением Arize Phoenix.

Инструмент предназначен для экспериментов, оценки и устранения неполадок в приложениях ИИ и LLM.

Для примера сделал небольшой RAG, который получает данные из PDF. Делит текст из документа на чанки по 600 символов.
Каждый чанк преобразуется в векторные представления (эмбендинги), которые сохраняются в векторное хранилище в оперативной памяти. После создается retriever, который получает 5 наиболее релевантных фрагмента из документа. Далее эти фрагменты передаются в качестве контекста в LLM.

Инструмент мне понравился. Легкая установка. Приятный и современный UI.
Множество вкладок и метрик по каждому шагу работы приложения.


———
Задал вопрос. Получил точный ответ из книги.

На скрине видно какие чанки из книги были выбраны для контекста LLM. В том числе фрагмент, который содержит точный ответ на вопрос.

Прикольно)

———
Ссылка на документацию:
https://arize.com/docs/phoenix

[Фреймворк Chainlit]

Сегодня познакомился с фреймворком Chainlit.
Это фреймворк, разработанный специально для создания приложений разговорного ИИ, то есть в формате чата.

Фреймворк понравился.

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


———
Ссылка на документацию:
https://docs.chainlit.io/get-started/overview

[Async vs Sync. Locust]

Мои тесты показали:
- RPS: 220 против 77 (разница в 2,85 раз)
- Response Time: 560ms против 4900ms (разница в 8,75 раз)
(см. скрин графиков)

Это наглядное сравнения производительности синхронного и асинхронного кода.

Тестировал 1 эндпоинт написанный на FastAPI в 2-х вариациях.
Проверял нагрузку на 500 юзеров.

Для моделирования нагрузки использовал Locust.
Это библиотека для симуляции нагрузки на сервер с минималистичным web-ui.

Прикольно)

[Еще один замечательный способ использования LLM в работе]

Проведение ревью в vscode и continue.

Сегодня вечером ко мне неожиданно обратился коллега из соседней команды, который подготовил MR с фичей для нашего платформенного бота.
Изменения достаточно большие, которые затрагивают все слои приложения.

Открыв diff в gitlab, первое что пришло в голову - "Пи***ц, как тут разобраться? Тут не просто новое? Здесь куча изменений в старом коде. Если проверять, то на это уйдет много времени (особенно когда уже забыл контекст и в памяти почти ничего не осталось о работе бота)."

Есть ИИ-боты в gitlab, которые прямо в MR оставляют свои комментарии. Это работает достаточно давно. И работает мягко скажем не очень (мое субъективное мнение, хотя опыта большого не было). Плюс в этой репе данного бота не было.

Решил попробовать ревью через агента локально.

1) Сначала просто скачал diff и скормил агенту (тоже самое можно было сделать через чат).
Он понял что хотел сделать разработчик и какой примерный контекст.
Дал ценные комментарии.

2) Потом я подумал дать доступ агенту ко всему проекту, подтянув ветку.
Сначала почему-то подумал что у агента нет доступа к git.
На мой вопрос "Есть ли у тебя доступ к последнему коммиту в проекте?" он ответил утвердительно и дал краткую справку по коммиту.

После этого я попросил сделать ревью. Результат оказался лучше и шире.
Плюс было очень удобно задавать уточняющие вопросы по вносимым изменениям и все перепроверять за агентом прямо в vscode .

В результате я на ревью этой фичи потратил около 30 минут и сделал 3 комментария к MR.

Без агента на это ушло бы не меньше 1 часа. И качество было бы хуже.

———
А еще после такой совместной работы с агентом:
- пропал страх перед такими MR-ми,
- быстро разобрался в предлагаемых изменениях,
- быстро восстановил контекст по работе приложения.

Ps
- ах, да. Еще научился проводить ревью "по-новому".

———
А как вы проводите ревью?
"По-новому" - 1️⃣ или "по старинке" - 2️⃣

[asyncpg vs psycopg3]

Наткнулся на asyncpg.
Зашел в репу.

Заявляют что это самый быстрый клиент для PostgreSQL:

5x faster than psycopg3.

Пруфы в репе у них на github.

Решил пощупать.
В контейнере запустил PosgreSQL 16.

Выполнил ряд операций с использованием asyncpg, а потом с psycopg3.

Победа только по показателю "Массовая вставка (1000 записей)":

asyncpg: 0.0428 с
psycopg3: 0.9552 с

С другими показателями можно ознакомиться на картинке.

Интересный опыт)

[pgvector, fastembed и косинусное расстояние]

1. Поднял PostgreSQL 17 с расширением pgvector в контейнере.

2. Написал простой код, который рассчитывает эмбендинги для 2-х предложений и записывает результаты в БД.
При этом использовал библиотеку fastembed.

3. Рассчитал косинусное расстояние между запросом пользователя и эмбендингами в БД.
Таким образом нашел наиболее релевантный кусок текста, который следует отдать LLM в качестве контекста.

4. Повторил упражнение заменив используемую модель в fastembed на мультиязычную.

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

Вот рассчитанные значения для нерелевантного предложения:
1) модель по-дефолту: distance=0.2626001991391288
2) мультиязычная модель: distance=0.578577122859318

Для информации
Чем больше косинусное расстояние, тем меньше подходит данный кусок текста.

P.s.
Не успел попробовать кастомную модель, используя TextEmbedding.add_custom_model(). Хз, работает или нет. Хочу попробовать взять модель из рейтинга https://huggingface.co/spaces/mteb/leaderboard

Какая сейчас лучшая модель для русского языка? Желательно небольшая.

[Qdrant - векторная база данных]

Сегодня познакомился с этой БД.

Посмотрел архитектуру, ключевые сущности, запустил инстанс в контейнере, выполнил несколько базовых операций через UI.

Ключевые сущности в БД:
- точка
- коллекция

Точка состоит из:
- id
- vector
- payload

Коллекция - это место хранения точек. Коллекция определяется набором атрибутов:
- размерность векторов
- метрика близости: косинусное расстояние, евклидово расстояние, скалярное произведение
- настройки HNSW, фильтрации, индексирования

Данные можно хранить как в оперативной памяти (in-memory), так и на диске (memmap).

[Анти-спам. Qdrant, fastembed, FastAPI]

Дано:
- датасет с размеченными сообщениями с флагом спам или нет

Сделал:
- рассчитал вектора для каждого сообщения c помощью fastembed
- загрузил все в Qdrant
- cоздал API на FastAPI для предсказания нового сообщения на предмет спама

В итоге система анализирует текст сообщения (рассчитывает вектор) и находит похожие сообщения в базе (ближайшие точки), чтобы определить - спам это или нет. Если среди ближайших точек больше 50% спама, то помечаем сообщение пользователя как спам.

Отправлял явный спам. Из бд получал ближайшие точки и 9 из 10 были спамом.
Отправлял сообщения не похожие на спам. Ближайшие точки все были не спам. Соответственно сообщение помечается как не спам.

Прикольно)

P.s. в Qdrant видно как сообщения со спамом (синий цвет) находятся рядом друг с другом.

Датасет с сообщениями брал здесь: https://www.kaggle.com/datasets/team-ai/spam-text-message-classification

[Что на счет безопасности ИИ-приложений?]

Узнал что атаки делятся на 2 вида:

Прямые:
1) Манипуляция через "поддавки"
2) Подмена инструкций (Prompt Injection)
3) Утечка промптов
4) Джейлбрейк (DAN техника)

Непрямые:
5) Отравление данных (например, инструкции для LLM в резюме)
6) Взлом через инструменты (тулы)

С помощью всего этого можно сломать приложение и заставить модель выполнять нецелевые инструкции.

Возможно, есть что-то еще.

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

Есть также какие-то библиотеки для защиты. Но их еще не смотрел.

P.s.
Буду благодарен, если есть рекомендации по библиотеке, которую стоит рассмотреть в первую очередь.

Спасибо.