Каждая организация, которая решает внедрить AI-оценку качества перевода, упирается в один и тот же вопрос: делать самим или купить готовое? Простого ответа нет — зависит от объёмов, команды, бюджета и того, насколько QA перевода стратегически важен для вашего бизнеса.

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

Что есть на рынке в 2025 году

Вариантов больше, чем когда-либо, и это одновременно хорошо и запутывает.

Варианты build

Подход	Сложность	Диапазон затрат
API LLM напрямую (OpenAI, Anthropic)	Высокая	$10-50K настройка + использование
Дообученные модели	Очень высокая	$50-200K+
Open-source фреймворки	Средне-высокая	$20-100K настройка

Варианты buy

Подход	Сложность	Диапазон затрат
Специализированный LQA SaaS (KTTC, ContentQuo)	Низкая	$500-5K/месяц
TMS с AI QA (Phrase, Lokalise)	Низко-средняя	$1-10K/месяц
Enterprise платформы (кастомные деплои)	Средняя	$50-200K/год

Build: во что это обойдётся на самом деле

Я участвовал в нескольких build-проектах для translation QA и скажу так: все они заняли в 1.5-2 раза дольше, чем планировалось. Вот почему.

Что нужно из экспертизы

AI/ML-инженеры — промпт-инжиниринг, калибровка моделей, обработка ошибок при неопределённости AI, масштабирование и управление затратами. Минимум 1-2 senior-инженера на 6-12 месяцев.

Лингвист или LQA-специалист — без него AI будет выдавать технически работающую, но лингвистически бессмысленную оценку. Кто-то должен реализовать таксономию ошибок MQM, откалибровать серьёзности, прописать языковые правила. Минимум 0.5 FTE.

Инфраструктура:

Компонент	Что нужно
Управление API	Rate limiting, кэширование, failover
Пайплайн данных	Приём, обработка, хранение оценок
UI/дашборд	Визуализация, управление
Интеграции	TMS, CAT-инструменты, CI/CD

Реалистичные сроки

Месяц 1-2:   Требования, архитектура, прототип
Месяц 3-4:   Ядро движка оценки
Месяц 5-6:   UI, дашборд, интеграции
Месяц 7-8:   Тестирование, калибровка, пилот
Месяц 9-10:  Хардинг, документация
Месяц 11-12: Развёртывание, обучение, итерации

9-12 месяцев до production-ready. И это при условии, что команда есть и не отвлекается на другие проекты.

Реальные затраты

Год 1 — разработка:

Статья	Затраты
ML-инженер (1.5 FTE × $180K)	$270,000
Лингвист/LQA-специалист (0.5 FTE)	$60,000
Продукт/PM поддержка (0.25 FTE)	$40,000
LLM API (разработка и тестирование)	$15,000
Инфраструктура (AWS/GCP)	$10,000
Итого	$395,000

Год 2+ — поддержка:

Статья	Ежегодно
ML-инженер (0.5 FTE)	$90,000
LLM API (продакшен)	$30-100,000
Инфраструктура	$15,000
Калибровка	$20,000
Итого	$155-225,000

Что обычно недооценивают

Вот список сюрпризов, которые ждут почти каждый build-проект:

Калибровка занимает месяцы. Добиться того, чтобы AI ставил серьёзность так же, как ваши ревьюеры, — итеративный процесс. Три-шесть месяцев — норма.
Граничные случаи в реальном контенте сложнее тестовых данных. Маркетинговый текст с иронией, юридическая формулировка с двойным отрицанием, UI-строка в 3 слова без контекста — всё это ломает промпты, которые отлично работали на чистых примерах.
Новые языки — каждая пара требует отдельной калибровки. То, что работает для EN-DE, может быть бесполезно для EN-JA.
Обновления моделей — OpenAI и Anthropic регулярно обновляют модели. Ваши промпты могут начать работать иначе. Нужно мониторить и адаптировать.
Альтернативные издержки — ваши ML-инженеры не работают над основным продуктом, пока строят QA-систему.

Buy: что получаете и чего не получаете

Сроки

Неделя 1:    Оценка и выбор вендора
Недели 2-3:  Контракт и настройка
Недели 4-6:  Конфигурация и интеграция
Недели 7-8:  Пилот и калибровка
Неделя 9+:   Продакшен

2-3 месяца до продакшена — в 4-5 раз быстрее, чем build.

Затраты

Для организации с 1М слов/месяц.

Год 1:

Статья	Затраты
Подписка	$24,000
Использование (1М слов × 12)	$60,000
Интеграции	$15,000
Обучение	$5,000
Итого	$104,000

Год 2+:

Статья	Ежегодно
Подписка	$24,000
Использование	$60,000
Поддержка	$5,000
Итого	$89,000

Что включено

Готовая MQM-типология, поддержка 50-100+ языков, откалиброванные пороги серьёзности, дашборд и отчёты, API, регулярные обновления моделей, клиентская поддержка, сертификаты безопасности.

