Архитектура двухслойной валидации для анализа документов: как LLM + код находят в 2.5 раза больше рисков

Почему одна LLM всегда врёт о ваших документах

Вы загружаете договор в GPT-5 Turbo, спрашиваете «Какие здесь риски?» и получаете красивый список. Потом юрист смотрит и говорит: «Половина — ерунда, а самое опасное пропустили». Знакомо? Проблема не в модели, а в архитектуре. Одна LLM — это один взгляд, один контекст, одна точка отказа. Она либо галлюцинирует, либо пропускает сложные логические связи.

В 2026 году топовые модели вроде Claude 3.7 Sonnet или GPT-5 стали умнее, но их фундаментальная слабость осталась: они блестяще работают с языком, но ужасно — с логикой и числами. Они могут написать поэму о процентной ставке, но пропустят, что в пункте 4.2 она противоречит приложению Б.

Двухслойная архитектура: где LLM работает, а где отключаем её мозги

Идея проста, но её почти никто не использует. Первый слой — ансамбль LLM-промптов. Они ищут семантические риски, неоднозначности, скрытые смыслы. Второй слой — детекторы на чистом коде (Python, regex, логические правила). Они проверяют то, что LLM проверять не может: числовые противоречия, ссылки на несуществующие пункты, формальные нарушения.

Почему именно два слоя? Потому что каждая технология делает то, что у неё получается лучше всего. LLM отлично справляется с пониманием намерений, код — с проверкой фактов. Объединяем их — получаем систему, которая не просто «анализирует», а фактически проводит юридико-технический аудит.

Слой 1: 32 промпта, которые не повторяют друг друга

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

• Группа «Юридические ловушки» (8 промптов): Ищет нестандартные условия расторжения, скрытые обязательства, чрезмерные штрафы. Каждый промпт заточен под конкретный тип договора (аренда, поставка, NDA).
• Группа «Финансовые аномалии» (6 промптов): Анализирует формулы расчёта, валютные риски, неявные индексации. Здесь критически важна работа с числами, поэтому эти промпты выдают только подозрения, которые потом проверяет код.
• Группа «Ссылочный ад» (5 промптов): Отслеживает циркулярные ссылки («см. пункт 5.1», где в 5.1 написано «см. пункт 3.2»), ссылки на несуществующие приложения, противоречивые отсылки к законодательству.
• Группа «Стилистические маркеры» (7 промптов): Ищет слишком расплывчатые формулировки («разумные сроки», «существенное нарушение»), избыточные уточнения, которые могут трактоваться двояко.
• Группа «Контекстуальные связи» (6 промптов): Сравнивает условия в разных разделах. Например, срок оплаты в финансовом разделе — 30 дней, а в разделе санкций за просрочку — 14 дней. LLM отлично видит такие несоответствия, если дать ей сравнить два фрагмента.

Каждый промпт работает независимо, результаты агрегируются. Ключевой трюк — заставить промпты возвращать данные в строгом JSON, а не в свободном тексте. Иначе второй слой не сможет с этим работать.

Слой 2: 25+ детекторов на коде, которые не верят ни одному слову LLM

Второй слой — это скептик. Он берёт все «найденные риски» от LLM и говорит: «Докажи». А ещё он сам ищет то, что LLM пропустила. Вот из чего он состоит:

1 Числовые детекторы

LLM постоянно ошибается в арифметике. Детектор извлекает все числа и даты из документа, строит временные линии и проверяет логику. Если в одном месте срок — 30 дней, а в другом за тот же процесс — 45 дней, детектор флагует противоречие, даже если LLM его пропустила.

def detect_numeric_contradictions(doc_text, llm_flags):
    """Ищет числовые противоречия, которые LLM могла пропустить."""
    # Извлекаем все упоминания сроков
    deadlines = re.findall(r'(\d+)\s*(день|дня|дней|рабочих дня)', doc_text)
    # Преобразуем в дни
    deadline_days = [int(d[0]) for d in deadlines]
    # Если разброс больше 50% от минимального значения - флаг
    if deadline_days:
        min_deadline = min(deadline_days)
        max_deadline = max(deadline_days)
        if max_deadline > min_deadline * 1.5:
            return {"risk": "NUMERIC_CONTRADICTION",
                    "details": f"Сроки варьируются от {min_deadline} до {max_deadline} дней"}
    return None

