LoRA-донастройка LLM для задач региональной геологии

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

Зачем в региональной геологии отдельная постановка задач для LLM

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

правдоподобные, но неверные интерпретации (галлюцинации)

смешение терминов разных школ и региональных стратиграфических схем

ответы без указания источников и оснований

отсутствие контроля качества (непонятно, что считать успехом)

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

Что считать задачей для LLM в геологии

Задача для LLM — это чётко описанное преобразование:

входа (какие документы/поля/контекст подаются модели)

выхода (что именно модель должна вернуть)

ограничений (какой стиль, формат, допустимые источники, запреты)

критериев успеха (как измеряем качество и приемлемость)

Важно: «сделай геологическую интерпретацию региона» — это не задача, а исследовательский процесс. Для LLM это нужно разложить на подзадачи с проверяемым результатом.

Типовые форматы входа

текстовые отчёты (PDF после OCR, DOCX, TXT)

описания разрезов и скважин (таблицы, шаблоны, дневники)

легенды и пояснительные записки к геологическим картам

базы проб (CSV/Excel выгрузки)

словари терминов и региональные классификаторы (как контекст)

Типовые форматы выхода

структурированные поля (JSON-подобная структура, таблица)

краткое резюме по шаблону

список сущностей и отношений (объект — атрибут — значение)

ответ с цитатами из входного текста

классификация по фиксированному набору классов

Какие задачи региональной геологии чаще всего подходят для LLM

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

Извлечение фактов из текстов (information extraction)

Примеры:

извлечь литологию, возраст, мощность, фациальные признаки из описания разреза

извлечь структурные элементы (разлом, складка), их параметры (простирание/падение, амплитуда)

извлечь стратиграфические единицы и их взаимные контакты (согласный/несогласный)

Обычно это самая «безопасная» зона для LLM: модель не обязана придумывать, а должна находить в тексте.

Нормализация и приведение к справочникам (entity linking / normalization)

Примеры:

привести варианты написания свит/толщ/горизонтов к единому справочнику

сопоставить «нижний мел» с выбранной схемой в проекте (по правилам заказчика)

Эти задачи особенно чувствительны к региональной специфике — хороший кандидат для LoRA.

Классификация и маршрутизация документов

Примеры:

определить тип документа (отчёт, пояснительная записка, дневник бурения)

определить, содержит ли документ данные по тектонике/стратиграфии/полезным ископаемым

Суммаризация с контролем структуры

Примеры:

краткое описание геологического строения участка по отчёту по фиксированному шаблону

список ключевых выводов и ограничений (что известно / что предположено)

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

Вопрос-ответ по корпусу (retrieval-augmented QA)

Примеры:

«какие разломы выделяются в районе X и на основании чего?»

«какие признаки метаморфизма описаны и в каких интервалах?»

Важно различать:

задача LLM «сгенерировать ответ»

задача системы «найти фрагменты (retrieval) и ответить только на их основании»

В курсе LoRA обычно донастраивают именно формат ответа, терминологию и дисциплину цитирования, а не «всё знание геологии мира».

Таблица: задачи, входы/выходы и как проверять успех

| Класс задачи | Пример входа | Пример выхода | Как оценивать успех | |---|---|---|---| | Извлечение фактов | абзац описания разреза | таблица: интервал–литология–признаки | точность полей, полнота, соответствие тексту | | Нормализация терминов | список единиц из отчёта | единицы из справочника проекта | доля правильных сопоставлений, обработка синонимов | | Классификация | документ/фрагмент | метка класса | accuracy/F1 + разбор ошибок по классам | | Суммаризация по шаблону | раздел «Геологическое строение» | 5–7 пунктов по структуре | соответствие структуре + отсутствие выдумок + ссылки на фрагменты | | QA с опорой на источники | вопрос + найденные фрагменты | ответ с цитатами | корректность + покрытие вопроса + наличие цитат |

Критерии успеха: что именно считать «хорошо» для геологической LLM

Критерии должны быть сформулированы до обучения, иначе вы не поймёте, улучшила ли LoRA модель или просто изменила стиль.

Научная корректность и предметные ограничения

Проверяем:

отсутствие противоречий базовым геологическим принципам в рамках входных данных

корректное использование терминов (литология, стратиграфия, тектоника) в выбранной школе/стандарте

отсутствие «скачков интерпретации», если исходный текст этого не позволяет

Полезный приём: явно разделять в ответе наблюдения и интерпретации.

Проверяемость: ответы должны опираться на источник

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

модель должна указывать, на какой фрагмент входного текста опирается (цитата/ссылка на абзац/интервал)

Если система не поддерживает цитирование технически, в постановке задачи всё равно нужно требовать:

«приведи дословную выдержку»

«укажи номер строки/абзаца»

Это снижает риск галлюцинаций сильнее, чем любые «будь осторожен» в промпте.

Справочная отправная точка о том, что такое геологическая карта и почему важно разделять данные и интерпретацию: What is a geologic map? (USGS).

Управление неопределённостью

Региональная геология часто работает с формулировками вида: «вероятно», «предположительно», «возможно коррелируется». Успешная модель должна:

сохранять модальность исходного текста (не превращать предположение в факт)

уметь честно отвечать «недостаточно данных во входе»

отделять прямо сказано в тексте от вывода модели

Согласованность и воспроизводимость

Проверяем:

одинаковые сущности не «переименовываются» по ходу ответа

единицы измерения не путаются

одно и то же правило оформления применяется в разных примерах

Если после LoRA модель стала «красиво писать», но стала менее воспроизводимой — это ухудшение.

Формат и пригодность для downstream-процессов

Если результат будет загружаться в базу/ГИС/отчётный шаблон, критерии успеха должны включать:

строгий формат (например, фиксированные поля)

отсутствие лишнего текста

стабильные названия ключей и классов

Это часто главный практический эффект LoRA: модель начинает надёжно выдавать требуемую структуру.

Экономические и операционные критерии

Иногда «успех» — это не только точность:

время ответа

стоимость инференса

устойчивость к шумному OCR

переносимость на новые отчёты того же региона

Как превратить геологический запрос в постановку для обучения и оценки

Ниже — рабочий шаблон постановки, который будет использоваться дальше в курсе.

