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

Когда одна ошибка RAG-бота стоит жизни или миллиардов

Вы запускаете RAG-бот для строителей. Вопрос про монтаж балок. Система находит устаревший документ 2012 года с нормами, которые отменили в 2023. Рабочие следуют рекомендациям. Балки рушатся. Вот цена банальной проблемы с актуальностью документов в RAG-системе.

В уходе за пожилыми ещё хуже. Бот по ошибке рекомендует лекарство, которое конфликтует с текущими препаратами пациента. В шахте - совет провести работы в зоне с повышенным содержанием метана. Регулируемые отрасли не прощают ошибок, которые в e-commerce просто потеряют клиента.

Три реальных кейса, где обычный RAG сломался

Стройка: BIM Inspector и его 80% успеха - остальные 20% убили проект

История про BIM Inspector выглядит красиво, пока не узнаешь детали. Система действительно ускорила адаптацию новичков на 80%. Но оставшиеся 20% - это случаи, когда инспектор получал противоречивые указания из разных версий СНИПов и технических регламентов.

Проблема: в строительной документации 30% документов - таблицы, схемы, чертежи. Текстовые эмбеддинги их не понимают. Более того - названия документов важнее их содержания. ГОСТ Р 12345-2026 по пожарной безопасности должен иметь приоритет над методичкой 1998 года, даже если в старой методичке больше ключевых слов.

Уход за пожилыми: когда HIPAA аудит отказывает в 100% случаев

Проект для сети пансионатов. Бот должен помогать медсёстрам с уходом, напоминать про процедуры, подсказывать дозировки. На тестах работал идеально. Пришёл аудитор по HIPAA - проект закрыли в первый же день.

Шахты: где RAG-бот может вызвать взрыв метана

В горнодобывающей промышленности каждый документ имеет уровень критичности. Инструкция по технике безопасности при работе в забое - критическая. Отчёт о планерке начальства - нет. В обычном RAG они равны. Более того - в шахтах часто спрашивают коротко: "Можно ли включать?" Контекста нет. Без query expansion система находит документы про включение света в бытовке, а не про включение оборудования в газоопасной зоне.

Технические решения, которые реально работают

Забудьте про базовый RAG с LangChain и OpenAI embeddings. В регулируемых отраслях это не работает. Вот что работает на 29.03.2026:

1 Query expansion через Claude Haiku 3 (да, именно Haiku, не Sonnet)

Claude 3.7 Haiku в 2026 году - самый быстрый и дешёвый LLM для query expansion. Зачем расширять запросы? Потому что в стройке спрашивают "балка", а имеют в виду "стальная двутавровая балка перекрытия ГОСТ 26020". В уходе за пожилыми - "давление" вместо "артериальное давление у лежачего пациента после инсульта".

# Пример query expansion через Haiku
from anthropic import Anthropic

client = Anthropic(api_key='your_key')

def expand_query(original_query: str, context: str = "строительство") -> list[str]:
    prompt = f"""Ты — специалист в области {context}. 
    Расширь запрос пользователя для поиска в технической документации.
    Верни 3 варианта расширенного запроса, каждый на новой строке.
    
    Оригинальный запрос: {original_query}
    """
    
    response = client.messages.create(
        model="claude-3-haiku-20270212",
        max_tokens=150,
        messages=[{"role": "user", "content": prompt}]
    )
    
    expanded = response.content[0].text.strip().split('\n')
    return [original_query] + expanded[:3]

Почему Haiku, а не GPT-4o или Claude Sonnet? Haiku в 3 раза быстрее и в 5 раз дешевле. Для query expansion этого достаточно. Сохраняйте бюджет для основного LLM.

2 Приоритизация документов по названию и метаданным

В регулируемых отраслях метаданные важнее содержания. Документ с названием "ГОСТ Р 12345-2026" всегда важнее документа с названием "Методические рекомендации 1998". Даже если в рекомендациях больше релевантного текста.

# Система приоритетов для строительных документов
document_priority = {
    "ГОСТ": 100,
    "СНИП": 95,
    "СП": 90,
    "ФЗ": 85,
    "Технический регламент": 80,
    "Инструкция": 70,
    "Методичка": 50,
    "Письмо": 30,
    "Черновик": 10
}

def calculate_document_score(chunk, query, similarity_score):
    base_score = similarity_score * 0.7
    
    # Проверяем приоритет по названию
    priority = 0
    for key, value in document_priority.items():
        if key.lower() in chunk.metadata["title"].lower():
            priority = max(priority, value)
    
    priority_score = priority * 0.3
    
    # Штраф за устаревшие документы
    year = chunk.metadata.get("year", 2000)
    if year < 2020:
        priority_score *= 0.5  # Штраф 50% для документов старше 2020
    
    return base_score + priority_score / 100

3 Трёхуровневая система промптов вместо одного гигантского

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

# Пример трехуровневой системы
class ThreeLayerRAG:
    def __init__(self):
        self.safety_filter = """Ты — фильтр безопасности для медицинского RAG-бота.
        Отвечай только "ДА" или "НЕТ".
        Вопрос: {query}
        Контекст: {context}
        
        Вопрос содержит запрос на:
        1. Постановку диагноза? (ДА/НЕТ)
        2. Назначение лечения? (ДА/НЕТ)
        3. Интерпретацию анализов? (ДА/НЕТ)
        Если хотя бы на один пункт ДА - отвечай "НЕТ" на весь вопрос."""
        
        self.intent_classifier = """Классифицируй намерение пользователя:
        1. Вопрос о процедурах ухода
        2. Вопрос о документации
        3. Вопрос о лекарствах
        4. Вопрос о симптомах
        5. Другое"""
        
        self.answer_generator = {
            "procedures": "Шаблон для процедур ухода...",
            "medication": "Шаблон для вопросов о лекарствах с обязательной проверкой взаимодействий..."
        }

