LLM-инжиниринг: создание продакшн-систем на Python

Введение: почему промпт-инжиниринг — это только начало

Когда-то казалось, что достаточно написать хороший промпт — и языковая модель сделает всю работу. Но для серьёзных проектов это иллюзия. Промпт — это запрос к вероятностной функции без памяти, доступа к вашим данным и гарантий корректности. Всё, что реально нужно enterprise: привязка к корпоративным знаниям, аудит, контроль доступа, управление стоимостью и отказоустойчивость — живёт за пределами промпта. LLM-инжиниринг — это дисциплина построения целостной системы вокруг модели.

Эволюция отрасли чётко отражает проблемы, которые решал каждый этап:

• Промпт-инжиниринг — научил модель следовать инструкциям, но оставил её без данных и действий.
• RAG (Retrieval-Augmented Generation) — привязал ответы к актуальным документам.
• AI-агенты — дали моделям способность планировать и вызывать инструменты.
• MCP (Model Context Protocol) — стандартизировал интеграцию с внешними сервисами.
• Корпоративные LLM-системы — решают всё остальное: надёжность, безопасность, наблюдаемость, управление и масштабирование.

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

Что такое LLM-инжиниринг

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

Полезная ментальная модель — относиться к LLM как к базе данных или внешнему API. Вы же не отдаёте пользователю сырое подключение к БД — вы оборачиваете его в контроль доступа, пул соединений, кеширование, мониторинг и failover. LLM-инжиниринг применяет ту же дисциплину к недетерминированному и дорогому компоненту.

Основные обязанности LLM-инженера:

• Проектирование пайплайнов поиска для привязки вывода модели к авторитетным данным.
• Сборка промптов и контекста как тестируемых, версионируемых артефактов.
• Внедрение guardrails для валидации ввода, фильтрации вывода и соблюдения политик.
• Создание оценочных тестов для выявления регрессий до релиза.
• Инструментирование системы трейсингом, логированием и метриками для каждого запроса.
• Управление стоимостью и задержкой через выбор модели, кеширование и маршрутизацию.
• Обработка угроз безопасности: инъекции промптов, утечка данных, PII.

Реальный пример: система автоматизации поддержки не просто передаёт сообщение пользователя модели. Она классифицирует намерение, извлекает статьи базы знаний и контекст аккаунта, собирает промпт, генерирует ответ, проверяет его фильтрами, логирует весь трейс и эскалирует человеку при низкой уверенности. Каждый шаг — инженерная работа.

Ключевые компоненты корпоративного LLM-стека

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

• API-шлюз — единая точка входа, обработка TLS, маршрутизация, политики.
• Аутентификация и авторизация — кто вызывает и что может видеть; изоляция арендаторов.
• Rate limiting — защита от перерасхода; лимиты в токенах.
• Промпт-слой — шаблоны, few-shot примеры, сборка контекста. Версионируется как код.
• LLM — движок генерации. Часто несколько моделей, маршрутизация по сложности.
• Модель эмбеддингов — преобразует текст в векторы для семантического поиска.
• Векторная БД — хранит эмбеддинги и выполняет поиск ближайших соседей.
• Слой поиска — переписывание запросов, гибридный поиск, фильтрация, реранжирование.
• Guardrails — контроль ввода и вывода: инъекции, PII, политики.
• Память — краткосрочная и долгосрочная, с границами для предотвращения раздувания контекста.
• Слой агентов — многоплановое рассуждение, планирование, выбор инструментов.
• Слой MCP — стандартизированный интерфейс между моделью и внешними инструментами.
• Кеширование — точное и семантическое, для снижения задержек и стоимости.
• Наблюдаемость — трейсинг, логи, метрики для воспроизводимости каждого запроса.
• Оценка — автоматическое измерение качества на офлайн-датасетах и в реальном времени.
• Деплой, масштабирование, мониторинг — контейнеризация, автоскейлинг, алерты.

Ключевая мысль: проблемы поиска — это не проблемы промпта, а проблемы задержки — редко проблемы модели. Инженер, умеющий локализовать проблему в нужный слой, решает инциденты за минуты.

Архитектура корпоративной LLM-системы

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

1. Клиент и фронтенд — веб-приложение, чат-виджет. Захватывает ввод, стримит токены. Никогда не общается напрямую с провайдером моделей.
2. Бэкенд — оркестрирует пайплайн: бизнес-логика, сессии, последовательность поиска, генерации и валидации.
3. API-шлюз — TLS, WAF, глобальные лимиты, грубые правила доступа.
4. Аутентификация — проверяет токены, определяет роли и арендатора.
5. LLM-шлюз — внутренняя абстракция над провайдерами: централизует credentials, реализует retry и failover, маршрутизирует на дешёвую модель, записывает токены для учёта затрат.
6. Шаблоны промптов — версионированные шаблоны собирают финальный промпт из системных инструкций, контекста, памяти и запроса пользователя.
7. RAG и пайплайн эмбеддингов — при необходимости поиска: переписывание запроса, эмбеддинг, поиск в векторной БД (часто гибридный с ключевыми словами), реранжирование, вставка лучших чанков в промпт.
8. Векторная БД и источники знаний — пайплайн ингестии: извлечение из документов, вики, тикетов, чанкинг, эмбеддинг, загрузка с метаданными.
9. Память — извлекается история диалога и долгосрочные факты, ограниченные текущим контекстом.
10. Агент и вызов инструментов — агент планирует шаги, вызывает инструменты, наблюдает результаты, итеративно завершает задачу.