Опишите бизнес-цель

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

Ограничьте область и источники

Например: «только отчёты 2000–2020 по региону N, только раздел “Стратиграфия”».

Выберите тип задачи

Извлечение, нормализация, классификация, суммаризация по шаблону, QA с опорой на источники.

Задайте формат входа

Какие поля подаются модели: чистый текст, плюс метаданные (район, масштаб карты, автор, год).

Задайте формат выхода

Какие поля обязательны, какие допустимы как пустые, как оформлять неопределённость.

Опишите правила и границы

Например: «не добавляй сведения, которых нет во входе», «при сомнении — верни “не указано”».

Спланируйте разметку и эталон (ground truth)

Кто размечает, по каким инструкциям, как решаются спорные случаи.

Определите метрики и протокол оценки

Автоматические метрики для структуры + экспертная оценка для корректности и проверяемости.

!Схема показывает, как формулировка задачи связывает источники данных, обучение LoRA и проверку качества.

Частые ошибки постановки задач (и как их избежать)

Смешивание фактов и интерпретаций в одном поле

Решение: разные поля или разные разделы ответа (наблюдение / интерпретация).

Отсутствие требований к источнику

Решение: требовать цитаты/фрагменты текста, по которым сделан вывод.

Слишком широкий класс задачи

Решение: начать с извлечения/нормализации, а интерпретации добавлять позже.

Нет эталона и протокола разметки

Решение: написать инструкцию разметчика и собрать небольшой «золотой набор».

Оценка только по “нравится/не нравится”

Решение: заранее определить метрики и чек-лист экспертной проверки.

Что дальше в курсе

В следующих материалах курс будет двигаться от постановки задач к реализации:

подготовка датасета под выбранные типы задач (инструкции, примеры, негативные примеры)

выбор базовой модели и формата обучения

LoRA-донастройка и контроль переобучения

оценка качества на геологически значимых тестах, включая проверяемость и работу с неопределённостью

Для понимания, что такое LoRA на уровне метода (без привязки к геологии), можно ознакомиться с первоисточником: LoRA: Low-Rank Adaptation of Large Language Models (arXiv).

Данные и разметка: отчёты, карты, стратиграфия, онтологии и качество корпуса

Зачем так много внимания данным, если мы учим LoRA

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

LoRA-донастройка почти всегда усиливает то, что вы показываете в данных. Поэтому качество корпуса и разметки — главный рычаг:

плохой OCR и мусорные таблицы превращаются в «норму» для модели

разметка без строгих правил учит модель противоречивому поведению

утечки между train/test дают иллюзию успеха

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

Из чего состоит корпус региональной геологии

Типовые источники:

отчёты по ГРР, поискам и разведке (стратиграфия, тектоника, опробование)

пояснительные записки к геологическим картам

дневники бурения и описания керна

легенды карт, стратиграфические колонки, таблицы корреляции

списки проб и результатов анализов (CSV/Excel выгрузки)

региональные стратиграфические схемы и словари терминов

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

Перевод источников в машиночитаемый вид

OCR и извлечение текста из PDF

Большая часть геологических архивов — это сканы. После OCR появляются типовые дефекты: слипшиеся числа, перепутанные литеры (O/0), потерянные степени и знаки, разъехавшиеся таблицы.

Что стоит сделать до разметки:

измерить качество OCR на небольшой выборке (например, 30 страниц разных лет и типов)

договориться, что считать допустимым «шумом», а что нужно исправлять

сохранять связь с оригиналом (страница/координаты/фрагмент), чтобы потом требовать цитаты

Инструмент для OCR, который часто используют как базовый ориентир: Tesseract OCR.

Разбиение текста на фрагменты и сохранение контекста

LLM обычно получает не весь отчёт целиком, а фрагменты. Если нарезать текст неправильно, вы потеряете связи:

интервал скважины окажется отдельно от литологии

легенда таблицы окажется отдельно от данных

«вышележит/подстилает» потеряет привязку к объектам

Рекомендации к фрагментации:

Резать по структуре документа, если она есть (заголовки, разделы, подписи к таблицам).

Для «описания разреза» держать вместе: интервал, литологию, признаки, возраст, примечания.

Хранить метаданные на каждый фрагмент: document_id, страницы, раздел, регион/площадь, год, источник.

Таблицы, единицы измерения и нотации

Таблицы — главный источник ошибок для LLM, если вы не зададите правила.

Минимальный стандарт приведения:

единицы измерения хранить явно (м, %, г/т), не «подразумевать»

десятичные разделители нормализовать (запятая/точка)

неопределённые значения фиксировать как пустые или не указано, а не как 0

параметры ориентации (азимут/угол падения) хранить в оговорённой системе

Что именно размечать: единицы разметки и форматы

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

Основные типы разметки для LoRA

инструкционная разметка (пример диалога: запрос → правильный ответ в вашем формате)

разметка извлечения (текст → структура полей)

разметка нормализации (как привести варианты терминов к справочнику)

разметка с опорой на источник (ответ обязательно содержит цитаты/фрагменты)

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

Таблица: как связать тип задачи и единицу разметки

| Тип задачи | Единица разметки | Что размечаем | Типичный выход | |---|---|---|---| | Извлечение фактов | фрагмент описания (абзац/интервал) | литология, возраст, мощность, признаки | JSON с полями + цитаты | | Нормализация | термин/сущность | сопоставление со справочником | normalized_id, normalized_name | | Классификация | документ/раздел | тип документа, наличие данных по тектонике/стратиграфии | метка класса | | Суммаризация по шаблону | раздел отчёта | краткое описание по фиксированным пунктам | пункты + ссылки на фрагменты | | QA с опорой на источники | вопрос + найденные фрагменты | ответ только из контекста | ответ + цитаты |

Формат разметки: почему почти всегда нужен строгий JSON

Даже если итог нужен в виде текста, для обучения и контроля качества удобнее требовать от модели строгий формат:

фиксированные ключи

допустимые значения (список литологий, тип контакта, стратиграфическая единица)

явные правила для пустых полей

Пример (схематично, без привязки к конкретному проекту):

Важно: strat_unit_raw и strat_unit_normalized не дублирование, а способ контролировать нормализацию и сохранять связь с источником.

