Garbage In, Garbage Out (GIGO)

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

Когда в распоряжении только лужа, приходится очищать воду, чтобы хоть немного утолить жажду.

И это касается многих других текстовых артефактов, которые подаются на вход ИИ-агентам. Над ними придётся серьёзно поработать.

При этом я никого не хочу критиковать.

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

В начале 2010-х, на заре массового внедрения ML, мы активно обсуждали идею разработки модуля СППВР, основанного на данных эпикризов. Однако быстро выяснилось, что врачи пишут эпикризы скорее для прокуратуры, чем для себя или коллег (defensive medicine). Польза от них минимальна, и для ML они практически непригодны.

С текстами в других сферах ситуация похожая: если кто-то полагает, что можно просто загрузить в RAG массивы текстов, накопленных компанией или отраслью, то это, боюсь, большое заблуждение. Мусор остаётся мусором, и место ему — на свалке.

Ну и да, для этого даже термин придумали — «RAG poisoning».

Сейчас в моду вошло философское течение, осмысляющее роль архитектора.

Выскажусь и я, раз уж всё равно толком ничего не успеваю.

Я отношусь к числу радикалов, считающих, что архитектура — это фикция. И рассматривать роль архитектора стоит через призму роли самой архитектуры.

Разложу по слоям:

- Бизнес-архитектура — это вовсе не архитектура, но при этом крайне важная штука.
- Корпоративная архитектура — это де-факто учет, секретариат при службе завхоза (офиса CTO).
- Архитектура приложений — это чистая инженерия, программная инженерия.
- Архитектура решений - это пересечение множества элементов структуры того, что назвается бизнес-архитектурой и множества элементов структуры приложений

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

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

Выскажу дизрапт-гипотезу.

Прирост качества новых версий моделей снижается — возможно, даже экспоненциально. Это не только ощущение практика, ежедневно работающего с передовыми моделями, включая платные, но и подтверждённая исследованиями тенденция убывающей отдачи от традиционных scaling laws.

Исходя из этого, для себя делаю такую ставку:

1. AGI на текущем уровне развития научно-технического прогресса (НТП) крайне маловероятен в ближайшие годы.
2. Характеристики OSS-моделей будут расти и в течение 2-3 лет практически сравняются с передовыми в большинстве задач.
3. Уже в ближайшем будущем промышленные агентные решения будут строиться на множестве моделей, инкапсулированных в агентов — теперь генеративных. Причём на коммодити железе. Архитектура таких решений радикально изменится: вместо монолита «одна большая модель» появится сеть из множества генеративных агентов, гибко комбинируемых под задачу.
4. Если AGI всё же возникнет в результате прорыва в НТП, влияние на п.3 может быть не столь драматическим — агентная архитектура останется актуальной.

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

И да, в задачах сопряжения "бизнес-архитектуры" и инженерии.

Поздравляю всех с Днём знаний!

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

Отдельная благодарность коллегам и единомышленникам, благодаря которым это стало возможным.

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

Наряду с нейро-символической интеграцией — графы знаний, композитный AI и, что особенно интересно, Causal AI. Ведь мы с коллегами разрабатываем метод концептуализации (онтологического моделирования), позволяющий отражать причинность в структуре графов знаний.

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

Ваши возможности изменений упираются в потолок вашей ветви эскалации. Если у оппонентов потолок выше — делайте выводы.

Пытаться подружиться с более сильными оппонентами — всё равно что овце искать дружбы у волков.

Jupyter в Cursor даёт буст в продуктивности для R&D. Работать иначе уже почти немыслимо.

И, честно говоря, студентов стоит учить ML сразу в таком окружении. Очень хочется, чтобы подобные среды появлялись и у нас — с адекватными условиями для учащихся.

Галлюцинации LLM и закат ИИ

После публикации статьи https://arxiv.org/abs/2509.04664 инфлюенсеры заговорили о «закате ИИ». Аргумент прост: если LLM подвержены галлюцинациям, то им нельзя доверять. Но не всё так однозначно.

1. LLM — это не весь ИИ, а крест ставят на всём ИИ.

2. Генеративные LLM типа GPT обучаются предсказывать следующий токен с помощью авторегрессии. Это принцип пошагового построения текста: модель каждый раз достраивает последовательность слов на основе ранее сгенерированной последовательности. Авторегрессивный подход критически важен для масштабирования: он позволяет эффективно обучать модели на огромных объемах текста, поскольку каждое слово в тексте становится и входными данными, и целевым значением для обучения. Без авторегрессии создание действительно больших языковых моделей было бы технически невозможно. Но именно у больших моделей и проявляются эмерджентные свойства — способности, которые не закладывались напрямую при обучении, но возникают при увеличении масштаба модели.

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

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

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

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

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

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

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

Хочу поделиться разработанной мною архитектурой Graph RAG.

Эта архитектура обладает двумя ключевыми особенностями: во-первых, наличием этапа интеллектуального планирования запроса (R), управляемого онтологией, и, во-вторых, использованием той же онтологии для семантического обогащения и контекстуализации ответа (A-G).