Пример кода на Python для базового RAG-пайплайна:

import openai
from sentence_transformers import SentenceTransformer
import numpy as np

# Загрузка модели эмбеддингов
embedder = SentenceTransformer('all-MiniLM-L6-v2')

# Пример корпуса документов (в реальности — из векторной БД)
documents = [
    "Политика возврата: товар можно вернуть в течение 30 дней.",
    "График работы: пн-пт с 9 до 18.",
]
doc_embeddings = embedder.encode(documents)

def retrieve(query, top_k=1):
    query_emb = embedder.encode([query])
    # Косинусное сходство
    scores = np.dot(doc_embeddings, query_emb.T).flatten()
    top_indices = np.argsort(scores)[-top_k:][::-1]
    return [documents[i] for i in top_indices]

def generate_answer(query):
    context = retrieve(query)
    prompt = f"Контекст: {' '.join(context)}\nВопрос: {query}\nОтвет:"
    response = openai.ChatCompletion.create(
        model="gpt-4",
        messages=[{"role": "user", "content": prompt}]
    )
    return response['choices'][0]['message']['content']

# Пример использования
print(generate_answer("Когда можно вернуть товар?"))

Жизненный цикл LLM в продакшне

Управление жизненным циклом модели — от выбора до деактивации — критично для enterprise.

• Выбор модели: оценка по качеству, стоимости, задержке, безопасности. Проблема: vendor lock-in.
• Настройка (fine-tuning): дообучение на корпоративных данных для специфических задач. Требует размеченных данных и инфраструктуры.
• Оценка: офлайн на тестовых наборах, онлайн A/B-тесты, метрики: точность, полнота, токсичность, соответствие политикам.
• Деплой: через API-шлюз с канареечным развёртыванием и откатом.
• Мониторинг: задержка, частота ошибок, стоимость, дрейф данных, инциденты безопасности.
• Обновление: регулярная переоценка, замена на новые версии, управление версиями.

Реальные корпоративные сценарии

• Поддержка клиентов: классификация интентов, поиск по базе знаний, генерация ответов, эскалация.
• Поиск по документации: RAG над внутренними вики, кодом, тикетами.
• Анализ контрактов: извлечение ключевых условий, сравнение с политиками.
• Кодовые ассистенты: подсказки на основе внутренних репозиториев.
• Автоматизация документооборота: заполнение форм, извлечение данных из PDF.

Лучшие практики

• Версионируйте промпты и конфигурации как код.
• Используйте семантическое кеширование для повторяющихся запросов.
• Внедряйте guardrails на входе и выходе.
• Трейсите каждый запрос для отладки и аудита.
• Тестируйте на краевых случаях: пустой ввод, инъекции, большой контекст.
• Устанавливайте бюджет на токены и мониторьте расходы.

Частые ошибки

• Полагаться только на промпт-инжиниринг без RAG.
• Игнорировать безопасность: промпт-инъекции, утечка контекста.
• Не оценивать качество: нет метрик, нет тестов.
• Не кешировать: каждый запрос дорогой.
• Не мониторить: сбои незаметны до жалоб пользователей.

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

• Начинайте с требований, а не с модели.
• Рисуйте слои: шлюз, поиск, генерация, guardrails, наблюдаемость.
• Обсуждайте компромиссы: стоимость vs качество, задержка vs точность.
• Приводите примеры из реального опыта.
• Покажите понимание жизненного цикла: от выбора до деактивации.

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

1. Как спроектировать RAG-пайплайн для миллиона документов?
2. Как защититься от промпт-инъекций?
3. Как управлять стоимостью при высокой нагрузке?
4. Как реализовать A/B-тестирование моделей?
5. Как обрабатывать контекст длиной более 100K токенов?
6. Как обеспечить изоляцию арендаторов в мультитенантной системе?
7. Как детектить и реагировать на дрейф данных?
8. Как проектировать агентов с памятью?
9. Как интегрировать LLM с внешними API через MCP?
10. Как оценивать качество генерации без человеческой разметки?

Заключение: что делать прямо сейчас

LLM-инжиниринг — это не про написание промптов, а про построение надёжных систем. Начните с малого: реализуйте простой RAG-пайплайн на Python с использованием openai и sentence-transformers. Добавьте кеширование и логирование. Затем — guardrails и мониторинг. Постепенно вы построите систему, готовую к production. Удачи!