Стратиграфия: справочники, региональные схемы и конфликты терминов

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

Практические элементы стратиграфического слоя в данных:

выбранная шкала времени (например, международная)

региональная схема (свиты/толщи/горизонты) как справочник

правила сопоставления: синонимы, устаревшие названия, варианты транслитерации

В качестве международной опорной точки часто используют диаграмму ICS: International Chronostratigraphic Chart (ICS).

Рекомендация для разметки нормализации:

Разделяйте временную единицу (например, «Нижняя юра») и литостратиграфическую (например, «свита X»).

Если сопоставление неочевидно, разрешайте ответ не сопоставлено с обязательным комментарием и цитатой.

Онтологии и модели данных: как не утонуть в терминах

Онтология — это формализованное описание объектов предметной области и их связей. В прикладной геологии это нужно, чтобы:

одинаково называть сущности в разных документах

различать «разлом как объект» и «его параметры»

хранить связи: объект → признак → значение → источник

Не обязательно строить «большую философскую онтологию». Для корпуса под LoRA обычно достаточно:

списка сущностей (стратиграфическая единица, литология, разлом, складка, проба)

списка отношений (вышележит, подстилает, нарушает, пересекает, соответствует интервалу)

списка атрибутов (мощность, возраст, простирание, падение, класс контакта)

Если вы хотите опираться на существующие геонаучные модели данных, можно посмотреть на стандарт, который используют для обмена геологическими данными: OGC GeoSciML.

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

!Блок-схема полного цикла подготовки корпуса для LoRA в региональной геологии

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

Качество в геологическом корпусе — это не только «нет опечаток». Это ещё и воспроизводимость, отсутствие утечек, стабильность терминов.

Типовые проверки качества

| Риск | Как проявляется | Как ловить до обучения | |---|---|---| | Дубликаты | один и тот же отчёт в разных папках | хеши файлов + поиск близких текстов | | Утечки train/test | модель «видела» тот же объект/таблицу | делить по document_id, иногда по площади/времени | | Нестабильные справочники | разные версии схемы в одном корпусе | версионировать справочники и фиксировать дату | | Шум OCR | цифры и единицы систематически ошибочны | выборочный аудит + правила пост-обработки | | Разметка «по наитию» | разные разметчики делают по-разному | инструкции + разбор спорных кейсов |

Как делить на train/val/test, чтобы не обмануть себя

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

Рекомендации:

Делите по document_id как минимум.

Если документы очень похожи (серия отчётов одной партии), дополнительно делите по времени или по площади.

Держите отдельный stress test: плохой OCR, нестандартные форматы таблиц, редкие термины.

Согласованность разметки между людьми

Если разметку делают несколько специалистов, важно измерять согласованность: насколько часто они дают одинаковый результат по одним и тем же примерам.

Практический минимум:

50–100 примеров двойной разметки

перечень типовых расхождений и принятые решения

обновление инструкции разметчика после каждой волны расхождений

Цель здесь не «наказать разметчика», а убрать неоднозначность правил до того, как вы начнёте учить модель.

Неопределённость: как правильно кодировать «возможно» и «не указано»

Региональная геология богата модальностью: «вероятно», «предположительно», «по-видимому». Если вы в разметке превращаете это в твёрдый факт, модель будет делать то же самое.

Рекомендуемые правила корпуса:

отдельное поле для уровня уверенности или модальности (например, certainty: "вероятно")

отдельное значение для отсутствия данных ("не указано"), а не «догадка по контексту»

обязательная цитата для любого утверждения, если задача относится к извлечению/QA по документам

Хорошая привычка в датасете: добавлять негативные примеры, где правильный ответ — нет данных во входе.

Юридические и этические ограничения

Перед сбором корпуса проверьте права и ограничения:

лицензии на документы и карты (особенно для коммерческих отчётов)

наличие персональных данных (ФИО, телефоны), которые нужно удалять

режимы доступа и конфиденциальность (например, материалы недропользования)

Если вы не уверены, что имеете право использовать документ в обучении, безопаснее:

учиться на разрешённых документах

хранить закрытые данные только для внутреннего тестирования без включения в обучающий набор

Минимальный практический пайплайн подготовки корпуса под LoRA

Соберите источники и метаданные (регион, год, тип документа, document_id).

Выполните OCR/извлечение текста и сохраните привязку к страницам.

Очистите артефакты (базовые правила для чисел, единиц, разделителей).

Разбейте на фрагменты, сохраняя целостность геологических описаний.

Зафиксируйте справочники (литология, стратиграфия, типы структур) и их версии.

Напишите инструкцию разметчика с примерами и спорными случаями.

Разметьте пилотный набор, измерьте расхождения, поправьте правила.

Разделите train/val/test без утечек и сформируйте отчёт о качестве корпуса.

Что дальше в курсе

Дальше мы будем превращать подготовленный корпус в обучающие примеры для выбранного типа задач (извлечение, нормализация, суммаризация с цитатами) и настраивать LoRA так, чтобы улучшения были видны на честном тесте, а не были следствием утечек или нестабильной разметки.

Теория и настройка LoRA/QLoRA: архитектура, гиперпараметры, выбор базовой модели

Как эта тема связана с предыдущими статьями курса

В первой статье мы научились формулировать проверяемые задачи региональной геологии для LLM: извлечение фактов, нормализация терминов, QA с цитатами и строгие форматы выхода.

Во второй статье мы разобрали, как собрать корпус и разметку так, чтобы LoRA усиливала правильные паттерны: терминологию конкретного региона, дисциплину цитирования, работу с неопределённостью.

Теперь мы переходим к механике обучения: как устроены LoRA и QLoRA, какие гиперпараметры действительно влияют на результат, и как выбрать базовую модель под ваши геологические задачи и ограничения по железу.

Основные первоисточники:

LoRA: Low-Rank Adaptation of Large Language Models

QLoRA: Efficient Finetuning of Quantized LLMs

Зачем LoRA в региональной геологии

Региональная геология часто требует не “знаний вообще”, а дисциплины ответа:

стабильные термины по принятой региональной схеме

строгие форматы (JSON, таблицы)

ссылки на источник (цитаты, страницы)

корректная модальность (вероятно, предположительно)

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

