Когда 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_{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 позиция.

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