Разработка ИИ-агента для анализа конфликтов и аудита веб-ресурсов

Архитектура ИИ-агентов: выбор стека технологий и планирование логики работы

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

Сегодня мы разберем архитектуру будущего агента, выберем инструменты (стек технологий) и спроектируем логику его «мышления».

Что такое ИИ-агент и чем он отличается от чат-бота?

Многие путают понятия «чат-бот» (как ChatGPT в веб-интерфейсе) и «ИИ-агент». Разница колоссальная.

* Чат-бот — это пассивная система. Вы пишете запрос — она отвечает. Она замкнута в своем окне диалога и не имеет доступа к внешнему миру (если не подключены плагины). * ИИ-агент — это автономная система, которая имеет цель, инструменты и право принимать решения. Агент может сам зайти на сайт, прочитать новости, проанализировать их, сохранить результат в базу данных и отправить вам отчет в Telegram.

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

Анатомия агента

Любой ИИ-агент состоит из четырех ключевых компонентов:

Мозг (LLM — Large Language Model): Это ядро системы (например, GPT-4, Claude 3.5 или Llama 3). Мозг отвечает за рассуждения, планирование и обработку текста.

Инструменты (Tools): Руки агента. Это функции, которые позволяют ему взаимодействовать с миром: get_website_content (скачать сайт), save_to_file (сохранить файл), google_search (поиск).

Память (Memory): Способность запоминать контекст разговора или сохранять данные надолго (векторные базы данных).

Планирование (Planning): Способность разбить большую задачу («проведи аудит сайта») на подзадачи («скачать HTML», «извлечь текст», «найти ключевые слова», «сформировать отчет»).

!Схема основных компонентов архитектуры ИИ-агента: Мозг, Инструменты, Память и Планирование.

Выбор стека технологий

Для реализации нашей задачи нам нужен надежный и современный набор инструментов. Мы будем использовать язык программирования Python, так как это безусловный стандарт в мире ИИ.

1. Языковая модель (LLM)

Нам нужна модель, которая хорошо понимает контекст и умеет следовать инструкциям в формате JSON (это важно для автоматизации).

* OpenAI (GPT-4o / GPT-4o-mini): Золотой стандарт. Отлично следует инструкциям, недорого стоит (особенно mini-версия). Идеально для старта. * Anthropic (Claude 3.5 Sonnet): Часто превосходит GPT в написании кода и анализе сложных текстов, но API может быть дороже. * Локальные модели (через Ollama): Если данные конфиденциальны, можно запустить Llama 3 локально. Но для этого нужно мощное железо.

Наш выбор: Мы начнем с OpenAI API, так как это проще всего в настройке, но архитектуру построим так, чтобы модель можно было заменить одной строчкой кода.

2. Фреймворк для оркестрации

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

* LangChain: Самый популярный фреймворк. Огромное сообщество, много готовых интеграций. * LlamaIndex: Лучше подходит, если главная задача — поиск по огромным базам данных (RAG), но чуть сложнее для создания агентов общего назначения. * LangGraph: Новая библиотека от создателей LangChain, специально для создания сложных агентов с циклами и ветвлениями.

Наш выбор: LangChain (для базовых цепей) и элементы LangGraph (для управления состоянием агента).

3. Инструменты для сбора данных (Scraping)

Чтобы анализировать сайт, его нужно сначала «прочитать».

* BeautifulSoup: Простая библиотека для парсинга HTML. Работает быстро, но не умеет открывать сайты со сложным JavaScript (SPA). * Selenium / Playwright: Эмулируют настоящий браузер. Могут нажать кнопку, прокрутить страницу. Медленнее, но надежнее.

Наш выбор: Мы создадим гибридный инструмент. Сначала пробуем легкий метод, если не выходит — подключаем «тяжелую артиллерию».

Планирование логики работы: Pipeline

Прежде чем писать код, нужно описать алгоритм. В программировании это часто называют «пайплайн» (pipeline — трубопровод). Данные заходят с одной стороны, проходят обработку и выходят с другой.

Рассмотрим формулу расчета стоимости обработки одной страницы, чтобы понимать экономику нашего агента. Это важно при выборе модели.

Где — итоговая стоимость запроса, — количество токенов во входном тексте (контент сайта + наш промпт), — цена за 1000 входных токенов, — количество токенов в ответе модели (наш отчет), а — цена за 1000 выходных токенов.