2 Референсные детекторы

Они строят граф ссылок документа. Каждый пункт, приложение, статью закона — как узел. Потом проверяют, нет ли ссылок на несуществующие узлы, нет ли циклических зависимостей (пункт 3 ссылается на 4, а 4 — на 3). LLM иногда замечает такие вещи, но часто пропускает, особенно в длинных документах.

3 Детекторы формальных нарушений

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

4 Валидаторы против галлюцинаций LLM

Самый важный тип детекторов. Они берут каждый флаг от LLM и ищут прямое текстовое подтверждение в документе. Если LLM говорит: «В пункте 5.2 указана неустойка 1% в день», детектор ищет в оригинальном тексте слова «пункт 5.2», «неустойка», «1%». Если не находит — флаг считается ложным срабатыванием и отбрасывается.

Как соединить два слоя: пайплайн, а не просто цепочка

Ошибка большинства гибридных систем — линейная цепочка: «LLM проанализировала → код проверил». В реальности нужно параллельное выполнение с кросс-валидацией.

1. Параллельный запуск: Все 32 промпта и 25+ детекторов запускаются одновременно. Нет последовательных задержек.
2. Дедупликация флагов: И LLM, и детекторы могут найти одно и то же разными путями. Алгоритм семантического сходства объединяет дубликаты.
3. Кросс-проверка: Если детектор нашёл риск, который пропустили все LLM-промпты, система помечает его как «высокая важность» — это обычно сложные логические ошибки.
4. Приоритизация: Каждому риску присваивается вес: LLM + детектор = высший приоритет, только детектор = высокий, только LLM = средний (требует ручной проверки).

Технически это реализуется на Celery или RQ для параллельных задач и Redis для агрегации результатов. Важно кэшировать результаты LLM-запросов — иначе стоимость API убьёт бюджет.

Типичные ошибки, которые мы совершили вместо вас

За год эксплуатации системы мы набили шишек, которые можно избежать:

• Слишком много промптов с одинаковой семантикой: 10 промптов, которые ищут «скрытые условия», дают 10 слегка разных вариантов одного и того же. Трата денег и времени. Нужна чёткая специализация.
• Детекторы без контекста: Детектор, который ищет фразу «в одностороннем порядке» и всегда флагует её как риск, будет генерировать тонны шума. Нужно учить детекторы понимать контекст (хотя бы по соседним предложениям).
• Игнорирование дедупликации: В начале система выдавала 150 «рисков» на документ, из которых 90 были дублями. Юристы ненавидели нас. Алгоритм на основе эмбидингов (например, семантического пайплайна) решил проблему.
• Нет механизма обратной связи: Юрист помечает флаг как ложный → система должна запомнить это и скорректировать веса промптов/детекторов. Иначе вы застрянете в вечной настройке.

Что будет, если завтра выйдет GPT-6?

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

Более того, с ростом сложности моделей растёт и стоимость ошибки. Галлюцинация GPT-6 будет убедительнее, её сложнее заметить. Значит, нужны будут более сложные детекторы, а не отказ от них.

Двухслойная архитектура — это не временное решение. Это принцип: используй каждый инструмент для той задачи, которую он решает лучше всего. LLM — для понимания смысла, код — для проверки фактов. В 2026 году это даёт прирост в 2.5 раза по найденным рискам. В 2027 году, возможно, будет 3 раза. Но принцип останется.

Если вы сейчас строите систему анализа документов на одной LLM, вы оставляете на столе большинство реальных рисков. И тратите время экспертов на проверку ложных срабатываний. Два слоя, 32 промпта, 25 детекторов — звучит сложно. Но это проще, чем объяснять клиенту, почему вы пропустили условие о штрафе в 2 миллиона в пункте 12.1 приложения В.