Чего может не быть

Кастомные категории ошибок, on-premise развёртывание, глубокая кастомизация, доступ к исходному коду, безлимитные API-вызовы, узкоспециализированные доменные модели.

Подводные камни

Зависимость от вендора. Ваш QA-процесс привязан к внешнему сервису. Если вендор закроется или поднимет цены — придётся мигрировать.
Ограниченная кастомизация. Если у вас очень специфичные требования, SaaS может не покрыть их.
Данные уходят наружу. Контент отправляется третьей стороне для оценки. Для публичного контента — не проблема. Для регулируемых данных — серьёзный вопрос.
Ценообразование может меняться. Стоимость за слово сегодня $0.005, через год может быть $0.008.

Как выбрать: пять факторов

Фактор 1: объём

Объём	Рекомендация
< 100K слов/мес.	Buy — build не окупится никогда
100K — 1M	Buy — если нет сильных причин для build
1M — 10M	Зависит от остальных факторов
> 10M	Рассмотреть build — экономия масштаба существенна

При 10M слов/мес. разница в стоимости за слово между собственным решением и SaaS начинает перевешивать затраты на разработку.

Фактор 2: кастомизация

Потребность	Рекомендация
Стандартная MQM-оценка	Buy
Минимальная кастомизация (пороги, веса)	Buy — большинство вендоров поддерживает
Кастомные категории ошибок	Смотреть внимательно
Проприетарная система оценки	Скорее build
Уникальные требования к процессу	Скорее build

Фактор 3: техническая команда

Что есть	Рекомендация
Нет ML-экспертизы	Buy — однозначно
Есть ML-опыт, но ресурсы заняты	Buy — не отвлекайте людей от основного продукта
Сильная ML-команда с ресурсами	Любой вариант
ML — ваш профиль, перевод — стратегия	Рассмотреть build

Фактор 4: чувствительность данных

Тип данных	Рекомендация
Публичный контент	Buy
Стандартный бизнес-контент	Buy с правильным DPA
Чувствительная IP	Тщательно проверить безопасность вендора
Регулируемые данные (медицина, право)	Может потребоваться private deployment
Секретные/государственные	Build или on-prem

Фактор 5: стратегическая роль QA

Роль	Рекомендация
Операционная потребность	Buy
Дифференциатор ваших услуг	Рассмотреть build
QA — часть вашего продукта	Build
Развитие ML-компетенций — стратегическая цель	Рассмотреть build

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

Чистый build или buy — не единственные варианты. На практике часто работают комбинации.

Buy + кастомные расширения

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

┌─────────────────────────────────────────────┐
│        Коммерческая LQA-платформа           │
│  (базовая оценка, стандартные процессы)     │
└─────────────────────┬───────────────────────┘
                      │ API
        ┌─────────────┴─────────────┐
        │                           │
┌───────▼───────┐           ┌───────▼───────┐
│ Кастомный     │           │ Кастомная     │
│ движок правил │           │ отчётность    │
│               │           │               │
│ - Доменная    │           │ - BI-         │
│   валидация   │           │   интеграция  │
│ - Свои        │           │ - Свои        │
│   проверки    │           │   дашборды    │
└───────────────┘           └───────────────┘

Своя обёртка, чужое ядро

Используете LLM API напрямую, но строите кастомный слой оркестрации:

class TranslationQA:
    def __init__(self):
        self.llm = OpenAI()  # или коммерческий LQA API
        self.custom_rules = load_domain_rules()
        self.glossary = load_glossary()

    def evaluate(self, source, target, lang_pair):
        # 1. Кастомные предпроверки
        custom_issues = self.apply_custom_rules(source, target)

        # 2. LLM/API оценка
        llm_evaluation = self.call_llm_qa(source, target, lang_pair)

        # 3. Кастомная постобработка
        final_result = self.merge_and_score(custom_issues, llm_evaluation)

        return final_result

Прогрессивный build

Честно говоря, это самый разумный путь для большинства. Начинаете с buy, набираетесь опыта, потом решаете.

Фаза 1 (месяцы 0-12): коммерческое решение. Изучаете реальные требования, накапливаете экспертизу, собираете данные калибровки. Через год вы понимаете свои потребности в 10 раз лучше, чем в начале.

Фаза 2 (месяцы 12-24): создаёте дополнительные компоненты — кастомный движок правил для доменных проверок, оптимизированные интеграции, улучшенную аналитику.

Фаза 3 (месяц 24+): оцениваете полный build. Теперь у вас есть данные, опыт и команда. Решение принимается на фактах, а не на предположениях.

Примеры из практики

Переводческое агентство

500K слов/мес., 15 клиентов, стандартный контент, маленькая команда, нет ML-экспертизы. QA — операционная потребность, а не конкурентное преимущество.

Решение: buy. Объём не оправдывает build. Нет людей для разработки. Коммерческие решения покрывают все потребности.

