Полный провал в финансовых и юридических задачах: разбираем два кейса GDPx и выясняем, почему ИИ умеет считать и составлять договоры, но не выдаёт результат, отвечающий требованиям

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

2 ноября 2026 года SemiAnalysis представила GDPx v1.0 — бенчмарк сложных профессиональных задач. Из 11 областей в финансах и праве ни одна из протестированных моделей не прошла задания полностью по изначальному бинарному критерию. Чтобы показать различия между моделями, исследовательской группе пришлось использовать «средний частичный балл».

Это не эмоциональный вывод в духе «ИИ ни на что не годится». Некоторые модели набрали в юридическом кейсе в среднем 44% баллов, а в финансовом выполнили около половины проверок при приёмке. Главный вопрос здесь в другом: почему результат, наполовину выполненный правильно, всё равно нельзя сдавать?

Что вы узнаете: какие суммы, показатели неудач и критерии оценки фигурируют в финансовой задаче Bellwood-QoE и задаче по внесению поправок в устав при инвестиционном раунде B. Это также поможет чётче разграничить способность ИИ помогать в работе и способность самостоятельно отвечать за конечный результат.

Финансовые и юридические задачи: ни одного полного прохождения

Первый выпуск GDPx охватывает 11 профессиональных областей и 206 задач. По умолчанию на каждую задачу отводится до 8 часов. Тест оценивает работу всей связки: «модель + агентный фреймворк + инструменты + рабочая среда». Claude Opus 5.5, занявшая первое место в общем рейтинге, набрала всего 12,0%. На этом фоне особенно выделяются две области — финансы и право.

При чтении таблицы стоит учесть два момента. Во-первых, бинарная оценка 0% не означает, что результаты всех запусков бесполезны: частичные баллы явно отличались от нуля. Во-вторых, 25 и 20 запусков в таблице относятся к тестированию отдельных публичных кейсов. Это не общее количество запусков для всех 24 финансовых или 20 юридических задач.

Почему финансовые и юридические задачи проверяют так строго

В обеих областях результат работы — не просто совет, а файл, который можно сразу использовать в реальной сделке. При комплексной проверке перед слиянием или поглощением либо на переговорах о финансировании ошибка в расчёте чистого долга или защитное положение, которое можно обойти, способны сделать весь документ непригодным для работы. Поэтому GDPx применяет строгие критерии приёмки, близкие к требованиям профессиональной практики. Это и объясняет появление результата 0%.

Пример финансовой задачи: как Bellwood-QoE заставил ИИ верно посчитать цифры, но не справиться с итоговой работой

Контекст сделки и требования к задаче

Living Context превращает опыт реальных сделок в анонимизированную тестовую среду. В этом сценарии фонд прямых инвестиций Bannock Capital приобретает около 62% акций Haverly Snack Company за примерно 880 млн долларов; сделка также предусматривает условное вознаграждение. Среда содержит около 4000 анонимизированных документов: главную бухгалтерскую книгу, банковские выписки, данные по зарплатам, анализ дебиторской задолженности по срокам, договорную переписку, документы по сделке, таблицы исторических корректировок и рабочие материалы разных консультантов.

Модели нужно продолжить работу над незавершённой книгой анализа качества прибыли (QoE). Она должна определить, какие данные уже верны, исправить ошибки в цифрах и классификации, сохранив правильные записи и структуру расчётов. Кроме того, ей нужно проверить корректировки EBITDA, сверить данные по оборотному капиталу за 12 месяцев, разобраться с методикой расчёта чистого долга, подкрепить каждую корректировку документами и обеспечить согласованность ссылок между таблицами. Результатом должна стать сама исправленная книга.

Результаты тестирования Bellwood-QoE

Самые сильные модели в среднем проходили около половины проверок, а в лучшем отдельном запуске удалось пройти 8. Но если среди оставшихся проверок обнаруживается критическая финансовая ошибка, всю рабочую книгу нельзя сдавать. Три типа ошибок ниже показывают, в чём проблема.

Финансовая ошибка первая: корректировке на 418 долларов придали слишком широкий смысл

По корректировке на 418 долларов, начисленной по результатам страхового аудита, платить уже не требовалось. Однако некоторые модели решили, что это означает прекращение всех прежних обязательств по страховому полису от несчастных случаев на производстве. В результате EBITDA за последние 12 месяцев была занижена на 4728 долларов. Такая ошибка возникла в 10 из 15 соответствующих запусков Opus, Astra и Sol.