Понимая эту формулу, мы решаем: мы не будем скармливать модели весь HTML-код (это дорого и зашумляет контекст). Мы будем сначала очищать текст.

Этапы работы нашего агента:

Входные данные: Пользователь отправляет URL (например, ссылка на новостную статью).

Скрапинг (Scraping):

* Агент загружает страницу. * Удаляет рекламу, меню, футеры (чистит DOM-дерево). * Извлекает чистый текст и мета-данные (Title, Description).

Анализ конфликтов (NLP Analysis):

Текст отправляется в LLM с системным промптом: «Ты эксперт по конфликтологии. Найди в тексте признаки языка вражды, манипуляции фактами и эмоционального давления»*.

Технический аудит:

* Параллельно агент проверяет: есть ли заголовок H1? Заполнены ли Alt-теги у картинок? Быстро ли ответил сервер?

Генерация отчета:

* Агент собирает все данные в структурированный JSON или Markdown-файл.

!Блок-схема процесса обработки веб-ресурса: от получения ссылки до финального отчета.

Проектирование промптов (Prompt Engineering)

Качество работы агента на 80% зависит от того, как мы составим инструкцию (промпт). Для нашего курса мы будем использовать технику Chain-of-Thought (Цепочка рассуждений).

Вместо того чтобы сказать: «Проверь текст на конфликты», мы скажем:

> Проанализируй текст шаг за шагом: > 1. Выдели основные тезисы статьи. > 2. Определи тональность каждого тезиса (нейтральная, позитивная, агрессивная). > 3. Если есть агрессия, укажи цитату и объясни, почему это считается конфликтом. > 4. Сформируй итоговый вывод.

Такой подход заставляет модель «думать» последовательно, что значительно снижает количество галлюцинаций (выдуманных фактов).

Заключение

Сегодня мы заложили фундамент. Мы определили, что наш агент — это автономная программа на Python, использующая LangChain и OpenAI API. Мы разбили его работу на этапы: скрапинг, очистка, анализ и отчетность.

В следующей статье мы перейдем к практике: настроим окружение, получим API-ключи и напишем наш первый скрипт, который умеет «видеть» веб-страницы.

Полезные ссылки

* Документация LangChain * Официальный сайт Python * Платформа OpenAI API

Сбор данных: методы парсинга веб-страниц и препроцессинг контента для LLM

Добро пожаловать во вторую часть курса «Разработка ИИ-агента для анализа конфликтов и аудита веб-ресурсов». В прошлой статье мы спроектировали архитектуру нашего агента и выбрали стек технологий. Мы решили, что «мозгом» будет LLM (например, GPT-4o), а «руками» — Python-скрипты.

Но даже самый умный мозг бесполезен без информации. Чтобы наш агент мог найти конфликты в статье или проверить техническое состояние сайта, он должен сначала этот сайт «прочитать». Сегодня мы займемся именно этим: научим агента забирать данные из интернета (парсинг) и готовить их к употреблению (препроцессинг).

Этика и технические ограничения

Прежде чем писать код, нужно усвоить главное правило веб-скрейпинга: не навреди. Сайты — это чья-то собственность и серверные ресурсы.

Robots.txt: У каждого уважающего себя сайта есть файл robots.txt (например, google.com/robots.txt), где прописано, куда роботам заходить нельзя.

User-Agent: Если вы стучитесь на сайт без представления, вас могут заблокировать. Мы будем маскироваться под обычный браузер, передавая заголовок User-Agent.

Rate Limiting (Ограничение частоты): Не отправляйте 100 запросов в секунду. Это похоже на DDoS-атаку. Делайте паузы между запросами.

Методы парсинга: Статика vs Динамика

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

1. Статические страницы (Server-Side Rendering)

Сервер отдает готовый HTML-код. Вы открываете код страницы (Ctrl+U) и видите там текст статьи. Это идеальный вариант для нас.

* Инструменты: Библиотеки requests (для запроса) и BeautifulSoup (для разбора HTML). * Плюсы: Очень быстро, минимальная нагрузка на процессор. * Минусы: Не работает, если контент подгружается через JavaScript.

2. Динамические страницы (Client-Side Rendering / SPA)

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

* Инструменты: Selenium, Playwright. * Плюсы: Видит то же, что и реальный пользователь (включая кнопки, всплывающие окна). * Минусы: Медленно (нужно запускать целый браузер), требует много памяти.

