Когда AI не нужен и почему это важно

Понятные инженерные границы.

В эпоху повсеместного увлечения LLM, эмбеддингами и RAG-инфраструктурами легко попасть в когнитивную ловушку: если задача связана с текстом, значит нужен AI. Если есть данные – значит нужна модель. Если можно применить нейросеть – значит это "современно".

Но зрелая инженерия начинается не с вопроса "как применить AI?", а с вопроса:

Можно ли решить это проще?

Эта глава – про границы. Про то, где машинное обучение оправдано, а где это избыточный, дорогой и хрупкий инструмент.

Инженерная бритва Оккама

В инженерии действует простое правило:

Не усложняй систему без необходимости.

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

$$\text{Risk} = f(\text{Complexity}, \text{Uncertainty})$$

Чем выше сложность системы, тем выше:

• вероятность ошибок

• стоимость поддержки

• зависимость от внешних сервисов

• неопределённость поведения

AI часто увеличивает инфраструктурную сложность системы:

• требуется обучение или интеграция модели,

• появляется стохастичность,

• усложняется дебаг,

• появляются инфраструктурные требования (GPU, векторные БД и т.д.)

Если задача решается детерминированным кодом – это почти всегда лучшее решение.

Когда достаточно правил вместо модели

Рассмотрим пример.

Задача

Определить, содержит ли текст email-адрес.

Подход 1 – регулярное выражение

function containsEmail(string $text): bool {
    return preg_match('/[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}/i', $text) === 1;
}

Это упрощённая проверка, достаточная для большинства практических случаев.

Сложность: O(n)

Детерминированность: 100%

Стоимость: ≈ 0

Подход 2 – классификатор на основе LLM

• Отправка текста в API

• Получение вероятности

• Пороговая классификация

Сложность: высокая

Стоимость: постоянная

Стохастичность: есть

В этом случае использование AI инженерно неоправданно.

Линейная зависимость ≠ машинное обучение

Иногда ML используется там, где хватает формулы.

Пример: прогнозирование цены доставки

Если цена зависит от веса:

$$price = base + k \cdot weight$$

Это обычная линейная функция.

PHP-реализация:

function calculateDeliveryPrice(float $weight): float {
    $base = 5.0;
    $k = 1.2;
    return $base + $k * $weight;
}

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

Модель нужна, когда:

• зависимость неизвестна

• данных много

• есть шум

• правила невозможно явно сформулировать

Данные малы – модель бессмысленна

В ML работает фундаментальный принцип, в упрощённой интуитивной форме его можно выразить как:

$$\text{Generalization Error} \approx \frac{d}{n}$$

где

• $d$ – сложность модели (число параметров)

• $n$ – размер выборки

Если данных мало, модель:

• переобучается

• не обобщает

• ведёт себя нестабильно

Если у вас 200 записей в таблице и нет предобученных моделей – нейросеть редко оправдана.

Проблема можно формализовать явно

AI нужен там, где невозможно явно и устойчиво сформулировать правила.

Если правило можно сформулировать логически – его стоит написать.

Пример: фильтрация заказов

Условие:

• сумма > 1000

• клиент новый

• страна = "US"

function isHighRiskOrder(array $order): bool {
    return $order['amount'] > 1000
        && $order['is_new_client']
        && $order['country'] === 'US';
}

AI здесь – избыточен.

Стохастичность против требований бизнеса

Большинство AI-моделей являются вероятностными системами.

В тоже время бизнес часто требует:

• воспроизводимость

• предсказуемость

• объяснимость

• гарантии

Если система должна давать одинаковый результат на один и тот же вход – LLM может быть неподходящим инструментом.

Формально:

Детерминированная функция:

$$y = f(x)$$

LLM:

$$y \sim P(Y \mid X)$$

Это принципиально разные классы систем.

Время отклика и latency

Если операция должна выполняться за 5мс – облачная модель почти всегда не подходит.

Пример: фильтрация 10 000 строк.

Простой SQL-запрос справится за миллисекунды, например:

$pdo->query("SELECT * FROM users WHERE age > 18");

LLM – нет.

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

Иногда AI используют, чтобы “залатать” архитектурные дыры:

• плохая нормализация данных

• отсутствие индексов

• неструктурированные поля

• дублирование логики

Если поиск по базе плохой – сначала нужно исправить схему БД, а не добавлять эмбеддинги.

31.1 Область применимости AI

Интерпретация:

Сложность	Данных мало	Данных много
Простая	Код	Код
Сложная	Исследование	AI

AI оправдан только в правом нижнем углу. Это упрощённая эвристика, но она хорошо отражает практику инженерных решений.

31.2 Рост сложности системы

Финансовая функция сложности

Можно рассматривать AI как добавление фиксированных и переменных затрат:

$$Cost_{AI} = C_{data} + C_{training} + C_{integration} + C_{inference} + C_{monitoring}$$

Если:

$$Value_{AI} < Cost_{AI}$$

это плохое инженерное решение.

Чек-лист: действительно ли нужен AI?

Перед тем как внедрять модель, задайте 7 вопросов:

1. Можно ли описать задачу набором правил?

2. Есть ли явная формула?

3. Достаточно ли данных?

4. Требуется ли стохастичность?

5. Можно ли улучшить схему БД вместо внедрения ML?

6. Требуется ли 100% воспроизводимость?

7. Окупит ли выигрыш сложность?

Если на первые два вопроса ответ "да" – AI чаще всего не нужен.

Где AI действительно оправдан

AI нужен, когда:

• высокая размерность данных

• нелинейные зависимости

• невозможно сформулировать правила

• большой объём исторических данных

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

Например:

• ранжирование документов по семантике

• детекция мошенничества

• генерация текста

• обработка изображений

Главная мысль

AI – это инструмент для работы с неопределённостью и сложными зависимостями в данных.

Если неопределённости нет – не нужен и AI.

Сильный инженер не тот, кто внедрил модель, а тот, кто понял, что модель не нужна.

Инженерная зрелость

В мире, где AI стал модным словом, настоящая экспертиза проявляется в способности сказать:

Здесь достаточно 20 строк PHP.

Иногда самая умная архитектура – это отсутствие нейросети.

И это не анти-AI позиция.

Это позиция зрелой инженерии.