Важную роль играет генерация промежуточного представления (Intermediate Representation, IR) — структурированного, независимого от языка запросов объекта (например, JSON), формализующего намерение пользователя. IR позволяет абстрагироваться от особенностей конкретных СУБД и, тем самым, подключать разные базы данных без влияния на остальные компоненты архитектуры.

Отдельно стоит отметить особенность работы Модуля Валидации: его результаты (успех, тип ошибки, данные `EXPLAIN`) могут использоваться для автоматического сбора сигналов обратной связи (reward signal) и дообучения (fine-tuning) модулей генерации кода. Это создает замкнутый контур для непрерывного, автоматизированного улучшения качества генерации запросов.

Прошу не судить строго за визуализацию — она целиком сгенерирована по описанию архитектуры.

Вдохновение для промптинга слабых моделей нужно черпать не в гайдах Anthropic, а у Джоэла Спольски

Формализованный подход к оценке NL-to-Query систем - часть 1/3

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

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

Почему синтаксическое сравнение не работает?

Оценка NL-to-Query систем осложняется двумя факторами:

1. Вариативность языка: одну и ту же мысль можно выразить множеством способов.

2. Семантическая эквивалентность: разные запросы могут давать одинаковый результат.

Это означает, что прямое сравнение "сгенерированный запрос = эталонный запрос" — неадекватная метрика. Она штрафует синтаксически различные, но при этом корректные решения.

Решение: оценивать не синтаксис запроса, а результат его выполнения.

Формализованный подход к оценке NL-to-Query систем - часть 2/3

Структура тестового набора

Тестирование проводится на фиксированном эталонном наборе данных (Reference Dataset), что обеспечивает воспроизводимость результатов.

Каждый тестовый случай включает три элемента:

1. Эталонный Запрос (Reference Query ): Канонический, верифицированный экспертом запрос к СУБД.

2. Эталонный Результат (Reference Result Set): Множество данных, полученное при выполнении эталонного запроса на эталонном наборе данных. Служит "истинным" результатом для всех сравнений.

3. Множество NL-вариаций: Репрезентативная выборка текстовых формулировок на естественном языке, которые семантически эквивалентны эталонному запросу.

Формализованный подход к оценке NL-to-Query систем - часть 3/3

Процесс оценки и метрики

Оценка качества модели для каждого тестового случая производится итеративно для каждой NL-вариации и включает следующие шаги:

1. Генерация и исполнение: NL-вариация обрабатывается моделью, генерируется формальный запрос, который затем исполняется в СУБД.

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

3. Фиксация результата: При полном совпадении множеств тест считается пройденным.

На основе результатов тестирования вычисляются следующие ключевые метрики:

- Синтаксическая корректность (Parsing Success Rate): Доля запросов, которые были сгенерированы синтаксически корректно.

- Семантическая точность (Semantic Accuracy): Доля NL-вариаций, для которых сгенерированные запросы вернули результат, полностью идентичный эталонному. Метрика характеризует способность модели распознавать семантику запроса независимо от лексико-синтаксического выражения.

Данный подход обеспечивает объективную и воспроизводимую оценку систем NL-to-Query.

RAG в архитектуре мультиагентных систем играет ту же роль, что R в CRUD или Q в CQRS.

Не могу не поделиться фрагментом интерфейса Memgraph Lab: Memgraph Lab’s LLM integrations allow you to chat with Memgraph in English, without needing to know Cypher.

https://memgraph.com/docs/memgraph-lab/features/graphchat

https://memgraph.com/docs/memgraph-lab/features/graphchat

Note: Large graph schemas can consume significant tokens in the LLM’s context window. In such cases, consider disabling automatic inclusion of the graph schema to optimize cost and performance.

Прелесть Cypher-баз данных в том, что при наличии онтологии graph schema - это и есть онтология.

И самое интересное начинается там, где схемы становятся большими.
Это «интересное» — context engineering, к которому структура онтологии должна быть «дружественной».

По просьбам подписчиков попробую пересказать предыдущий пост простыми словами.

Онтология отражает язык вашей предметной области, на котором вы разговариваете каждый день в своей работе.

Этот язык не нужно придумывать — его нужно «вытащить на поверхность» и оцифровать.

Когда вы создаёте онтологию, вы формализуете этот язык, чтобы его одинаково понимали и вы, и ваши коллеги, и машины.

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

Одновременно вы создаёте и «скелет» знаний для LLM — основу, на которую модель сможет опираться при решении ваших задач.

LLM прекрасно натренированы на синтаксисе формальных онтологий (например, Turtle) и хорошо его понимают.

Передавая онтологию в контекст LLM через промпт (in-context learning), вы выполняете «заземление» рассуждений модели (grounding) и резко снижаете вероятность галлюцинаций.

Модель буквально начинает говорить на вашем языке.

Структура формальных онтологий (тройки субъект-предикат-объект) естественным образом отображается на структуру графовых баз данных.
Разрабатывая онтологию, вы фактически проектируете схему вашей будущей графовой базы данных.

А дальше — всего один шаг, чтобы начать разговаривать с вашими данными в графовой БД на вашем языке.

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

О многом из сказанного в этом тексте я уже писал в своих предыдущих постах — и пытливый ум при желании мог воссоздать эту «картину» ещё несколько месяцев назад.