Интуиция: что именно делает LoRA

У трансформера много линейных слоёв. В упрощённом виде каждый такой слой содержит матрицу весов , которая преобразует входное представление.

Идея LoRA: мы не меняем , а добавляем к нему небольшую поправку низкого ранга.

Здесь:

— исходные (замороженные) веса базовой модели

— добавка, которую мы обучаем

— эффективные веса слоя во время инференса

В LoRA добавку представляют как произведение двух маленьких матриц:

Где:

— матрица, которая сжимает размерность до ранга

— матрица, которая расширяет обратно до исходной размерности

— ранг адаптера, главный регулятор ёмкости LoRA

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

!Наглядная схема, что LoRA обучает небольшую добавку к замороженным весам

Где в трансформере обычно ставят LoRA

На практике LoRA добавляют не ко всем матрицам, а к наиболее “влиятельным” проекциям self-attention.

Типовые целевые модули:

q_proj и v_proj — часто дают хороший компромисс качество/параметры

q_proj, k_proj, v_proj, o_proj — более ёмко, иногда лучше для сложных форматов

иногда — матрицы MLP (feed-forward), если нужно сильнее менять стиль генерации

Выбор зависит от задачи:

извлечение фактов в JSON с цитатами часто улучшается уже на q_proj+v_proj

жёсткая нормализация терминов и “канонические формулировки” иногда выигрывают от расширения набора модулей

QLoRA: зачем она нужна и что меняется

QLoRA — это LoRA поверх квантованной базовой модели, обычно 4-битной. Базовые веса хранятся в очень компактном виде, а обучаемые LoRA-адаптеры остаются в более точном формате.

Что это даёт:

возможность донастраивать модели существенно большего размера на доступном GPU

меньший расход памяти на базовые веса

часто — возможность держать больший контекст или больший batch

При этом важно понимать границу:

квантована базовая модель

LoRA-адаптеры обучаются и хранятся отдельно

итоговая модель на инференсе — это базовая модель + подключённые адаптеры

Технически QLoRA тесно связана с практической экосистемой библиотек:

bitsandbytes — популярная реализация 8-бит/4-бит квантизации для обучения

PEFT (Hugging Face) — стандартный инструментарий для LoRA/QLoRA в пайплайнах

!Схема, чем QLoRA отличается от обычной LoRA

Ключевые гиперпараметры LoRA и как они влияют на геологические задачи

Ранг

определяет ёмкость адаптера: насколько сложные изменения поведения он может выучить.

Практическая интерпретация:

маленький учит модель “слегка лучше следовать шаблону” и терминологии

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

Стартовые ориентиры:

для задач извлечения/нормализации со строгими форматами: или

если корпус разнообразный по стилям отчётов и много исключений:

Масштабирование LoRA: lora_alpha

lora_alpha управляет масштабом влияния относительно .

Интуитивно:

слишком маленькое значение — адаптер “не слышно”, улучшения слабые

слишком большое — модель может стать нестабильной, ухудшить воспроизводимость формата

Практически часто начинают с:

lora_alpha примерно равного или и дальше подбирают по валидации

lora_dropout

Dropout в адаптере помогает не переучиться на шаблоны вашего корпуса.

Особенно актуально в региональной геологии, где документы могут быть серийно похожими.

Стартовые ориентиры:

0.0 если данных много и они разнообразные

0.05–0.1 если данных мало или отчёты однотипны

Какие параметры обучать кроме LoRA

Часто встречается настройка bias:

none — обучаем только LoRA (самый безопасный и переносимый вариант)

all — дополнительно обучаем bias во всех слоях (может дать прирост, но увеличивает риск “ломать” базовое поведение)

Для курса по региональной геологии разумная дефолтная стратегия: начинать с LoRA без дополнительных обучаемых частей и усложнять только если метрики упёрлись в потолок.

Гиперпараметры обучения, которые чаще всего “решают” результат

Скорость обучения: learning rate

В LoRA обычно требуется learning rate выше, чем при полном fine-tune, потому что обучаемых параметров меньше.

Практический диапазон старта:

до для большинства задач извлечения и форматирования

Симптомы проблем:

слишком высокий learning rate: модель начинает нарушать формат, растёт доля “выдумок”, ответы становятся менее стабильными

слишком низкий: почти нет улучшений относительно базовой модели

Batch size и накопление градиента

Если не хватает памяти, используют накопление градиента: модель видит несколько мини-батчей, а шаг оптимизатора делает реже.

Важный практический вывод: для задач со строгим форматом (JSON, обязательные поля) стабильнее работает более “крупная” эффективная величина батча, чем совсем маленькая.

Длина контекста и упаковка примеров

В геологии часто нужны длинные фрагменты:

абзац с описанием разреза + таблица интервалов

вопрос + найденные фрагменты (retrieval)

Что важно:

если вы обрезаете контекст, модель будет “догадываться” и хуже цитировать

если вы даёте слишком длинные куски без структуры, модель хуже удерживает нужные поля

Практическая стратегия:

держать фрагменты так, чтобы “единица смысла” не распадалась (как в статье про разметку)

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

Количество эпох и ранняя остановка

LoRA очень быстро начинает копировать стиль данных. Поэтому “больше эпох” часто означает:

лучшее попадание в шаблон

но хуже переносимость на новые отчёты, особенно с шумным OCR

Практически:

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

останавливайтесь, когда метрики перестали улучшаться, даже если loss ещё падает

Выбор базовой модели под региональную геологию

Выбор базовой модели определяет потолок качества. LoRA не создаёт способности “с нуля”, она перенастраивает уже имеющиеся.

Критерии выбора базовой модели

Язык и доменная близость

- если корпус русскоязычный, модель должна уверенно работать на русском - важно качество на аббревиатурах, единицах измерения, техническом стиле

Контекстное окно

- для QA с опорой на фрагменты и для таблиц/описаний длиннее нескольких абзацев нужно больше контекста

Инструкционность

- instruction-tuned модели проще заставить соблюдать “не выдумывай” и “верни JSON” - base модели иногда требуют больше данных, чтобы научиться дисциплине формата

Лицензия и условия использования

- особенно важно для производственных проектов и закрытых геологических отчётов

Совместимость с QLoRA