Это не ошибка умножения. Модели распространили бухгалтерский и юридический смысл конкретной корректировки на все прежние обязательства по страхованию. Отклонение в 4728 долларов стало следствием такой ошибочной трактовки, а не результатом умножения 418 долларов на какой-либо коэффициент. Такую ошибку сложно обнаружить повторной проверкой вычислений: сами формулы могут быть верными.

Ошибка в финансовом анализе № 2: расходы на сделку включили в чистый долг

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

Так проявляется разница между «данные есть» и «данные правильно классифицированы». В сделках M&A чистый долг обычно влияет на сумму, которую фактически платит покупатель, поэтому последствия ошибки выходят за рамки таблицы.

Ошибка в финансовом анализе № 3: пропущенные корректировки расходов

Исследователи обнаружили и ряд менее заметных проблем:

• В 17 запусках вознаграждение членов семьи, которые фактически не работали, по-прежнему считалось обычным операционным расходом компании;
• В большинстве запусков не были выявлены личные расходы владельца, указанные только в примечаниях к главной книге;
• В 10 из 15 запусков самой сильной модели была пропущена корректировка исторических расходов на продвижение в размере 9192 долларов: расходы, относящиеся к другому периоду, включили в текущие 12 месяцев.

Эти ошибки затрагивают одновременно учетный период, характер расходов, источники подтверждений и экономическую суть сделки. Смысл анализа качества прибыли как раз в том, чтобы исключить подобные статьи, которые «выглядят как операционные расходы, но на самом деле ими не являются». Если их пропустить, EBITDA не отразит реальную способность компании зарабатывать.

Кейс из юридической практики: почему все 20 вариантов правок устава для раунда B оказались непригодны

Требования задачи

В задаче quillon-series-b-redline ИИ представлял интересы ведущего инвестора раунда B и должен был внести правки в подготовленный к подписанию устав компании. Среди исходных материалов были подписанный перечень условий инвестирования, таблица структуры капитала, письмо клиента, проект устава и другие документы по сделке. Критерий успеха — защитить законные интересы инвестора, не меняя без оснований уже согласованные коммерческие условия. Это задача на юридическую оценку с сопоставлением нескольких документов, а не на стилистическую правку текста.

Результаты юридического кейса и три ключевые ошибки

Важно уточнить: 18% — это средний частичный балл запусков в рамках данного кейса, а не общий показатель GDPx для юридической сферы.

Ошибка первая: читать положения, но не считать голоса. В 13 запусках модели не обнаружили, что у остальных акционеров достаточно голосов, чтобы отменить защитное положение, необходимое ведущему инвестору. То, что защитное положение записано в уставе, ещё не означает, что оно надёжно. Чтобы понять, можно ли его отменить, нужно рассчитать голоса с учётом структуры владения акциями.

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

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

Как контролируется надёжность юридической оценки

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

Общая причина ошибок в финансовых и юридических задачах: дело не в тексте, а в суждениях

Living Context выделяет четыре распространённых типа ошибок в финансовых задачах. Они во многом совпадают с тем, что наблюдалось в юридических примерах:

Это типы ошибок, обобщённые исследовательской командой, а не универсальные показатели частоты ошибок для всех финансовых моделей компаний или юридических документов. Общий вывод таков: главная сложность часто не в создании текста, а в выборе источников, профессиональных суждениях, неявных ограничениях, согласованности между документами и итоговой приёмке. Чем более гладко отвечает модель, тем легче упустить эти проблемы.

Анализ влияния ИИ в финансах и юриспруденции: как отличить помощь от самостоятельной сдачи результата

Что это значит для руководителей ИИ-направлений и разработчиков в компаниях

GDPx не ставит под сомнение ценность ИИ как помощника в профессиональной работе. Частичные баллы показывают, что модели уже способны выполнять часть требований приёмки. Но исследование не даёт оснований оценить, сколько времени или денег экономит работа с участием человека, поэтому напрямую переводить выводы по кейсам в ROI не стоит. Практичнее предоставлять ИИ полномочия с учётом уровня риска. За основу можно взять таблицу:

Такая градация согласуется с направлением внешних рекомендаций. В документе Formal Opinion 512, опубликованном 29 июля 2024 года, Американская ассоциация юристов (ABA) указывает, что при использовании генеративного ИИ юристы по-прежнему должны соблюдать требования к профессиональной компетентности, конфиденциальности информации клиентов, коммуникации, надзору и обоснованности гонораров. Им также необходимо понимать возможности и ограничения инструмента и не принимать его результаты без проверки. Документ NIST AI RMF Generative AI Profile, опубликованный 26 июля 2024 года, также подчёркивает, что организации должны организовывать человеческий надзор, оценку, документирование и управление с учётом условий применения. При этом рекомендации ABA относятся к профессиональной этике юристов в США, а документ NIST не является результатом тестирования GDPx. Оба источника можно использовать лишь в качестве ориентиров при работе в других областях.

