Консалтинг без утечек: собираем локальную фабрику анализа документов за £30K

Зачем юристу или консультанту своя электростанция?

Представьте: вы анализируете слияние компаний. На столе 1200 страниц юридических документов, финансовых отчетов, переписки. Клиент спрашивает: «Какие риски в пункте 4.7.3 на странице 843?» Открывать ChatGPT нельзя — это NDA. Нанимать стажеров на месяц — дорого. Остается одно: построить собственную вычислительную фабрику, которая жует PDF как конфеты, не покидая вашего офиса.

Почему облако не подходит для юристов

Облачные LLM — это черный ящик. Вы не знаете, где физически лежат ваши данные, кто их просматривает, как долго хранятся локи. Когда Microsoft или Google получают запрос от правительства, они молча отдают данные. Ваш NDA этого не переживет.

Но приватность — только половина проблемы. Вторая половина — контроль. Облачные API ограничивают контекст (128K токенов у лучших моделей — это примерно 300 страниц текста), не дают тонкой настройки под вашу предметную область и стоят диких денег при активном использовании. Анализ одного 1000-страничного документа через GPT-4 может обойтись в $50-100. Умножьте на 10 документов в неделю.

Сердце системы: три RTX Pro 6000 против одной A100

Здесь многие совершают первую ошибку — гонятся за одной картой H100 или A100. Не делайте этого. Для анализа документов важна не только вычислительная мощность, но и гибкость распределения нагрузки.

Три Pro 6000 дают магическое число 144GB VRAM. Почему это важно? Вы можете:

• На первой карте запустить большую долгоконтекстную модель (например, Yi-34B-200K, которая занимает ~70GB в FP16)
• На второй карте держать векторную базу данных в памяти для мгновенного поиска
• Третью карту использовать для специализированных задач: проверки противоречий между документами или извлечения таблиц

Если одна карта «упадет» (а с драйверами NVIDIA под Linux это случается), система продолжит работать на двух оставшихся. С одной A100 вы получаете single point of failure.

Остальная начинка: от процессора до хранилища

Процессор: AMD Threadripper PRO 7965WX (24 ядра). Зачем столько? Потому что обработка PDF — это не только нейросети. Декодирование страниц, OCR для сканов, предобработка изображений — все это грузит CPU. Плюс вам нужны PCIe линии для трех карт (минимум x16/x16/x8).

Оперативная память: 256GB DDR5. Почему не 128GB? Потому что когда вы параллельно обрабатываете несколько документов, система кэширует их в RAM. 1000-страничный PDF после распаковки текста и изображений может занимать 5-10GB. Десять таких документов — уже 50-100GB.

Хранилище: 2× NVMe 4TB в RAID 0 для скорости. Не бойтесь RAID 0 — все важные данные должны быть в бэкапах на отдельном NAS. Скорость чтения здесь критична: загрузка модели Yi-34B с диска занимает минуты. Каждая минута простоя консультанта стоит денег.

1 Сборка и первичная настройка железа

Собрать такой компьютер — это квест. Материнская плата WRX90, блок питания на 1600W, корпус Full-Tower. После сборки первое, что нужно сделать — обновить BIOS и установить проприетарные драйвера NVIDIA через apt.

# Добавляем репозиторий NVIDIA
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

# Устанавливаем драйвера (важно: версия 550+ для поддержки Ada)
sudo apt install nvidia-driver-550 nvidia-utils-550

# Проверяем, что все три карты видны
nvidia-smi --query-gpu=name,memory.total --format=csv

2 Установка софтверного стека

Не используйте Docker для всего подряд. Для LLM он добавляет накладные расходы. Устанавливайте нативно:

# Ollama — для быстрого запуска моделей
curl -fsSL https://ollama.com/install.sh | sh

# Устанавливаем llama.cpp из исходников для максимальной производительности
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp && make -j24 CUDA_DOCKER_ARCH=all # 24 потока Threadripper

# ChromaDB для векторного поиска
pip install chromadb[client]

Сравнение Ollama и других систем показывает: Ollama проще, но llama.cpp быстрее на 15-20% для инференса больших моделей.

Архитектура RAG для 1000-страничных монстров

Стандартный RAG разваливается на длинных документах. Проблема в чанкинге: разбиваете договор на куски по 500 слов, и модель теряет связь между разделом 1 и разделом 12, где уточняются условия.