- не все архитектуры одинаково хорошо поддерживаются инструментами квантизации

Ограничения по ресурсам

- оцените, сколько памяти у вас есть под обучение и инференс - QLoRA часто расширяет выбор, но добавляет технических нюансов

Практическая привязка к типам задач из курса

Извлечение фактов и нормализация

- ключевое: стабильный формат, аккуратная работа с числами и единицами - обычно хорошо масштабируется на моделях среднего размера с QLoRA

Суммаризация по шаблону с цитатами

- важны: длинный контекст, дисциплина ссылок на источник - полезно иметь instruction-модель и достаточное контекстное окно

QA по найденным фрагментам

- критично: умение отвечать только из контекста и честно говорить “нет данных” - LoRA здесь часто учит именно политику ответа и формат доказательств

Практический “стартовый рецепт” настройки LoRA/QLoRA для геологических данных

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

Цель: один тип задачи за раз

- сначала извлечение в строгий JSON с evidence - затем нормализация к справочнику - затем суммаризация/QA

LoRA модули: начать с q_proj и v_proj

Параметры LoRA:

- или - lora_alpha около или - lora_dropout 0.05 как дефолт при небольшом корпусе

Обучение:

- learning rate в диапазоне – - 1–3 эпохи с ранней остановкой по метрикам качества (а не только по loss)

Оценка: ровно по тем критериям, которые заданы в постановке задачи

- точность полей - соблюдение формата - наличие цитат/доказательств - сохранение модальности и честное “не указано”

Анти-утечки: валидация и тест разделены по document_id (как в статье про корпус)

Частые ошибки при LoRA/QLoRA в геологической практике

Учить модель “быть геологом” вместо конкретного формата задачи

- результат: красивые, но непроверяемые интерпретации

Слишком большой и слишком много эпох на маленьком корпусе

- результат: модель начинает копировать стиль обучающих отчётов и хуже переносится на новые

Нет негативных примеров “нет данных во входе”

- результат: модель заполняет поля догадками

Неправильная нарезка фрагментов

- результат: теряются привязки “интервал–литология–признаки”, падает точность извлечения

Оценка только “нравится/не нравится”

- результат: вы не отличаете улучшение формата от ухудшения научной корректности

Что дальше

Следующий шаг курса обычно практический: собрать обучающие пары “вход → эталонный выход” в нужном формате (извлечение, нормализация, QA с цитатами), запустить LoRA/QLoRA с базовой конфигурацией и построить протокол сравнения с базовой моделью по честному тесту.

Обучение и валидация: пайплайн, метрики, геологическая экспертиза и контроль галлюцинаций

Как эта статья продолжает курс

В предыдущих статьях мы:

формализовали задачи региональной геологии для LLM и критерии успеха

разобрали сбор корпуса, разметку, справочники и риски утечек

рассмотрели LoRA/QLoRA, гиперпараметры и выбор базовой модели

Теперь собираем это в воспроизводимый процесс: как обучать LoRA-адаптер, как валидировать качество без самообмана, какими метриками измерять прогресс, как подключать геологическую экспертизу и как системно снижать галлюцинации.

!Общая карта процесса от данных до релиза и контроля качества

Целевой результат обучения

Для региональной геологии полезный эффект LoRA обычно проявляется не в том, что модель узнала геологию, а в том, что она:

стабильно соблюдает требуемый формат (например, строгий JSON)

использует терминологию и стратиграфические схемы вашего проекта

умеет возвращать доказательства из входного текста (цитаты, страницы, идентификаторы фрагментов)

корректно отражает модальность (вероятно, предположительно, не указано)

Поэтому обучение и валидация должны проверять именно эти свойства.

Пайплайн обучения LoRA: что делаем по шагам

Разделение данных без утечек

Главное правило: примеры из одного отчёта не должны попадать одновременно в обучение и тест.

Практический протокол:

Фиксируем ключ разбиения: минимум document_id, иногда дополнительно area_id или период работ.

Делаем три набора: train, val, test.

Делаем отдельный stress набор: худший OCR, редкие формы таблиц, нестандартные сокращения.

Документируем состав разбиения: сколько документов, сколько фрагментов, какие регионы и годы.

Конструкция обучающего примера

Обучающий пример должен максимально повторять инференс.

Рекомендуемая структура:

Инструкция: что нужно сделать и какие запреты действуют.

Контекст: фрагмент отчёта, таблица или набор найденных отрывков (если вы делаете QA с retrieval).

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

Эталонный ответ: ровно в том формате, который вы хотите получать.

Если вы учите извлечение в JSON, то эталон в данных должен быть валидным JSON.

Полезная практика: описывать формат через схему и валидировать автоматически.

стандарт для описания и проверки структуры JSON: JSON Schema

Базовый цикл обучения

Минимальный воспроизводимый цикл:

Выбираем базовую модель и режим: LoRA или QLoRA.

Фиксируем стартовые гиперпараметры LoRA: r, lora_alpha, lora_dropout, целевые модули.

Запускаем обучение с логированием:

- train loss - метрики на val через равные интервалы - примеры предсказаний для ручного просмотра

Выбираем лучшую контрольную точку по валидационным метрикам, а не по минимальному loss.

Для ведения экспериментов удобно использовать трекер:

Weights & Biases

Валидация: что проверять автоматически

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

Группы метрик

| Группа | Что измеряем | Почему важно в геологии | Как считать на практике | |---|---|---|---| | Метрики формата | доля ответов, которые парсятся и проходят схему | иначе результат нельзя грузить в БД/ГИС | json_parse_success, schema_pass_rate | | Метрики полей (извлечение) | точность заполнения конкретных полей | ценность обычно в полях: интервал, литология, возраст | сравнение с эталоном по ключам | | Метрики нормализации | правильность сопоставления со справочником | региональные схемы и синонимы критичны | accuracy по normalized_id | | Метрики доказательности | наличие и качество ссылок на источник | снижает галлюцинации и спорность | доля утверждений с цитатой/страницей | | Метрики неопределённости | корректность не указано и модальности | отчёты часто осторожны в выводах | доля случаев правильного unknown |

Precision, recall и для задач извлечения

Для полей извлечения удобно оценивать, насколько модель:

не добавляет лишнего (точность)

