RAG для трейдера: поиск по своим заметкам без дообучения ИИ

TL;DR: RAG не учит нейросеть торговать и не превращает старые заметки в торговый сигнал. Он сначала находит подходящие фрагменты в вашем журнале сделок, а затем даёт их модели как контекст — поэтому ответ можно проверить по исходным записям.

Ключевые факты

Факт	Что это значит на практике	Источник
Embeddings превращают текст в числовые векторы для семантического поиска и RAG; для индексации и запроса рекомендуется использовать одну модель.	Если поменять embedding-модель, базу заметок обычно нужно переиндексировать, иначе сравнение векторов теряет смысл.	Документация Ollama: Embeddings
pgvector поддерживает точный и приближённый поиск; HNSW и IVFFlat обменивают часть полноты результатов на скорость.	Для небольшого личного журнала точного поиска часто достаточно. Индекс «на вырост» не обязателен.	Официальный репозиторий pgvector
Полнотекстовый и векторный поиск можно объединять в гибридный.	Это полезно для тикеров, точных цен и названий сетапов: семантика находит смысл, обычный поиск — точное совпадение.	pgvector: Hybrid Search
RAG не устраняет риск prompt injection.	Загруженные документы нельзя считать безопасными инструкциями; модели следует давать только чтение и запрещать выполнять команды из найденного текста.	OWASP: Prompt Injection

Что такое RAG без маркетингового тумана

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

RAG — retrieval-augmented generation, то есть генерация с предварительным поиском. Система не отправляет модели весь архив. Она разбивает записи на фрагменты, строит для них embeddings, находит несколько фрагментов, близких к вопросу по смыслу, и только их добавляет в запрос.

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

Минимальная схема, с которой я бы начал

1. Привести записи к одному формату. Минимум: дата, рынок, инструмент, таймфрейм, сетап, контекст, решение, результат и вывод. Отдельные поля лучше свободного полотна текста.
2. Разбивать по одной сделке или одному смысловому блоку. Не стоит резать запись посередине вывода. В каждый фрагмент я бы дублировал метаданные: дату, тикер, рынок и ID сделки.
3. Построить embeddings. Для локального прототипа это можно сделать через Ollama. Главное — не менять модель между загрузкой базы и поисковым запросом.
4. Хранить оригинал рядом с вектором. В ответе нужны не только похожие числа, но и исходный текст, ссылка на скриншот и метаданные.
5. Искать гибридно. Векторный поиск хорошо ловит близкий смысл, но точные обозначения вроде BTCUSDT, XAUUSD, «1,0845» или названия сетапа надёжнее дополнительно проверять полнотекстовым фильтром.
6. Требовать цитаты из журнала. Если ответ не содержит ID или даты найденных записей, я считаю его гипотезой, а не результатом анализа.

Где система реально полезна, а где опасна

Практическая польза начинается с вопросов к собственной истории: «Какие ошибки повторялись после двух убытков подряд?», «Что происходило со сделками, открытыми перед CPI?», «В каких записях я нарушал заранее заданный риск?». Такой инструмент экономит время на поиске и помогает увидеть повторяющиеся формулировки.

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

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

Третья опасность — документы с чужими инструкциями. Если база пополняется письмами, веб-страницами или публичными PDF, внутри может встретиться текст, пытающийся управлять моделью. RAG не лечит prompt injection. Найденный контент нужно считать данными, а не командами, а доступ модели ограничивать чтением.

Простой тест качества до подключения реальных денег

Я бы подготовил 20 вопросов, ответы на которые уже знаю из журнала. Для каждого вопроса отмечается: попала ли нужная запись в найденные фрагменты; верно ли модель пересказала её; указала ли источник; признала ли отсутствие данных. Если система красиво отвечает, но не находит нужные сделки, менять нужно поиск и разбиение документов, а не «характер» чат-бота.

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

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

Нужно ли дообучать модель на журнале сделок?

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

Можно ли собрать всё локально и не отправлять журнал в облако?

Да, базовый контур можно построить с локальной embedding-моделью, локальной LLM и локальной базой. Но «локально» не означает «автоматически безопасно»: нужно контролировать резервные копии, доступ к файлам, логи и сторонние расширения.

Нужна ли отдельная векторная база?

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

Может ли RAG давать торговые сигналы?

Он может найти похожие исторические записи и помочь их суммировать, но это не делает результат прогнозом. Рыночный режим меняется, а похожесть текста не равна статистическому преимуществу. Решение о сделке и контроль риска должны оставаться вне автоматического ответа.

Почему не загрузить весь журнал одним файлом в чат?

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

Итог

RAG для трейдера имеет смысл не как оракул, а как поисковый слой над собственной дисциплинированной историей. Я бы начал с единого формата записей, локального прототипа и 20 контрольных вопросов, потребовал ссылки на каждую использованную сделку и не подключал системе право торговать. Если она стабильно находит нужные записи и честно говорит «данных нет», тогда её уже можно превращать в рабочий инструмент анализа.

---

Автор: Denis | Дата: 10 сентября 2026 | Обновлено: 10 сентября 2026
Denis — трейдер с 10+ летним опытом на форексе и крипторынках