Создаём через API помощника для выявления противоречий

Одна из самых частых ошибок в юридических кейсах GDPx — не заметить противоречие между письмом клиента и подписанными условиями. Задачи на поиск расхождений и формулирование вопросов хорошо подходят для помощи уровня L2, при условии что результаты используются лишь как подсказки для проверки человеком. В примере ниже модель сопоставляет два текста и перечисляет противоречия и вопросы, требующие ручной проверки:

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # OpenAI-совместимый интерфейс APIYI
)

resp = client.chat.completions.create(
    model="claude-sonnet-4-20250514",
    messages=[{"role": "user", "content": "对照【已签署条款清单】与【客户邮件】，只列出冲突项和需人工确认的问题，不要直接修改条款。\n条款清单：...\n客户邮件：..."}]
)
print(resp.choices[0].message.content)

import openai
from typing import List, Dict

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # Один ключ для вызова моделей разных поставщиков
)

SYSTEM = (
    "你是交易文件审查助手。你的输出只作为专业人员的审查线索，"
    "必须遵守：1) 已签署文件效力优先于邮件和旧表格；"
    "2) 发现冲突时提示，不得自行改写商业条款；"
    "3) 每条结论标注依据的文件名和段落；"
    "4) 无法确认的事项明确写'需人工确认'。"
)

CHECKS = [
    "客户邮件中的要求是否与已签署条款清单冲突",
    "结合股权结构，其他股东能否凭投票权移除保护条款",
    "保护条款是否覆盖子公司，是否存在绕行路径",
]

def review(docs: str, models: List[str]) -> Dict[str, str]:
    """Получить подсказки для проверки от нескольких моделей, чтобы специалист мог сопоставить их ответы"""
    prompt = "请逐项检查：\n" + "\n".join(f"- {c}" for c in CHECKS) + f"\n\n材料：\n{docs}"
    results = {}
    for m in models:
        try:
            r = client.chat.completions.create(
                model=m,
                messages=[{"role": "system", "content": SYSTEM},
                          {"role": "user", "content": prompt}],
                temperature=0
            )
            results[m] = r.choices[0].message.content
        except Exception as e:
            results[m] = f"调用失败: {e}"
    return results

if __name__ == "__main__":
    out = review("条款清单：...\n股权结构表：...\n客户邮件：...\n章程草稿：...",
                 ["claude-sonnet-4-20250514", "gpt-4o"])
    for model, text in out.items():
        print(f"===== {model} =====\n{text}\n")
    # Окончательное решение о принятии результатов принимает юрист или финансовый специалист, проверяя каждый пункт по контрольному списку

🚀 Как быстро начать: при построении такого вспомогательного процесса можно сначала подключить несколько популярных моделей через APIYI apiyi.com с помощью одного API-ключа и сравнить, насколько хорошо они выявляют конфликты в ваших обезличенных примерах. Новые пользователи могут провести небольшую проверку в рамках бесплатного тестового лимита, а затем решить, стоит ли запускать пилотный проект.

Влияние на финансовые и юридические технологии

Результаты GDPx напоминают: при оценке профессиональных AI-продуктов недостаточно смотреть, насколько гладко проходит диалог с моделью. Важно, сможет ли итоговый результат пройти профессиональную приёмку. Для поставщиков конкурентоспособность продукта будет всё больше зависеть от таких технических деталей, как «приоритет авторитетных документов», «уведомления о конфликтах», «сохранение исходной структуры формул» и «отслеживание источников доказательств». Заказчикам же стоит самостоятельно тестировать продукты на задачах, близких к их реальной работе. GDPx также опубликовал лишь часть задач и журналов выполнения, поэтому необходимы дополнительные независимые проверки и воспроизведение результатов.

💡 Совет по выбору: производительность моделей заметно различается в разных областях, поэтому единый общий рейтинг не отражает их пригодность для ваших задач. Через единый интерфейс APIYI apiyi.com можно параллельно протестировать несколько моделей на собственных задачах, записывая как частичные результаты, так и прохождение ключевых проверок. Не ориентируйтесь только на средний балл. Доступность конкретных моделей уточняйте в актуальном списке платформы.

Частые вопросы FAQ

Оценка AI в финансовых и юридических задачах: главное