Компания корпоративного ПО

2M слов/мес., сильная инженерная команда, высокоспециализированный технический контент, строгие требования к терминологии.

Решение: гибрид (buy + кастомизация). Объём мог бы оправдать build, но базовые потребности стандартны. Разумнее купить платформу и написать кастомные правила для своей терминологии, чем строить всё с нуля.

Крупный LSP

10M+ слов/мес., QA — ключевой дифференциатор услуг, развитие AI-возможностей — часть стратегии, есть своя ML-команда.

Решение: build. Масштаб даёт экономию. QA — то, за что клиенты платят. Есть люди и стратегическое намерение.

Фармкомпания

300K слов/мес., строгий compliance, весь контент регулируется, нужен полный аудиторский след.

Решение: buy (enterprise/on-prem). Объём не оправдывает build. Но compliance-требования диктуют enterprise-развёртывание с контролем данных. Нужен вендор с сертификатами и on-prem опцией.

Типичные ошибки

При build

Недооценка калибровки. Закладывайте 3-6 месяцев только на это.
Забыли про поддержку. Модели требуют постоянного внимания — обновления, дрифт, новые языки.
Нет лингвиста в команде. AI сам по себе не понимает разницу между major и minor без экспертной калибровки.
Спроектировали под текущий объём. Через год объём вырастет. Проектируйте под 10×.
Пытаются сделать всё сразу. Начните с одной языковой пары и одного типа контента.

При buy

Не провели пилот на своём контенте. Демо на чистых примерах вендора — не показатель.
Не посчитали полную стоимость. Плата за использование при больших объёмах может превысить подписку в разы.
Недооценили интеграцию. Подключить API — неделя. Интегрировать в процессы — месяц-два.
Пропустили калибровку. Даже SaaS нужно настраивать под ваш контент.
Не продумали exit strategy. Что если через 2 года нужно мигрировать? Данные в проприетарном формате?

Чек-лист для решения

Build, если:

Объём > 5M слов/мес.
Есть ML-инженеры с ресурсами
QA — стратегический дифференциатор
Уникальные требования, не покрытые рынком
Данные требуют полного контроля
Бюджет на 12+ месяцев разработки
Готовность к постоянной поддержке

Buy, если:

Объём < 2M слов/мес.
Нет ML-экспертизы
Стандартные QA-требования
Нужно запуститься за 3 месяца
Предпочитаете предсказуемые затраты
Не хотите отвлекать инженеров от основного продукта

Гибрид, если:

Стандартные потребности + немного кастомизации
Хотите сохранить гибкость на будущее
Развиваете экспертизу постепенно
Объём растёт к порогу build

FAQ

Сколько реально стоит построить AI QA перевода?

$300-500K в первый год (команда, инфраструктура, API) и $150-250K ежегодно на поддержку. Если ML-специалистов нужно нанимать и обучать — добавляйте 6-12 месяцев и $100-200K.

Можно просто взять ChatGPT/Claude API и сделать QA?

Технически — да. Практически — сырые LLM API требуют серьёзной инженерии для продакшена: структурированный вывод, обработка ошибок, кэширование, rate limiting, калибровка, интеграция. «Build» — это не API-ключ и промпт, а всё вокруг них.

Какой минимально жизнеспособный build?

Промпт-инжиниринг для MQM-оценки, парсинг структурированного вывода, базовый UI, интеграция с вашим процессом. 3-6 месяцев с 1-2 инженерами. Работать будет, но без красот — и калибровка потребует времени.

Как убедить руководство выбрать buy?

Четыре аргумента: время до результата (3 месяца vs 12), альтернативные издержки (над чем ещё могут работать инженеры?), полная стоимость build включая поддержку, риск провала или задержки. Покупка позволяет быстро проверить AI QA на практике и принять обоснованное решение о build позже — если понадобится.

Когда build становится дешевле buy?

Обычно при 5-10M слов/мес. — но это зависит от цен вендора и ваших инженерных затрат. При меньших объёмах buy почти всегда выгоднее. Постройте 3-летнее сравнение TCO с вашими реальными цифрами, прежде чем решать.

Итог

Решение build vs buy сводится к нескольким вопросам.

Build — когда QA стратегичен для бизнеса, есть команда и ресурсы, объём оправдывает инвестиции, нужны функции, которых нет на рынке.

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

Гибрид — когда хотите коммерческую надёжность с возможностью расширения под свои нужды.

Мой совет большинству: начните с buy или гибрида. Получите опыт с AI QA в продакшене. Через год у вас будут данные, понимание и команда для обоснованного решения о build — если оно вообще понадобится.

Цель — не построить технологию ради технологии. Цель — лучшее качество перевода. Выбирайте путь, который приведёт к ней быстрее.

Хотите оценить, подойдёт ли вам готовое решение? Попробуйте KTTC бесплатно — и поймёте, нужен ли build, прежде чем вкладывать $400K.