Наш выбор: Мы начнем с статического парсинга. Он покрывает 80% новостных ресурсов и блогов, которые нам нужно анализировать на предмет конфликтов. Если метод не сработает, агент переключится на динамический (но это тема для продвинутой оптимизации).

Практика: Получаем «сырой» HTML

Для начала установим необходимые библиотеки:

Напишем функцию, которая скачивает страницу. Обратите внимание на использование заголовков (headers) — это наш «паспорт» для сервера.

Препроцессинг: От HTML к чистому смыслу

Получить HTML — это только полдела. Если мы отправим в LLM весь код страницы (с меню, рекламой, скриптами и стилями), мы столкнемся с двумя проблемами:

Шум: Модель может запутаться в техническом коде и начать анализировать классы CSS вместо смысла статьи.

Стоимость: LLM берут плату за токены (части слов). HTML-код увеличивает объем текста в 3-5 раз.

Рассмотрим формулу эффективности очистки данных:

Где — эффективность очистки в процентах, — количество токенов в сыром HTML, а — количество токенов в очищенном тексте. Наша цель — максимизировать , сохраняя при этом смысл.

!Визуализация процесса фильтрации HTML-кода: удаление технического мусора и извлечение полезного контента.

Алгоритм очистки (Cleaning Pipeline)

Мы будем использовать BeautifulSoup для навигации по дереву тегов (DOM). Наша задача — вырезать лишнее и оставить суть.

#### Шаг 1: Удаление мусора

Сразу удаляем теги, которые точно не содержат полезного контента для анализа конфликтов: <script>, <style>, <nav> (меню), <footer> (подвал), <aside> (боковые панели с рекламой).

#### Шаг 2: Извлечение метаданных

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

#### Шаг 3: Извлечение основного текста

Самая сложная часть. Просто взять soup.get_text() плохая идея, так как текст сольется в кашу. Нам нужно сохранить структуру абзацев.

Мы будем искать специфичные теги: <p> (параграфы), <h1>-<h6> (заголовки), <li> (списки).

Подготовка к отправке в LLM (Chunking)

Даже очищенный текст может быть слишком длинным для одного запроса к модели (хотя современные окна контекста велики, лучше экономить). Кроме того, если статья огромная, качество анализа падает («эффект потери внимания в середине»).

Для этого используется чанкинг (разбиение на части). В библиотеке LangChain, которую мы выбрали в прошлой статье, есть отличный инструмент для этого.

Зачем нужно перекрытие (Overlap)?

Представьте, что важная фраза «Конфликт начался из-за...» попала на конец одного чанка, а продолжение «...недопонимания сторон» — в начало другого. Без перекрытия модель не свяжет эти две части. Параметр chunk_overlap дублирует конец предыдущего куска в начале следующего.

Итоговый пайплайн сбора данных

Теперь соберем все функции в единый класс WebScraper, который мы будем использовать в нашем агенте.

Заключение

Сегодня мы создали «глаза» нашего агента. Мы научились:

Скачивать веб-страницы, притворяясь браузером.

Очищать HTML от мусора, экономя токены и деньги.

Извлекать метаданные для технического аудита.

Готовить текст для LLM с помощью чанкинга.

В следующей статье мы перейдем к самому интересному: подключим «мозг». Мы настроим интеграцию с OpenAI через LangChain и напишем промпты, которые заставят модель искать в нашем очищенном тексте признаки агрессии и манипуляций.

Полезные ссылки

* Документация Beautiful Soup * Библиотека Requests * Text Splitters в LangChain

Семантический анализ: промпт-инжиниринг для поиска смысловых конфликтов и противоречий

Приветствую вас на третьей лекции курса «Разработка ИИ-агента для анализа конфликтов и аудита веб-ресурсов».

В прошлых статьях мы построили «тело» нашего агента: научили его скачивать веб-страницы, очищать HTML от мусора и разбивать текст на удобные кусочки. Теперь у нас есть данные. Но данные сами по себе — это просто набор символов. Чтобы найти в них конфликты, манипуляции или логические дыры, нашему агенту нужен «интеллект».

Сегодня мы займемся самым творческим и сложным этапом разработки — промпт-инжинирингом (Prompt Engineering). Мы научим языковую модель (LLM) не просто читать текст, а понимать его скрытый смысл, то есть проводить семантический анализ.

Синтаксис против Семантики: в чем разница?