Решение — иерархический RAG:

1. Извлекаем структуру документа: оглавление, разделы, подразделы
2. Создаем два уровня эмбеддингов: для разделов (крупные чанки 2000-5000 слов) и для параграфов (мелкие чанки 200-500 слов)
3. При поиске сначала ищем раздел по смыслу, затем внутри него — конкретные параграфы

# Псевдокод иерархического индекса
from langchain.text_splitter import RecursiveCharacterTextSplitter

# Первый уровень: разделы по заголовкам
section_splitter = RecursiveCharacterTextSplitter(
    separators=["\n\n## ", "\n\n# ", "\n\n"],  # Markdown-ориентированный
    chunk_size=4000,
    chunk_overlap=200
)

# Второй уровень: параграфы внутри разделов
paragraph_splitter = RecursiveCharacterTextSplitter(
    separators=[". ", "\n", " "],
    chunk_size=500,
    chunk_overlap=50
)

# Создаем связанные эмбеддинги
for section in sections:
    section_embedding = embed(section.text)
    store_in_vector_db(section_embedding, metadata={'type': 'section'})
    
    for paragraph in paragraph_splitter.split_text(section.text):
        para_embedding = embed(paragraph)
        store_in_vector_db(para_embedding, metadata={
            'type': 'paragraph', 
            'section_id': section.id
        })

Когда пользователь спрашивает про «компенсацию за задержку поставки», система сначала находит раздел «Ответственность сторон», затем внутри него — конкретные параграфы про штрафные санкции.

Какие модели загружать на 144GB VRAM

Распределение памяти — это искусство. Вот рабочая конфигурация:

Почему Yi-34B? Потому что у нее действительно работающий 200K контекст (в отличие от многих моделей, где декларируют 128K, но после 64K качество падает). И она отлично справляется с юридическими текстами.

8B модель на второй карте — для простых вопросов: «Найди все упоминания компании X». Не нужно гонять 34B модель для таких задач.

Обработка PDF: где спотыкаются 90% решений

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

Используйте связку:

• Docling для структурированного извлечения (отлично работает с оглавлениями)
• PaddleOCR для сканов (китайская разработка, но для английского работает лучше Tesseract)
• Camelot для таблиц (сохраняет структуру в CSV)

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

# Пример обработки сложного PDF
from docling.document import Document
import camelot

# Docling извлекает текст и структуру
doc = Document("contract.pdf")
doc.parse()
text = doc.get_text()
toc = doc.get_table_of_contents()  # Оглавление!

# Camelot для таблиц
tables = camelot.read_pdf("contract.pdf", pages='all', flavor='lattice')
for table in tables:
    table.to_csv(f"table_{table.page}.csv")  # Сохраняем для анализа

Интерфейс: как юристы будут работать с системой

Не заставляйте пользователей писать промпты в командной строке. Разверните локальный веб-интерфейс на базе Gradio или Streamlit.

Ключевые функции интерфейса:

1. Загрузка PDF (перетаскиванием)
2. Автоматическое индексирование с прогресс-баром
3. Чат с документом: «Покажи все обязательства покупателя»
4. Сравнение двух документов: «Чем отличается версия 1.2 от 1.3?»
5. Экспорт ответов в Word с цитированием (страницы, пункты)

Интерфейс должен быть тупым как пробка. Юрист не должен думать о temperature или top_p.

Типичные ошибки при развертывании

Что дальше? Эволюция системы

Через месяц работы вы поймете, что система слишком хорошо справляется с анализом. Пора расширять функционал:

• Добавить анализ аудиозаписей совещаний через локальную транскрипцию
• Настроить автоматическое сравнение новых версий договоров с предыдущими (diff на стероидах)
• Подключить систему к внутренней почте для анализа переписки с клиентами

Самое главное — начать. Первый прототип можно собрать на одной карте за £10K. Когда система начнет экономить 20 часов работы в неделю, докупите остальное железо. Конфиденциальность клиентов стоит каждой потраченной копейки. А возможность сказать «ваши данные никогда не покидали наш офис» — бесценна.

P.S. Если бюджет £30K кажется большим, посчитайте стоимость утечки одного конфиденциального договора. Или стоимость найма двух юристов-аналитиков на полный рабочий день. Система окупается быстрее, чем вы думаете.