Практические кейсы

От теории вероятности к инженерной ответственности

В предыдущей главе мы разобрали, почему LLM ошибаются математически.

Галлюцинации, сдвиг распределения, игнорирование base rate, bias, temperature – всё это не баги, а прямое следствие базовой формулы:

\hat{x}_t = \arg\max_x P(x_t \mid x_{<t})

Модель максимизирует вероятность следующего токена.

Не истину.

Не доказуемость.

Не корректность вычислений.

И именно здесь начинается зона ответственности инженера.

Понимание формул важно, но архитектурные решения важнее. В реальной системе мы не можем позволить себе “примерно правильно”. Если вы строите:

– финансовый сервис

– security-платформу

– phishing-симулятор

– AI-ассистента для бизнеса

– образовательный продукт

то математические ошибки модели становятся уже не теоретической особенностью, а операционным риском.

В следующих кейсах мы перейдём от формул к коду. Мы посмотрим, как:

– детектировать галлюцинации

– проверять вычисления

– учитывать базовые вероятности

– снижать bias

– управлять температурой генерации

– разделять вероятностный и детерминированный слой

Все примеры будут на pure PHP и с использованием RubixML – без магии, только инженерные решения.

Эта глава не про то, “как сделать модель умнее”.

Она про то, как сделать систему над моделью надёжнее.

Именно так и строятся зрелые AI-продукты – не на доверии к LLM, а на правильной архитектуре вокруг неё.