Прежде чем писать инструкции для ИИ, важно понять, что мы ищем.

* Синтаксический анализ — это работа с формой. Например, поиск по ключевому слову «война» или «обман». Если слова нет в тексте, обычный поиск ничего не найдет. * Семантический анализ — это работа со смыслом. Фраза «специальная операция по принуждению к миру» синтаксически не содержит слова «война», но семантически может быть ей эквивалентна в определенном контексте.

Наша задача — найти смысловые конфликты. Они бывают двух типов:

Внутренние противоречия: Автор в первом абзаце утверждает одно, а в последнем — прямо противоположное.

Внешние конфликты (манипуляции): Использование агрессивной риторики, логических ошибок (fallacies) или подмены понятий.

!Различие между синтаксическим и семантическим анализом текста.

Как «думает» модель: Механизм внимания

Чтобы эффективно управлять LLM, нужно понимать, как она обрабатывает информацию. В основе современных трансформеров (GPT, Claude, Llama) лежит механизм Self-Attention (самовнимания).

Когда модель читает предложение, она вычисляет взаимосвязь каждого слова с каждым другим словом. Это позволяет ей понимать контекст. Математически это описывается формулой внимания:

Где: * (Query) — запрос (то, что мы ищем или текущее слово). * (Key) — ключ (метка, с которой мы сравниваем запрос). * (Value) — значение (смысловое содержание). * — размерность ключей (масштабирующий коэффициент). * — функция, превращающая числа в вероятности (сумма равна 1).

Простыми словами: модель берет текущее слово (), «пробегается» по всем остальным словам (), определяет, насколько они важны для текущего контекста (результат умножения и softmax), и собирает итоговый смысл () с учетом этой важности.

Зачем нам это знать? Потому что «внимание» модели ограничено. Если мы подадим в промпт слишком много мусора, веса внимания «размажутся», и модель упустит тонкие противоречия. Именно поэтому мы так тщательно чистили HTML в прошлом уроке.

Стратегии промпт-инжиниринга для аудита

Промпт — это не просто вопрос к модели. Это программа, написанная на естественном языке. Для анализа конфликтов мы будем использовать комбинацию трех техник.

1. Role Prompting (Задание роли)

Мы должны четко определить, кто наш агент. Это сужает пространство возможных ответов и настраивает стиль.

> Плохо: «Найди ошибки в тексте». > Хорошо: «Ты — опытный лингвист-конфликтолог и фактчекер. Твоя задача — проводить беспристрастный аудит текста на наличие манипуляций и логических противоречий».

2. Chain-of-Thought (Цепочка рассуждений)

Это самая мощная техника для сложных задач. Мы просим модель «думать вслух» или по шагам. Исследования показывают, что это значительно повышает точность логических выводов.

Вместо того чтобы требовать сразу ответ «Есть конфликт или нет», мы просим:

Выдели ключевые тезисы.

Определи тональность каждого тезиса.

Сравни тезисы между собой.

Сделай вывод.

3. Few-Shot Prompting (Обучение на примерах)

Дайте модели пример того, что вы считаете конфликтом. Это работает лучше, чем длинные теоретические описания.

Практика: Создаем системный промпт

Давайте напишем шаблон промпта на Python, используя библиотеку LangChain, которую мы выбрали ранее. Мы будем использовать структуру: Роль + Контекст + Инструкция + Формат вывода.

Почему JSON?

Мы требуем JSON, потому что наш агент — это программа. Ей нужно будет сохранить результаты в базу данных или отправить их на фронтенд. Парсить (разбирать) свободный текст сложно и ненадежно. JSON гарантирует структуру.

Борьба с галлюцинациями

Главный враг ИИ-агента — галлюцинации. Модель может придумать конфликт там, где его нет, просто чтобы выполнить вашу просьбу «найти конфликт».

Как с этим бороться?

Требование цитат: В промпте выше мы добавили требование: «ОБЯЗАТЕЛЬНО приведи точную цитату». Это заставляет модель «заземляться» (grounding) на исходный текст. Если она не может найти цитату, она с меньшей вероятностью выдумает факт.

Параметр Temperature: При вызове модели (через API OpenAI или Anthropic) установите temperature=0. Это делает модель детерминированной и менее «творческой».

Где: * — вероятность выбора следующего токена. * — логит (сырая оценка) токена. * — температура.

