Промпт-инжиниринг для качества данных в инвестИИ

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

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

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

Почему правила и регулярки перестали спасать

Короткий ответ: потому что инвестиционные данные стали полуструктурированными и контекстными, а правила — статичными.

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

• новости, релизы, протоколы заседаний регуляторов;
• сообщения брокера об ошибках/отклонениях ордеров;
• web-scrape с календарей дивидендов;
• лог-файлы и алерты торговой инфраструктуры;
• заявки и документы клиентов (KYC/AML) в свободном тексте.

Правило может поймать «2023-31-02» как плохой формат. LLM поймает это как невозможную дату — и, главное, объяснит, почему.

В инвестициях ценность «смысловой» проверки обычно выше, чем кажется. Пример из практики: цена акции «вдруг» стала в 100 раз ниже из‑за того, что в одном из фидов пришла цена в центах, а не в долларах. Диапазоны могут не сработать (если бумага дешёвая), а контекстная проверка “единицы измерения + историческая динамика + тип инструмента” — сработает.

LLM как аудитор: что он видит, чего не видят скрипты

Короткий ответ: LLM силён в проверке согласованности и правдоподобия, особенно когда данные «размазаны» по полям и источникам.

Вместо «совпадает ли поле с regex» мы задаём вопрос уровня аудитора: “имеет ли запись смысл в контексте набора данных и доменных правил?”.

Три класса ошибок, которые LLM ловит особенно хорошо

1. Семантические противоречия

   • Валюта инструмента — EUR, а котировка пришла с символом USD.
   • В корпоративном событии указан дивиденд после даты ex‑div.

2. Несостыковки между полями

   • order_type=LIMIT, но limit_price пустой.
   • Время сделки выходит за торговую сессию биржи (с учётом таймзоны).

3. Скрытые “аномалии-переименования”

   • Поставщик данных поменял смысл поля volume (например, с лотов на акции), а формат остался прежним.

Эта логика один в один совпадает с задачами ИИ в логистике: статусы перевозок «в пути/на складе/доставлено» могут приходить в разных формулировках, и система планирования должна понять, что «arrived at hub» — это “прибыло на сортировку”, а не “доставлено клиенту”. LLM в таких местах очень уместен.

Как писать промпты, чтобы модель “думала как валидатор”

Короткий ответ: давайте схему, цель, примеры, требуйте объяснение и жёсткий формат ответа.

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

Шаблон промпта для проверки записей (универсальный)

• Контекст: что за датасет и откуда он
• Схема: какие поля, типы, допустимые значения
• Доменные правила: торговые часы, валюта, точность, единицы
• Задача: что считать ошибкой, что — подозрением
• Формат вывода: JSON/таблица, чтобы это съел пайплайн
• Требование объяснения: 1–2 предложения, без «воды»
• Оценка уверенности: шкала 0–1 или 0–100

Сильная привычка: разделяйте “ошибка” и “подозрение”. Для продакшена это снижает количество ложных блокировок.

Пример промпта: валидация торговых тиков

Ты — аудитор качества данных для алгоритмической торговли.

Проверь записи тиков по правилам:
1) timestamp должен быть в формате ISO и попадать в торговую сессию 10:00–18:45 по Москве.
2) price > 0, bid <= ask, spread не больше 2% от mid.
3) volume — целое число, в лотах; если инструмент облигация, volume обычно кратен 10.
4) Если price отличается от медианы последних 30 тиков более чем на 5%, пометь как подозрение.

Вход: список записей JSON.
Выход: строго JSON массив объектов {id, status: OK|ERROR|SUSPECT, issues: [..], confidence, note}.
В note объясни причину в 1–2 предложениях.

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

Иерархическая проверка: сначала “скелет”, потом смысл

Я предпочитаю трёхступенчатую схему — она даёт меньше хаоса в результатах:

1. Схема/полнота: поля на месте? типы читаются?
2. Проверка значений: диапазоны, форматы, обязательные связи
3. Кросс-проверки: согласованность между записями и источниками

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

Как встроить доменные знания: без них LLM будет “умничать”

Короткий ответ: доменные якоря (правила рынка, единицы, справочники) нужны прямо в промпте или рядом с ним.

В финансах «выброс» зависит от контекста. Сделка на 10 000 долларов подозрительна в розничном потоке, но обычна в B2B. То же с данными: 8% дневной гэп — норма в малоликвидных бумагах и тревожный сигнал в крупном индексе.

Что добавлять в промпт, чтобы модель не фантазировала:

• описание инструментов: акции/фьючерсы/облигации, валюта, тик-сайз, лотность;
• правила торговых сессий по биржам и праздникам;
• справочник кодов: причины отклонения ордеров, статусы сделок;
• примеры “хороших” и “плохих” записей из вашей реальности.

Практика, которая отлично работает: держать рядом с промптом короткий “кодбук” (10–30 строк), и обновлять его вместе с изменениями у поставщиков данных. Это дешевле, чем потом отлавливать последствия на PnL.

Автоматизация: как сделать LLM-проверки частью пайплайна

Короткий ответ: ставьте LLM не на весь поток, а на крайние случаи и критичные точки.

LLM‑запросы стоят денег и времени, поэтому в продакшене выигрывает гибридный подход:

1. Правила/SQL/Great Expectations ловят очевидное быстро и дёшево.
2. LLM проверяет:
   • записи, которые прошли формально, но выглядят странно;
   • новые символы/поля после обновления провайдера;
   • неструктурированный текст (новости, логи, письма);
   • «дорогие» данные: корпоративные события, референс‑данные, маппинги.

Практичный паттерн для ETL/ELT

• На входе: техническая валидация (типы/NULL/диапазоны)
• Далее: “LLM‑гейт” на выборке (например, 1–5% случайно + 100% подозрительных)
• На выходе: запись результата в таблицу качества (dq_findings) и маршрутизация:
  • ERROR → блокировка/карантин
  • SUSPECT → ручная проверка или повторная проверка другим промптом
  • OK → в прод

Удобная метрика для руководителя: “доля записей, ушедших в карантин” и “среднее время разруливания”. Это быстро показывает, улучшаете вы качество данных или просто добавили шума.

3 способа снизить стоимость LLM-валидации

1. Сэмплирование и приоритезация: проверяйте то, что влияет на решения (сигналы, риск, исполнение).
2. Шаблоны промптов: один раз отладили — используете в десятках пайплайнов.
3. Двухшаговый режим: дешёвая модель сортирует на “норм/странно”, дорогая разбирает только странное.

Частые вопросы из команды (и честные ответы)

“Можно ли доверять LLM, если она ошибается?”

Да, если вы используете её как второй слой контроля, а не как единственный источник истины. Правила остаются основой. LLM добавляет смысловую проверку и объяснения.

“Не попадут ли чувствительные данные в модель?”

Риск есть всегда, поэтому архитектурно правильно: минимизировать PII, маскировать поля, передавать только нужные атрибуты, хранить промпты и ответы в защищённом контуре. Для KYC/AML это особенно критично.

“Как понять, что промпт стал хуже после изменений?”

Нужен регрессионный набор: 200–500 исторических кейсов (OK/ERROR/SUSPECT) и прогон при каждом изменении промпта. Если метрики точности/полноты просели — откатывайте.

Что это даёт инвесторам и командам ИИ — по делу

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

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

Если вы строите или масштабируете AI‑решения для инвестиций и хотите внедрить LLM‑валидацию без хаоса (с метриками, карантином, шаблонами промптов и безопасностью), имеет смысл начать с одного критичного потока — и довести его до стабильного результата за 2–4 недели.

Какая точка у вас самая болезненная прямо сейчас: рыночные фиды, корпоративные события, данные по сделкам или отчётность для риск‑контроля?