• Ни одна модель не прошла строгую приёмку: по бинарному критерию ни одна модель полностью не справилась с задачами GDPx в финансовой и юридической областях.
• Частичные результаты были ненулевыми: лучший результат в финансовом кейсе — 8 из 11 проверок за один запуск, а в юридическом — 57% за один запуск.
• Ошибка была в суждении, а не в расчётах: неверная интерпретация корректировки на 418 долларов привела к занижению EBITDA на 4728 долларов.
• Приоритет источников имеет значение: в 14 из 20 запусков модель поставила письмо клиента выше подписанного перечня условий.
• Неявные ограничения учесть сложнее всего: ни в одном из 20 запусков не удалось предотвратить риск обхода ограничений через дочернюю компанию.
• Три понятия нельзя смешивать: частичный результат, полное прохождение проверки и готовность к промышленному использованию нужно оценивать отдельно.
• Сначала помощь, затем пилот: через единый интерфейс APIYI apiyi.com можно провести поэтапную проверку нескольких моделей на собственных примерах.

Итоги

Главные выводы из финансовых и юридических задач GDPx можно свести к трём пунктам:

1. Гладкий результат — ещё не качественный: даже если расчёты в таблице верны, а условия изложены складно, модель может ошибиться в оценке экономической сути, структуры прав и противоречий между документами;
2. Профессиональный результат требует суждения: главные сложности — оценка авторитетности источников, последствий второго порядка, неявных ограничений и согласованности документов;
3. Полномочия нужно распределять поэтапно, а критерии приёмки — определять заранее: следуя подходам ABA и NIST, стоит сохранить проверку человеком и использовать AI как помощника и инструмент для подготовки первых черновиков.

AI уже способен выполнять часть полезной работы в сложных профессиональных задачах, но до самостоятельной подготовки результатов, за которые можно нести ответственность, ему ещё далеко. Если вы оцениваете AI-решения для финансовых или юридических сценариев, сравните через APIYI apiyi.com частичные результаты нескольких моделей и долю прохождения ключевых проверок на собственных рабочих примерах. Это поможет определить границы полномочий AI.

📚 Источники

1. Оригинальный отчёт SemiAnalysis GDPx: разделы о финансах и праве, примеры и типичные ошибки
2. Ссылка: newsletter.semianalysis.com/p/gdpx-measuring-frontier-model-capabilities

3. Описание: первоисточник данных по кейсам Bellwood-QoE и quillon-series-b-redline

4. Описание областей GDPx и открытые записи выполнения: количество задач, партнёры и записи действий агентов

5. Ссылки: gdpx.semianalysis.com/domains, gdpx.semianalysis.com/rollouts

6. Описание: здесь можно посмотреть, как выполнялись некоторые общедоступные задачи

7. Пресс-релиз об ABA Formal Opinion 512: рекомендации по профессиональной этике для юристов, использующих генеративный ИИ

8. Ссылка: americanbar.org/news/abanews/aba-news-archives/2024/07/aba-issues-first-ethics-guidance-ai-tools/

9. Описание: относится к юридической профессии в США и может служить ориентиром для принципов проверки человеком

10. Профиль генеративного ИИ NIST AI RMF: система управления рисками генеративного ИИ

11. Ссылка: nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
12. Описание: межотраслевой источник по вопросам надзора со стороны человека, оценки и мер управления

Автор: техническая команда APIYI
Технические вопросы: свяжитесь с нами на главной странице сайта APIYI. Дополнительные материалы по подключению доступны в центре документации docs.apiyi.com

Читайте также

• Почему нельзя слепо доверять баллам в рейтингах: 3 причины benchmaxing и выбор модели в 4 шага с помощью оценки на собственных задачах: Объясните, почему benchmaxing завышает оценки в публичных рейтингах, приведите чек-лист из 5 пунктов для проверки их надёжности и 4 шага работы с приватным набором задач: выборка, критерии приёмки, тестирование нескольких моделей и регулярное обновление — для выбора модели на собственных задачах.
• Юридическая версия Astra от OpenAI уже доступна? Ответы на 4 вопроса о ценах, условиях подачи заявки и ограничениях API: На официальной странице цен OpenAI уже указан gpt-6-astra-law, но «цена опубликована» не означает «доступен всем»; в статье рассматриваются назначение юридической версии Astra, цены, условия подачи заявки и ограничения API по состоянию на 2 ноября 2026 года.
• Создаём агента для формирования сводок мониторинга по расписанию: 4 компонента и руководство по выбору интерфейсов: Разберите 4 компонента агента для создания сводок мониторинга по расписанию, объясните, как слой вызова модели отделяется от конкретного SDK с помощью OpenAI-совместимого интерфейса, и приведите рабочий пример на Python.