Если стремится к нулю, распределение вероятностей становится «острым»: самый вероятный токен получает почти 100% шансов, а остальные — 0%. Это убивает фантазию, но повышает надежность для задач аудита.

Типология конфликтов для промпта

Чтобы агент работал качественно, дайте ему «словарь» конфликтов. Вот список, который стоит включить в системный промпт:

* Ad Hominem (Переход на личности): Атака на характер оппонента вместо критики его аргументов. * Whataboutism (Как насчет...): Отвлечение внимания от проблемы указанием на недостатки других. * Ложная дихотомия: Представление ситуации так, будто есть только два выхода, хотя их больше. * Эмоциональная накачка: Использование слов-триггеров («шок», «катастрофа», «предательство») без фактического обоснования.

!Иерархия типов конфликтов, которые должен искать ИИ-агент.

Итоговая сборка цепочки (Chain)

Теперь, когда у нас есть промпт, мы можем соединить его с моделью. В LangChain это делается просто:

Этот код создает конвейер: очищенный текст попадает в шаблон, превращается в инструкцию для GPT-4, модель генерирует JSON-строку, а парсер превращает её в объект Python, с которым мы можем работать дальше.

Заключение

Сегодня мы превратили нашего агента из простого «читателя» в «аналитика». Мы разобрали:

Разницу между поиском слов и поиском смысла.

Математику внимания, которая ограничивает объем контекста.

Техники промпт-инжиниринга: Роли, Цепочки рассуждений (CoT) и требование цитат.

Настройку температуры для снижения галлюцинаций.

Теперь наш агент умеет находить конфликты в одной статье. Но что, если нам нужно следить за сотней сайтов ежедневно и отправлять уведомления в Telegram? В следующей статье мы займемся автоматизацией и деплоем: создадим расписание проверок и подключим базу данных для хранения истории конфликтов.

Полезные ссылки

* Руководство по Prompt Engineering от OpenAI * Документация LangChain по промптам * Исследование Chain-of-Thought Prompting

Автоматизация аудита: критерии оценки UX, SEO и технического состояния сайта

Добро пожаловать на четвертую лекцию курса «Разработка ИИ-агента для анализа конфликтов и аудита веб-ресурсов».

В предыдущих статьях мы проделали огромную работу: создали архитектуру агента, научили его парсить данные и подключили «мозг» (LLM) для поиска смысловых конфликтов. Наш агент уже умеет читать и понимать текст. Но хороший аудитор должен видеть не только смысл написанного, но и качество площадки, на которой этот текст размещен.

Представьте ситуацию: агент нашел статью с идеальной, бесконфликтной риторикой. Но сайт грузится 10 секунд, картинки не открываются, а заголовок страницы отсутствует. Можно ли доверять такому ресурсу? Вряд ли. Техническая небрежность часто коррелирует с низким качеством контента.

Сегодня мы научим нашего агента проводить технический аудит без использования LLM. Это сэкономит токены и даст нам объективные метрики качества сайта.

Зачем разделять семантический и технический аудит?

Использовать GPT-4 для проверки наличия тега <title> — это как забивать гвозди микроскопом. Это дорого и медленно.

Мы разделим логику агента на два потока:

Семантический поток (LLM): Анализ текста, поиск конфликтов, тональность (то, что мы делали в прошлой статье).

Технический поток (Python Code): Проверка скорости, кодов ответа, мета-тегов, структуры HTML.

!Блок-схема разделения потоков обработки данных в ИИ-агенте

1. Техническое состояние (Technical Health)

Первый рубеж обороны — доступность сервера. Если сайт не работает, анализировать там нечего.

Коды ответа сервера

Когда мы делаем запрос через библиотеку requests, сервер возвращает статус-код. Наш агент должен уметь их интерпретировать:

* 200 OK: Все отлично, работаем дальше. * 404 Not Found: Страница удалена. Это сигнал для базы данных — пометить ресурс как неактивный. * 500+ Server Error: Проблемы на стороне сайта. Возможно, он не справляется с нагрузкой. * 301/302 Redirect: Перенаправление. Агент должен уметь следовать за редиректом, но не бесконечно (защита от циклов).

Скорость ответа (Performance)

Скорость загрузки — критический фактор UX. Мы будем замерять TTFB (Time to First Byte) — время от отправки запроса до получения первого байта ответа.

Для оценки качества мы можем использовать простую линейную формулу расчета балла:

Где — итоговый балл за скорость (максимум 100), а — время ответа сервера в секундах.

Пример: Если сайт ответил за 0.5 секунды, балл будет . Если за 5 секунд — балл упадет до 0 (мы не допускаем отрицательных значений в коде).

2. SEO-критерии (Search Engine Optimization)

SEO-аудит важен не только для продвижения, но и для оценки авторитетности ресурса. Качественные СМИ и блоги следят за разметкой.

Мы будем проверять наличие и длину ключевых мета-тегов, используя BeautifulSoup.

Title и Description

* Title: Заголовок вкладки браузера. Должен быть уникальным и информативным. Оптимальная длина: 30–60 символов. * Description: Краткое описание страницы для поисковика. Оптимальная длина: 70–160 символов.

Иерархия заголовков (H1-H6)

На странице должен быть ровно один заголовок первого уровня <h1>. Если их ноль или больше одного — это грубая ошибка структуры.

3. UX и Доступность (User Experience & Accessibility)

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

Атрибуты Alt у изображений

Атрибут alt описывает, что изображено на картинке. Это критически важно для незрячих пользователей (которые используют скринридеры) и для поисковиков.

Мы рассчитаем коэффициент доступности изображений по формуле:

Где — процент изображений с описанием, — количество тегов <img>, у которых есть атрибут alt, а — общее количество изображений на странице.

Практическая реализация: Класс Auditor

Давайте напишем код на Python, который реализует все вышеописанные проверки. Мы создадим класс SiteAuditor, который принимает HTML и объект ответа requests.

Этот код выполняет базовые проверки быстро и эффективно, не затрачивая ресурсы дорогостоящей LLM.

Система оценки (Scoring System)

Чтобы агент мог принять решение («сайт хороший» или «сайт плохой»), нам нужно свести все метрики к единому числу. Для этого мы используем метод взвешенного среднего.

Не все параметры одинаково важны. Например, отсутствие <h1> (ошибка структуры) менее критично, чем ответ сервера 500 (сайт не работает). Мы назначим веса каждому параметру.

Формула расчета итогового рейтинга:

Где: * — итоговый рейтинг страницы. * — оценка -го параметра (нормализованная от 0 до 1). * — вес (важность) -го параметра. * — количество проверяемых параметров.

Таблица весов для нашего агента

| Параметр | Вес () | Обоснование | | :--- | :--- | :--- | | Статус код 200 | 10 | Критически важно. Если не 200, аудит провален. | | Скорость < 1 сек | 5 | Важно для UX. | | Наличие H1 | 3 | Важно для структуры. | | Наличие Description | 2 | Важно для SEO. | | Alt у картинок | 2 | Важно для доступности. |

!Визуализация приоритетности параметров при расчете рейтинга

Интеграция с общим пайплайном

Теперь у нас есть два независимых отчета.

Отчет LLM: «В тексте обнаружена агрессивная риторика (Score: 8/10)».

Технический отчет: «Сайт технически оптимизирован, загрузка быстрая (Score: 9/10)».

Как это интерпретировать?

* Высокое качество / Низкий конфликт: Надежный источник. * Высокое качество / Высокий конфликт: Профессиональная пропаганда или качественная манипуляция. Самый опасный тип ресурсов. * Низкое качество / Высокий конфликт: «Мусорный» сайт, созданный на коленке для вбросов.

Такая матрица 2x2 позволяет нашему агенту делать гораздо более глубокие выводы, чем просто анализ текста.

Заключение

Сегодня мы добавили нашему агенту «зрение» инженера. Он научился оценивать техническое здоровье сайта, его SEO-оптимизацию и удобство для пользователей. Мы реализовали это с помощью чистого Python, сэкономив бюджет проекта.

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

Полезные ссылки

* Документация библиотеки Requests * Руководство Google по Web Vitals * Спецификация HTML5 от W3C

Сборка финального пайплайна: интеграция инструментов, тестирование и генерация отчетов

Добро пожаловать на финальную лекцию курса «Разработка ИИ-агента для анализа конфликтов и аудита веб-ресурсов». Мы прошли долгий путь: от выбора архитектуры и стека технологий до написания сложных модулей парсинга и промпт-инжиниринга.

Сейчас у нас есть набор разрозненных инструментов:

* Scraper: Умеет скачивать и чистить HTML. * Auditor: Проверяет техническое состояние (SEO, скорость). * Analyzer: Ищет смысловые конфликты с помощью LLM.

