Опубликовано: 03.10.2026 | Источник: SecurityLab (RSS)

```html

База знаний для ИИ-агентов в ВКР: от прототипа до метрик качества

Mozilla анонсировала платформу, которую уже окрестили «Stack Overflow для роботов» — коллективную базу знаний, где ИИ-агенты будут публиковать описания своих ошибок, удачных решений и контекста, в котором они работали. Идея простая и в то же время радикальная: вместо того чтобы каждая модель училась заново, агенты будут обмениваться опытом через общее хранилище. Для выпускников ИТ-направлений это не абстрактная новость, а готовый полигон для диплома. Тема мультиагентных систем, методов накопления знаний и оценки их качества только формируется — значит, здесь ещё нет «заезженных» шаблонов, а значит, есть шанс защититься на действительно свежем материале. Ниже — как превратить эту новость в рабочую ВКР.

Три темы ВКР, которые вырастают из этой статьи

Тема 1. Проектирование межагентной базы знаний с валидацией записей

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

Цель: разработать архитектуру хранилища записей об ошибках ИИ-агентов с механизмом модерации и оценки достоверности.

• Задача 1: анализ существующих подходов к RAG и векторным хранилищам.
• Задача 2: проектирование схемы записи (контекст, действие, результат, метка доверия).
• Задача 3: реализация протокола обмена между агентами (MCP или gRPC).
• Задача 4: оценка качества базы по метрикам полноты и точности.

Структура: Глава 1 — обзор RAG, векторных БД, практик Mozilla; Глава 2 — архитектура сервиса, UML-диаграммы, схема БД; Глава 3 — нагрузочное тестирование, расчёт эффекта от переиспользования записей.

Тема 2. Оценка влияния коллективной памяти агентов на число ошибок решения задач

Актуальность. Гипотеза Mozilla проверяема: если агент обращается к базе чужих ошибок, растёт ли доля успешных решений? Это экспериментальная ВКР с реальными метриками, а не пересказ документации.

Цель: количественно оценить эффект от подключения межагентной базы знаний к пайплайну двух и более агентов.

• Задача 1: сформировать контрольный набор задач и baseline без базы знаний.
• Задача 2: собрать телеметрию через OpenTelemetry.
• Задача 3: провести A/B-эксперимент и посчитать прирост success rate.
• Задача 4: оформить выводы с оценкой статистической значимости.

Структура: Глава 1 — метрики качества LLM-систем по ISO/IEC 25010; Глава 2 — схема эксперимента, развёртывание в Kubernetes; Глава 3 — анализ результатов, доверительные интервалы, экономический эффект.

Тема 3. Безопасность и отравление общей базы знаний ИИ-агентов

Актуальность. Как только агенты начинают доверять записям друг друга, возникает вектор атаки: злоумышленник публикует ложное «решение», и оно расходится по всей сети. Тема на стыке ИБ и ИИ — редкая и выигрышная на защите.

Цель: выявить классы угроз для коллективной памяти агентов и предложить механизм защиты.

• Задача 1: таксономия атак (prompt injection, data poisoning, sybil-агенты).
• Задача 2: модель угроз по методологии STRIDE для архитектуры базы.
• Задача 3: прототип фильтра записей на основе перекрёстной проверки.
• Задача 4: оценка ложноположительных срабатываний фильтра.

Структура: Глава 1 — обзор угроз ИИ-систем и смежных стандартов; Глава 2 — проектирование защитного слоя; Глава 3 — пентест прототипа и рекомендации по эксплуатации.

Аналитическая глава: чем обосновывать выбор стека

Здесь студенты чаще всего скатываются в пересказ документации. Работает другое: сравнение по критериям, привязанным к задачам ВКР. Ниже — шаблон таблицы, который легко защитить перед комиссией, потому что критерии не «взяты из воздуха», а вытекают из гипотезы Mozilla.

Рядом с таблицей уместно привести фрагмент схемы записи — он показывает, что вы продумали модель данных, а не просто «взяли Postgres».

{
  "record_id": "uuid",
  "agent_id": "agent-42",
  "task_context": "refactor legacy REST endpoint",
  "action_taken": "batch update without transaction",
  "error_signature": "partial_write_on_timeout",
  "resolution": "wrap in transaction + retry with jitter",
  "trust_score": 0.87,
  "verified_by": ["agent-7", "agent-13"]
}

Проектная часть: как показать интеграцию агентов, а не только диаграммы

Комиссия любит, когда в работе видна реальная интеграция. Если вы возьмёте в прототип протокол Model Context Protocol (MCP) или хотя бы опишете его как альтернативу самописному gRPC-интерфейсу, — это сразу поднимет уровень. Обоснование строится вокруг вопроса: «Кто ещё будет пользоваться базой, кроме моего агента?». MCP отвечает на это стандартом, самописный API — нет.

Что обязательно нарисовать

• Диаграмму компонентов (C4-уровень Container): агент-клиент, API-шлюз, сервис модерации, векторное хранилище, телеметрия.
• Диаграмму последовательности: публикация записи → проверка → сохранение → выдача при следующем похожем запросе.
• ER-диаграмму схемы БД с полями trust_score и историей верификаций.
• Схему развёртывания в Kubernetes с указанием StatefulSet для хранилища и Deployment для API.

Если UML кажется громоздким, используйте PlantUML — код диаграммы легко вставить в приложение ВКР и это выглядит современно. Главное — не «диаграмма ради диаграммы», а ответ на вопрос: как решение масштабируется при росте числа агентов.

Тестирование и метрики: где большинство ВКР теряют баллы

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

Отдельно зафиксируйте методику: сколько прогонов, как считаете статистическую значимость, какие задачи считаются «успешно решёнными». Это защищает от вопроса «а почему у вас 12% прирост — это вообще не шум?».

Чему вы реально научитесь на такой теме

• Проектировать распределённые сервисы с учётом доверия к данным, а не только отказоустойчивости.
• Работать со стандартными инструментами наблюдаемости: OpenTelemetry, трейсы, метрики, логи.
• Обосновывать выбор стека не «модностью», а критериями задачи и ограничениями развёртывания.
• Оформлять техническую документацию по требованиям ГОСТ 34.602-89 и оценивать качество ПО по ISO/IEC 25010.
• Строить CI/CD-пайплайн (GitHub Actions или GitLab CI) для воспроизводимых экспериментов.

FAQ

Насколько сложно реализовать прототип за один семестр?

Реально, если ограничить объём: два агента, одно векторное хранилище, 30–50 тестовых задач. Основное время уйдёт не на код, а на разметку и оценку результатов. Если кажется, что не успеть, — сокращайте число экспериментов, но не убирайте метрики.

Обязательно ли писать код, или можно обойтись архитектурой?

Зависит от кафедры. На прикладных направлениях работа без прототипа почти всегда снижает оценку. Компромисс: рабочий прототип минимальной функциональности плюс детальное проектирование «целевой» версии на будущее.

Как оформлять UML-диаграммы по требованиям?

Единого ГОСТ на UML нет, но есть сложившаяся практика: подписи на русском, легенда, ссылки на диаграмму из текста. В приложении укажите нотацию (UML 2.5) и инструмент. Если используете PlantUML — приложите исходный текст диаграммы, это оценят.

Где взять тестовые данные для экспериментов?

Открытые бенчмарки (SWE-bench, HumanEval), логи собственных pet-проектов, задачи из учебных лабораторных. Для темы про обмен ошибками особо ценны реальные сбои — можно собрать их из issue-трекеров открытых проектов.

Источник: «Stack Overflow для роботов». Mozilla создает базу знаний, где ИИ-агенты будут учиться на ошибках друг друга (опубликовано 2026-03-26)

```