4 Локальные эмбеддинги и ChromaDB вместо облачных API

В 2026 году всё ещё есть проекты, которые шлют медицинские записи в OpenAI embeddings. Это нарушение HIPAA, GDPR и здравого смысла. Решение: локальные модели эмбеддингов.

# Установка на свой сервер
pip install sentence-transformers chromadb

# Использование
from sentence_transformers import SentenceTransformer
import chromadb

# Модель 2026 года для русского языка
model = SentenceTransformer('intfloat/multilingual-e5-large-v2-2026')
emmbeddings = model.encode(["текст документа"])

ChromaDB в 2026 поддерживает мультитенантность из коробки. Это решает проблему доступа: данные разных филиалов в разных коллекциях. Аудитор доволен.

Пошаговый план: от документов до продакшена

1 Подготовка документов с обязательной разметкой

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

• Год издания (обязательно)
• Тип документа (ГОСТ, инструкция, методичка)
• Уровень доступа (кто может видеть)
• Критичность (что будет, если ошибиться)
• Срок действия (когда документ устаревает)

Без этой разметки ваш RAG будет опасным. Нет времени на ручную разметку тысяч документов? Используйте тот же Claude Haiku для автоматической классификации.

2 Настройка векторной БД с фильтрами доступа

ChromaDB позволяет создавать отдельные коллекции для разных отделов. В строительстве: одна коллекция для общедоступных СНИПов, другая - для внутренних инструкций конкретного подрядчика.

import chromadb
from chromadb.config import Settings

# Создаём клиент с персистентностью
client = chromadb.PersistentClient(
    path="./rag_db",
    settings=Settings(anonymized_telemetry=False)
)

# Коллекция для московского филиала
mos_collection = client.create_collection(
    name="moscow_branch_docs",
    metadata={"branch": "moscow", "access_level": "medical_staff"}
)

# Коллекция для казанского филиала
kazan_collection = client.create_collection(
    name="kazan_branch_docs",
    metadata={"branch": "kazan", "access_level": "medical_staff"}
)

# При поиске проверяем права пользователя
user_branch = get_user_branch(current_user)
if user_branch == "moscow":
    results = mos_collection.query(query_embeddings=[query_embedding])
else:
    results = kazan_collection.query(query_embeddings=[query_embedding])

3 Реализация трёхуровневого промптинга

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

4 Мониторинг и логирование ВСЕГО

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

{
  "timestamp": "2026-03-29T14:30:00Z",
  "user_id": "медсестра_123",
  "original_query": "как менять повязку лежачему",
  "expanded_queries": ["уход за лежачими пациентами", "смена повязки"],
  "found_documents": [
    {"id": "doc_456", "title": "Инструкция по уходу 2025", "score": 0.87},
    {"id": "doc_789", "title": "Методичка 2018", "score": 0.65}
  ],
  "safety_filter_result": "PASSED",
  "intent_classification": "procedures",
  "final_answer": "Ответ согласно шаблону процедур...",
  "disclaimer_shown": true
}

Типичные ошибки, которые убивают проекты

Специфика для каждой отрасли

Строительство: бойтесь устаревших документов

В строительстве нормативы меняются каждые 2-3 года. Документ 2020 года часто опаснее, чем его отсутствие. Автоматически помечайте всё старше 5 лет как "устаревшее". Добавляйте в ответ предупреждение: "Внимание: этот документ устарел в 2024 году".

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

Медсестра из одного филиала не должна видеть истории болезней пациентов из другого. Даже если это улучшит ответ. Используйте принципы из статьи про аудит безопасности. Фильтруйте документы не только по релевантности, но и по правам доступа пользователя.

Шахты: критичность и краткость запросов

В шахтах запросы максимально короткие: "Можно?", "Сколько?", "Куда?". Без query expansion система не работает. Добавьте контекст шахты в расширение запросов. "Можно?" → "можно ли включать оборудование в газоопасной зоне шахты".

А что с метриками? RAG Doctor и BoR

Обычные метрики RAG (precision, recall) не работают в регулируемых отраслях. Точность 95% - это 5% опасных ответов. Неприемлемо.

Используйте RAG Doctor для автоматической диагностики проблем. И метрику Bits over Random (BoR) - она показывает, насколько система лучше случайного подбора документов. В регулируемых отраслях BoR должен быть выше 0.8.

Прогноз на 2027: RAG станет невидимым

К 2027 году все эти техники войдут в стандартные фреймворки. Но появится новая проблема: атаки на RAG-системы. Злоумышленники будут специально загружать документы с ошибками, чтобы манипулировать ответами. Уже сейчас готовьтесь к этому: добавьте верификацию источников, репутационную систему для документов, обязательную модерацию загружаемого контента.

Самое важное: в регулируемых отраслях RAG - не про удобство, а про безопасность. Каждая техническая деталь должна отвечать на вопрос "Что будет, если это сломается?" Если ответ "люди пострадают" - нужно два уровня защиты, мониторинг и ручной оверрайд.

Начните с малого: выберите один нефункциональный документ (например, правила внутреннего распорядка), настройте для него всю систему безопасности. Покажите аудитору. Получите фидбэк. Только потом масштабируйтесь на критичные документы. Так вы сэкономите месяцы работы и не получите запрет на использование системы.

Подписаться на канал