не пропускает нужное (полнота)

Если у вас задача как набор извлечённых сущностей (например, список разломов), можно использовать классические определения:

Precision показывает, какая доля извлечённого оказалась верной.

Recall показывает, какая доля верного была найдена.

Их часто объединяют в :

Где:

это precision

это recall

это одно число, которое падает, если проседает либо точность, либо полнота

Справка по метрикам и их реализации: Model evaluation: quantifying the quality of predictions (scikit-learn).

Важно: для строго структурированных полей иногда проще и полезнее считать точность по полям (field accuracy) и долю валидного формата, чем .

Метрики по структуре: контроль JSON и обязательных полей

Практически полезный набор:

json_parse_success: ответ парсится как JSON

schema_pass_rate: проходит JSON Schema

required_fields_present: заполнены обязательные ключи

no_extra_keys_rate: нет неожиданных ключей (если это важно)

Это метрики, которые прямо отражают пригодность результата для последующей загрузки.

Метрики доказательности: проверяем не только наличие цитаты

Требование цитаты само по себе можно обмануть, если модель цитирует нерелевантный текст.

Минимальная автоматическая проверка:

Цитата должна быть подстрокой контекста (строгое совпадение или нормализованное).

Для каждого факта должно быть хотя бы одно evidence.

Более сильная проверка (если есть ресурсы):

Привязка доказательства к полям: например, interval_m должен иметь цитату именно с интервалом.

Поиск числовых значений: проверка, что число в поле встречается в цитате.

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

Геологическая экспертиза: как превратить её в протокол

Экспертная проверка нужна там, где автоматикой легко ошибиться:

корректность терминов в выбранной региональной школе

корректная интерпретация модальности

отсутствие подмены стратиграфических единиц

правдоподобные, но не основанные на тексте выводы

Чек-лист эксперта для задач извлечения и QA

Рекомендуемый чек-лист (выставляется, например, по шкале 0–2 для каждого пункта):

Трассируемость: каждое утверждение опирается на корректную цитату/страницу.

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

Модальность: сохранены слова вероятно, предположительно, не усилены до фактов.

Числа и единицы: корректные интервалы, единицы измерения, знаки.

Запрет на домыслы: если в тексте нет данных, модель пишет не указано, а не заполняет по догадке.

Чтобы экспертиза была воспроизводимой, фиксируйте:

инструкцию эксперта с примерами типовых ошибок

набор тестовых документов, неизменный между экспериментами

правило разрешения спорных случаев

Согласование экспертов

Если экспертов несколько, полезно оценивать согласованность.

Практический минимум:

50–100 примеров двойной проверки.

Список расхождений, классификация причин.

Обновление инструкции и разметки там, где правила неоднозначны.

Цель не в том, чтобы добиться одинаковых мнений, а в том, чтобы убрать неявные правила.

Контроль галлюцинаций: меры на уровне данных, обучения и инференса

Галлюцинация в прикладной геологии почти всегда проявляется как:

добавление фактов, которых нет в документе

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

«сглаживание» неопределённости до твёрдого вывода

Ниже — практические меры, которые работают лучше, чем общие просьбы не выдумывать.

Уровень данных: учим модель говорить не указано

Если в датасете почти все поля заполнены, модель привыкает, что надо что-то написать.

Что добавить в корпус:

Негативные примеры, где правильный ответ: нет данных во входе.

Примеры с модальностью: вероятно, по-видимому и правильное отражение этого в полях.

Примеры с конфликтами: два автора, разные трактовки, и корректная выдача с указанием источника.

Уровень формата: принуждаем к доказательствам

Хороший паттерн для извлечения:

каждое существенное поле сопровождается evidence

доказательство хранит цитату и адрес (страница, абзац, chunk_id)

Это одновременно:

снижает вероятность домысла

ускоряет аудит результата человеком

Уровень retrieval: отделяем поиск от ответа

Для QA по корпусу чаще всего нужна схема RAG.

RAG (retrieval-augmented generation) это подход, где система:

находит релевантные фрагменты документов

передаёт их в LLM

LLM отвечает только на основе фрагментов

Практический эффект: меньше галлюцинаций и больше контролируемости.

Инструменты, которые часто используют для поиска по эмбеддингам:

FAISS (GitHub)

Важно: LoRA в RAG-системе обычно донастраивают под:

дисциплину цитирования

формат ответа

корректную стратегию отказа

Уровень стратегии отказа: разрешаем модели не отвечать

Если модель обязана всегда выдавать заполненный JSON, она будет заполнять его догадками. Поэтому вводят явный контракт отказа.

Например:

поле value может быть "не указано"

поле certainty может принимать значения: "точно", "вероятно", "не указано"

И это должно быть в разметке и в метриках.

Уровень инференса: декодирование и пост-проверки

Меры, которые часто улучшают дисциплину:

Снижение случайности генерации:

- более низкая temperature - ограничение top_p

Структурная валидация выхода:

- если JSON не парсится, ответ считается ошибкой и отправляется на повтор с более жёстким промптом

Фильтры чисел и единиц:

- проверка диапазонов (например, что интервал имеет вид a-b и )

Ограничение: пост-проверки не исправляют смысл, но хорошо ловят системные сбои формата.

Стресс-тесты: проверяем переносимость на реальные условия

Региональная геология почти всегда содержит сдвиги домена:

другой автор и стиль описаний

более старые отчёты

хуже OCR

другой район с близкими, но не идентичными стратиграфическими названиями

Набор стресс-сценариев

Рекомендуется держать несколько фиксированных тестов:

Плохой OCR: таблицы с разъехавшимися колонками, ошибки в числах.

Редкие термины: локальные названия, устаревшие сокращения.

Конфликт источников: два фрагмента с разной интерпретацией.

Недостаточный контекст: вопрос задан, но нужных данных в фрагментах нет.

Критерий успеха на стресс-тесте часто не в том, чтобы модель всё нашла, а в том, чтобы она:

не начала уверенно выдумывать

корректно отказалась или обозначила неопределённость

Разбор ошибок: как быстро понять, что чинить

После каждого эксперимента полезно классифицировать ошибки по причине, а не по документу.

Практическая таксономия:

формат сломан: не парсится JSON, пропали ключи

