LLM-RAG для поиска патентов: как работает семантический поиск + генерация ответов

ЭТАП 1 — RETRIEVAL (поиск):
Запрос → Векторизация → Поиск по семантике в базе → Top-5 документов

ЭТАП 2 — GENERATION (генерация):
Запрос + Top-5 документов → LLM → Контекстный ответ

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

Задача: Ты юрист в российской IT-компании. Клиент спрашивает: "Кто-то уже патентовал алгоритм рекомендаций на основе истории покупок для маркетплейсов?" Keyword-поиск выдаст всё про "рекомендации" или "маркетплейсы" — тонны мусора. Тебе нужно найти семантически похожие патенты, даже если формулировки другие.

Промпт:

У меня база из 500 российских патентов по IT (загружена файлом patents_ru_2020-2024.csv).

Найди патенты, которые описывают:
- Персонализация контента на основе поведения пользователя
- Использование истории транзакций для предсказаний
- Алгоритмы для e-commerce платформ

НЕ ищи по keywords. Ищи по СМЫСЛУ — даже если слова "рекомендации" или "маркетплейс" нет, но идея похожа.

Выдай:
1. Топ-5 релевантных патентов с номерами
2. Краткое описание каждого (2-3 предложения)
3. Степень релевантности к запросу (высокая/средняя/низкая)

Результат:

Модель просканирует загруженную базу по смыслу, не по совпадению слов. Выдаст 5 патентов, где может быть написано "адаптивные системы выбора товаров" или "прогнозирование покупательских предпочтений" — термины другие, но суть та же. Для каждого даст краткую выжимку и объяснит почему релевантно.

LLM хороша в понимании смысла, но плохо держит в памяти конкретные факты из базы данных. Keyword-поиск наоборот — находит точные совпадения, но не понимает семантику.

RAG объединяет силы:

1. Retrieval (поиск) находит релевантные документы по смыслу, не по keywords
2. Augmented (дополненная) — LLM получает конкретные данные из базы
3. Generation — модель формулирует ответ, опираясь на факты, а не на "общие знания"

Preprocessing критичен: если данные грязные (дубли, битые поля, несогласованные форматы) — поиск вернёт мусор. Исследователи стандартизировали даты, почистили от дублей, выровняли классификацию патентов. В реальной работе: перед загрузкой в LLM приведи данные к единому виду — иначе модель запутается.

Рычаги управления:

• Top-K (сколько документов искать) → меньше K = быстрее, но можешь пропустить релевантное
• Поля для поиска (title, abstract, claims) → если ищешь в аннотации, можешь пропустить детали из claims
• Preprocessing (очистка, стандартизация) → грязные данные = плохой поиск

У меня база документов: {описание базы — тип, объём, формат}.

Найди документы, которые соответствуют критериям:
{критерии_поиска — опиши СМЫСЛ, не keywords}

НЕ ищи по точным совпадениям слов. Ищи по СМЫСЛУ — даже если термины другие, но идея похожа.

Выдай:
1. Топ-{N} релевантных документов с {идентификаторы}
2. Краткое описание каждого ({длина} предложений)
3. Степень релевантности (высокая/средняя/низкая) и почему

Что подставлять:

• {описание базы} — тип документов (контракты, статьи, отчёты), сколько штук, в каком формате загружены
• {критерии_поиска} — опиши ЧТО ищешь семантически, не keywords
• {N} — сколько документов вернуть (обычно 5-10)
• {идентификаторы} — номера, названия, даты — что поможет найти документ в базе
• {длина} — сколько предложений для описания каждого

🚀 Быстрый старт — вставь в чат:

Вот шаблон для семантического поиска в базе документов. Адаптируй под мою задачу: [твоя задача]. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

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

⚠️ Требует загрузку документов: RAG не работает "в воздухе" — нужно загрузить базу в чат. Если база огромная (миллионы документов) — ChatGPT/Claude не потянут, нужна инфраструктура.

⚠️ Качество поиска = качество данных: Если документы грязные (дубли, битые поля, разные форматы) — модель вернёт мусор. Preprocessing обязателен перед загрузкой.

⚠️ Не для keyword-задач: Если нужно найти точное совпадение (номер договора, код статьи) — обычный Ctrl+F быстрее. RAG для смысловых запросов, когда keywords не работают.

Исследователи взяли базу Google Patents (2006-2024) — миллионы патентов из USPTO, EPO, JPO. Почистили: убрали дубли, выровняли даты, стандартизировали классификацию технологий. Разбили на train/val/test в пропорции 8:1:1, чтобы модель училась на разнообразных данных.

Тестировали 5 конфигураций:

• gpt-3.5-turbo без RAG → 61.2% точности
• gpt-3.5-turbo + RAG → 65.3%
• gpt-3.5-turbo-0125 без RAG → 62.8%
• gpt-3.5-turbo-0125 + RAG → 80.5% (победитель)
• gpt-4.0 без RAG → 80.1%

Ключевой инсайт: RAG даёт скачок на 28 процентных пунктов (с 62.8% до 80.5% для gpt-3.5-turbo-0125). Интересно, что gpt-3.5-turbo-0125 + RAG обогнал даже gpt-4.0 без RAG. Это значит: правильная архитектура (поиск + генерация) важнее чем просто "более мощная модель".

Измеряли два параметра:

• Accuracy (точность) — сколько из найденных документов действительно релевантны
• Recall (полнота) — сколько релевантных документов нашли из всех возможных

gpt-3.5-turbo-0125 + RAG показал 92.1% recall — почти не пропускает релевантное. Это критично для патентов — пропустил чужой патент = риск нарушения.

В IT-компании накопилась база из 200 внутренних документов (регламенты, best practices, постмортемы). Новичок спрашивает: "Как у нас принято оформлять PR в критичных модулях?" Keywords "PR" и "критичные модули" не дадут точного ответа — могут вылезти документы про production release или project roadmap.

Промпт:

У меня загружена корпоративная база знаний (200 документов: регламенты, постмортемы, best practices).

Найди документы, которые описывают:
- Процесс code review для критичной инфраструктуры
- Требования к pull requests в production-модулях
- Практики безопасной интеграции изменений

НЕ ищи по keywords ("PR", "критичные"). Ищи по СМЫСЛУ — даже если написано "merge request" или "высоконагруженные системы".

Выдай:
1. Топ-5 релевантных документов с названиями
2. Краткую выжимку каждого (3-4 предложения)
3. Конкретные требования/рекомендации из найденных документов

Модель вернёт документы где может быть написано "интеграция в ядро системы" или "процедуры ревью для платёжного модуля" — термины другие, но смысл тот же.

Если первый запрос вернул мусор — дай модели примеры того, что считаешь релевантным.

Модифицированный промпт:

У меня база документов: {описание базы}.

Найди документы, которые соответствуют критериям:
{критерии_поиска}

ПРИМЕРЫ РЕЛЕВАНТНОГО:
- Документ X: [краткое описание] — релевантен, потому что [почему]
- Документ Y: [краткое описание] — НЕ релевантен, потому что [почему]

Ищи по СМЫСЛУ, ориентируясь на примеры выше.

Выдай:
1. Топ-{N} документов
2. Описание каждого
3. Объяснение релевантности с отсылкой к примерам

Эффект: Модель калибрует понимание "релевантности" под твою задачу. Полезно для subjective queries — где релевантность зависит от контекста.

An automatic patent literature retrieval system based on LLM-RAG

Yao Ding, Yuqing Wu, Ziyang Ding

Belarusian State University, Uber Technologies, Stanford University