Но это еще не агент. Это просто набор скриптов. Агент становится агентом, когда он обретает автономность и целостность. Сегодня мы займемся оркестрацией: объединим все модули в единый пайплайн, подключим базу данных для памяти, настроим автоматический запуск и научим систему генерировать понятные отчеты.

Архитектура финального решения

Прежде чем писать код, взглянем на схему потоков данных. Наш оркестратор (Orchestrator) будет выступать в роли дирижера.

!Диаграмма потоков данных, показывающая центральную роль Оркестратора в управлении модулями скрапинга, аудита, анализа и сохранения результатов.

1. Проектирование Базы Данных

Агенту нужна долговременная память. Если мы будем просто выводить результаты в консоль, мы не сможем отслеживать динамику (например, стал ли сайт более агрессивным за последнюю неделю).

Для нашего проекта идеально подойдет SQLite. Это встроенная в Python легковесная база данных, которая хранит всё в одном файле. Для продакшн-решений лучше использовать PostgreSQL, но логика останется той же.

Нам понадобятся две таблицы:

Sites: Список ресурсов для мониторинга.

Audits: История проверок (связана с таблицей Sites).

2. Создание Оркестратора

Оркестратор — это класс, который импортирует наши предыдущие наработки и управляет ими. Он решает, что делать, если сайт недоступен, и как объединять оценки.

Расчет интегрального рейтинга доверия

У нас есть две оценки: техническая (насколько сайт качественный) и семантическая (насколько контент безопасный). Нам нужен единый индекс доверия (Trust Score).

Используем формулу взвешенного среднего:

Где: * — итоговый индекс доверия (от 0 до 100). * — весовой коэффициент важности технической части (например, 0.3). * — техническая оценка сайта (0-100). * — оценка конфликтности/токсичности контента (0-100), которую мы инвертируем (), так как высокая конфликтность снижает доверие.

Реализуем класс AgentOrchestrator:

3. Генерация отчетов

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

Мы будем генерировать отчет в формате Markdown. Это позволит легко отправлять его в Telegram, Slack или сохранять как файл.

4. Автоматизация и планирование (Scheduling)

Агент должен работать автономно. Мы не хотим запускать скрипт вручную каждый раз. Для простых задач в Python отлично подходит библиотека schedule.

Напишем скрипт запуска, который проверяет список сайтов каждые 6 часов:

5. Тестирование: Unit vs Integration

Как убедиться, что агент не сломается, если сайт изменит верстку или API OpenAI станет недоступным? Нам нужны тесты.

Мокирование (Mocking)

Самая большая ошибка новичков — тестировать на реальных запросах к API. Это:

Дорого: Вы платите за каждый тестовый прогон.

Медленно: Сетевые запросы занимают время.

Нестабильно: Если интернет пропал, тест упал, хотя код правильный.

В тестах мы используем «моки» (заглушки). Вместо реального вызова LLM мы подсовываем программе заранее заготовленный JSON-ответ.

Пример теста с использованием unittest.mock:

6. Деплой и Docker

Чтобы агент работал 24/7, его нельзя запускать на личном ноутбуке. Его место — на сервере (VPS). Чтобы избежать проблем «на моем компьютере работает, а на сервере нет», мы упакуем агента в Docker.

Создадим простой Dockerfile:

Теперь нашего агента можно развернуть одной командой на любом сервере, будь то AWS, DigitalOcean или домашний Raspberry Pi.

Заключение курса

Поздравляю! Вы прошли полный путь разработки сложного ИИ-продукта.

Чему мы научились:

Архитектура: Понимать разницу между чат-ботом и агентом.

Сбор данных: Парсить HTML и чистить его от шума.

Анализ: Использовать LLM и Chain-of-Thought для поиска скрытых смыслов.

Аудит: Оценивать техническое качество кода без нейросетей.

Интеграция: Собирать всё это в работающую систему с базой данных и отчетами.

Что дальше? Мир ИИ-агентов огромен. Вы можете улучшить этот проект: * Добавить RAG (Retrieval Augmented Generation), чтобы агент сравнивал новости с историческими фактами из своей базы. * Подключить Browser Use, чтобы агент мог делать скриншоты доказательств. * Настроить уведомления в мессенджеры.

Ваш агент готов к работе. Удачи в поисках истины и чистого веба!