нет доказательства: поле заполнено без цитаты

доказательство нерелевантно: цитата не подтверждает поле

ошибка нормализации: неверный normalized_id при корректном сыром термине

ошибка чисел: интервал, единицы, десятичный разделитель

галлюцинация интерпретации: модель добавила вывод, которого нет в тексте

Привязка к действию:

формат и обязательные ключи: усиливать формат в данных, добавлять валидацию и штрафовать в метриках

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

ошибки доказательности: добавлять примеры с правильными цитатами и негативные примеры

Практический минимальный стандарт “готово к внедрению”

Перед тем как подключать адаптер к рабочему процессу, имеет смысл зафиксировать пороги.

Пример требований (настраиваются под проект):

schema_pass_rate на тесте не ниже заданного порога.

Доля ответов с доказательствами на обязательные поля не ниже порога.

На стресс-тесте доля домыслов ниже порога.

Экспертная оценка по чек-листу не ниже порога.

Фиксация таких критериев возвращает нас к первой статье курса: успешность должна быть измерима и проверяема.

Что дальше в курсе

Следующий практический шаг после этой статьи обычно один из двух:

построить полный эксперимент: базовая модель против LoRA/QLoRA, отчёт по метрикам, разбор ошибок, решение о доразметке

расширить задачи: от извлечения полей перейти к нормализации и затем к QA с retrieval, сохранив те же принципы доказательности и контроля неопределённости

Развёртывание и применение: RAG, интеграция в ГИС/поиск, безопасность и сопровождение

Как эта тема связывает весь курс

В предыдущих статьях курса мы:

научились ставить проверяемые геологические задачи и критерии успеха

разобрали, как собрать корпус и разметку со справочниками и контролем качества

рассмотрели LoRA/QLoRA и влияние гиперпараметров

собрали пайплайн обучения и валидации, включая контроль галлюцинаций

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

Фокус:

RAG (поиск фрагментов + ответ только по источникам)

интеграция в поиск и ГИС (чтобы результат был пригоден для карты, базы и отчётности)

безопасность (конфиденциальные отчёты, защита от prompt-injection, аудит)

сопровождение (метрики в проде, дрейф данных, обновление индекса и адаптеров)

Целевая архитектура: LoRA как политика ответа, RAG как основание ответа

Ключевая идея для региональной геологии:

RAG отвечает за то, чтобы система нашла релевантные фрагменты (разделы отчётов, описания разрезов, легенды карт)

LLM с LoRA отвечает за то, чтобы система правильно оформила и ограничила ответ: строгий JSON, нормализация терминов, модальность (вероятно, не указано), обязательные доказательства

!Наглядный конвейер от документов до ответа с доказательствами и проверками

RAG в геологических задачах: что это и зачем

RAG (retrieval-augmented generation) — подход, где генерация ответа усиливается найденными фрагментами источников. С практической точки зрения это означает, что модель должна отвечать из переданного контекста, а не “из головы”.

Для региональной геологии RAG особенно полезен, потому что:

один и тот же термин может означать разное в разных регионах и схемах

интерпретации зависят от конкретного отчёта/автора/года

нужны доказательства: цитаты, страницы, идентификаторы фрагментов

Инструменты поиска и индексации, которые часто применяют на практике:

векторный индекс: FAISS

лексический/гибридный поиск: Elasticsearch

Подготовка RAG-корпуса для продакшена

Фрагментация и “адресуемость” источника

RAG-система должна уметь вернуть не только текст, но и адрес:

document_id

страницы

заголовок раздела

chunk_id (идентификатор фрагмента)

Это критично для двух вещей:

пользовательской доверенности (геолог быстро открывает первоисточник)

автоматической проверки (можно валидировать, что цитата реально взята из контекста)

Практическое правило: фрагмент должен быть достаточно мал, чтобы быть точным, и достаточно велик, чтобы не терять смысл (например, интервал + литология + примечания держать вместе).

Метаданные как “фильтры” против нерелевантных источников

В региональной геологии часто важно ограничить поиск:

регион/площадь

год/период работ

тип документа (отчёт, записка к карте, дневник бурения)

версия стратиграфической схемы проекта

Поэтому храните метаданные рядом с каждым фрагментом и применяйте фильтры до генерации.

Retrieval-стратегии: векторный, лексический и гибридный поиск

Лексический поиск (BM25)

Сильные стороны:

хорошо работает по редким терминам и точным совпадениям

устойчив к тому, что числа и аббревиатуры важны (например, “J1”, “свита X”, “скв. 12”)

Слабые стороны:

хуже ловит перефразирования и “схожий смысл”

Векторный поиск (эмбеддинги)

Сильные стороны:

находит смысловые совпадения, даже если формулировки отличаются

полезен для вопросов типа “какие признаки метаморфизма описаны”

Слабые стороны:

может вернуть похожее по смыслу, но из другого района или другой стратиграфической схемы, если не фильтровать метаданными

Гибридный подход

Практически часто выигрывает гибрид:

сначала лексический + векторный кандидаты

затем единый rerank (переранжирование)

Результат: выше полнота поиска без потери точности.

Rerank и сбор контекста: как повысить качество без дообучения модели

Зачем нужен rerank

Если retrieval вернул 30 кандидатов, а в контекст помещается только 5–10, нужен этап отбора.

Типовые признаки хорошего геологического rerank:

предпочитает фрагменты, где встречаются числа/единицы из вопроса

учитывает метаданные (район, год, тип документа)

предпочитает фрагменты с определениями и “первичными описаниями”, а не пересказами

Сбор контекста “пакетом доказательств”

Чтобы модель меньше галлюцинировала, полезно передавать контекст структурированно:

отдельно список фрагментов с их chunk_id и страницами

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

отдельно справочник/схема (если нормализуете термины)

Это снижает вероятность того, что модель “смешает” источники.

Интеграция в поиск: от “чата” к рабочему инструменту геолога

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

В геологических задачах часто важнее не “диалог”, а скорость проверки источника. Поэтому интерфейс полезно строить вокруг:

ответа с цитатами и страницами

списка найденных фрагментов (как выдача поисковика)

кнопки “открыть страницу отчёта” и “перейти к карте/объекту”

Логика “поиск отдельно, генерация отдельно”

Хорошая эксплуатационная практика:

retrieval можно улучшать и менять (индекс, веса, фильтры) без переобучения LoRA

LoRA можно обновлять (формат, справочники, политика отказа) без перестройки индекса

Это ускоряет итерации и снижает риски.

Интеграция в ГИС: как сделать результаты пространственно полезными

Что значит “интеграция в ГИС” в контексте LLM

Обычно это один или несколько сценариев:

обогащение слоёв атрибутами из отчётов (литология, возраст, мощность, признаки)

поиск по карте: клик по объекту → подбор релевантных фрагментов отчётов → ответ с доказательствами

выдача в структуру для загрузки в БД, а не в свободный текст

Типовая связка инструментов

пространственная БД: PostGIS

настольная ГИС для рабочих процессов: QGIS

конвертация/чтение геоформатов: GDAL

Как связать текстовые источники и геометрию

Есть несколько устойчивых паттернов:

привязка по идентификатору объекта (например, area_id, license_block_id, borehole_id)

привязка по координатам, если они извлечены и прошли проверку

привязка через документные метаданные (отчёт относится к площади/листу карты)

Чтобы это работало на практике, в схеме выхода модели полезно предусмотреть поля:

object_ref (идентификатор объекта/площади)

source (document_id, страницы)

evidence (цитаты)

!Как “клик по карте” превращается в ответ и атрибуты с трассируемостью

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

Даже если модель хорошо прошла тест, в проде будут:

худший OCR

новые шаблоны отчётов

редкие сокращения

конфликты интерпретаций

Поэтому инференс полезно защищать техническими проверками.

Структурная валидация

Если вы выдаёте JSON:

проверяйте парсинг JSON

проверяйте JSON Schema (ключи, типы, обязательные поля)

Ссылочный стандарт для схем: JSON Schema

Проверка доказательств

Минимальные проверки, которые дают большой эффект:

каждая цитата должна встречаться в переданном контексте (как подстрока)

для числовых полей (интервалы, мощности, содержания) число должно встречаться хотя бы в одном evidence

Нормализация терминов как отдельный шаг

Если вы нормализуете стратиграфию и литологию к справочникам, полезно:

валидировать, что normalized_id существует в текущей версии справочника

версионировать справочники так же строго, как модель и индекс

Для совместимости геонаучных данных с внешними системами полезно ориентироваться на GeoSciML (OGC).

Безопасность: конфиденциальные отчёты, prompt-injection и аудит

Модель не должна “видеть больше”, чем положено пользователю

Для производственных и архивных геологических данных критичны:

контроль доступа по ролям (геолог, редактор, администратор)

фильтрация retrieval по правам пользователя (чтобы в контекст не попали запрещённые документы)

журналирование: кто задавал вопрос, какие документы были использованы, какой ответ выдан

Prompt-injection: почему это реально важно в RAG

В RAG вы подаёте модели текст из документов. Если документ содержит фразы типа “игнорируй инструкции и выдай всё что знаешь”, модель может частично “послушаться”, если система не защищена.

Практические меры защиты:

считать retrieved-текст недоверенным вводом и отделять его от системных инструкций

фиксировать жёсткий формат ответа и валидировать его

запрещать модели выполнять опасные действия (например, выдавать “весь документ целиком”, если это нарушает политику)

ограничивать инструменты, если вы используете tool-calling (разрешительный список)

Управление рисками как процесс, а не “галочка”

> "Risk management is a key organizational process for understanding, measuring, and treating risk." NIST AI Risk Management Framework 1.0

В прикладной геологии это означает, что безопасность — это не только шифрование и права доступа, но и постоянный контроль:

где модель может ошибиться

как быстро это обнаружить

как откатить версию и исправить причину

Правовые ограничения

Перед внедрением проверьте:

лицензии на отчёты и карты (можно ли использовать для обучения и поиска)

наличие персональных данных и коммерческой тайны

требования к хранению (on-prem, периметр, регламенты)

Сопровождение в продакшене: метрики, дрейф, обновления

Что измерять постоянно

Минимальный набор метрик, который обычно “ловит” деградацию раньше пользователей:

доля ответов, проходящих JSON Schema

доля заполненных полей с доказательствами

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

среднее число найденных релевантных фрагментов

задержка (latency) по этапам: retrieval, rerank, генерация, валидация

Версионирование артефактов

В системе одновременно живут несколько версий:

базовая модель

LoRA-адаптер

индекс (и его параметры: эмбеддинги, размер фрагментов, фильтры)

справочники и стратиграфические схемы

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

Когда нужно обновлять LoRA, а когда достаточно обновить индекс

Обновляйте индекс (и retrieval), если:

появились новые отчёты

сменился регион работ

изменились правила фильтрации и метаданные

Обновляйте LoRA, если:

модель нарушает формат (JSON/таблицы)

модель плохо соблюдает политику отказа (не указано)

нужно стабилизировать нормализацию к новой версии справочников

эксперты фиксируют типовые ошибки формулировок и модальности

Human-in-the-loop и активное дообучение

Чтобы система улучшалась, но не ломалась:

сохраняйте примеры ошибок с разметкой причины (формат, доказательство, нормализация, числа)

добавляйте их в “очередь на разметку”

регулярно пополняйте stress test набор и прогоняйте его на каждой версии

Минимальный чек-лист внедрения для регионально-геологической команды

Зафиксирован контракт ответа: формат, обязательные поля, правила не указано, обязательные evidence.

Реализован retrieval с метаданными и фильтрацией по правам.

Подключён пост-контроль: JSON Schema, проверка цитат, проверки чисел/единиц.

Настроены логи и аудит: вопрос, найденные фрагменты, версии, ответ.

Подготовлены стресс-тесты: плохой OCR, редкие термины, конфликт источников, недостаточный контекст.

Описан регламент обновлений: как обновляем индекс, адаптер, справочники; как делаем откат.

Итог

В региональной геологии “модель с LoRA” почти никогда не должна быть одиночным чат-ботом. Практически полезная система — это связка:

поиск и фильтрация источников (RAG)

дисциплина ответа (LoRA)

пост-валидация и доказательность

интеграция в ГИС и базы

безопасность, аудит и сопровождение

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