Hacker News Digest

Люди слишком уверены в себе. В коде это проявляется так:

if currentLocation.distance(to: target) < 100 {
    print("Вы прибыли!") // А точно ли? 🤨

GPS-координаты приблизительны, но Bool требует выбора. Мы «схлопываем волновую функцию» слишком рано.

В 2014 г. исследователи предложили тип Uncertain<T>, встроенный в систему типов. Я портировал идею на Swift:

import Uncertain

let loc = Uncertain<CLLocation>.from(currentLocation)
let nearby = loc.distance(to: target) < 100
if nearby.probability(exceeds: 0.95) {
    print("Вы прибыли!") // с 95 % уверенности
}

Сравнение возвращает не Bool, а Uncertain<Bool> — вероятность истинности. Под капотом используется распределение Рэлея и метод Монте-Карло; выборка происходит только при необходимости, а SPRT экономит вычисления.

let speed = 400 / Uncertain<Double>.normal(mean: 60, sd: 5)
let ok = speed < 6
print(ok.probability(exceeds: 0.9))

Такой подход делает неопределённость первоклассной и заставляет писать более умный код.

• Обсуждение крутится вокруг идеи «Uncertain<T>» — типа данных, который носит и распространяет неопределённость (ошибки, распределения вероятностей) через обычные вычисления.
• Участники вспоминают похожие подходы: interval arithmetic, вероятностное программирование, fuzzy logic, а также библиотеки Boost, gvar, monad-bayes и Pyro.
• Отмечают, что GPS-ошибки редко бывают круглыми и независимыми; важно учитывать ковариацию и корреляции между переменными.
• Кто-то мечтает о таблицах, где можно вводить «1 m ± 10 cm» и получать правильную пропагацию погрешностей, а кто-то — о языках, где «Uncertain» был бы типом по умолчанию.
• Главный вопрос: почему, несмотря на множество реализаций, такие типы всё ещё не стали мейнстримом в продакшене.

Строим продукты ИИ в эпоху вероятностей

Мы живём в момент, когда инструменты обогнали наши модели их понимания. ИИ изменил саму природу софта: вместо детерминированной функции F: X → Y мы получаем статистическое распределение.

Классическая эра

До ИИ продукты были предсказуемы: нажал «отправить» — сообщение ушло. Именно поэтому вся отрасль строилась на 100 % надёжности: SLO-дэшборды, тесты, аккуратные рефакторинги. PM и дизайн тоже сводились к прокачке воронок с заранее заданными входами и целями.

Новая реальность

С ИИ выход y стал вероятностным: один и тот же промпт может дать разные ответы. Это ломает привычные процессы:

• Инженерия перестаёт быть «написать код → проверить тесты». Теперь нужно управлять распределениями, подбирать промпты, валидировать выборки.
• Продукт больше не сводится к фиксированному набору фич. Модель сама генерирует новые пути ценности, а цели могут меняться по ходу использования.
• Организация требует новых ролей: «prompt engineer», «eval lead», «AI safety analyst».

Что делать

1. Отказаться от 100 % SLO. Достаточно 95 % качества при 10× скорости релизов.
2. Оценивать не функцию, а распределение. A/B тесты уступают место оценке статистических хвостов.
3. Строить обратную связь в цикл. Пользовательские данные теперь не просто метрика, а способ «дообучать» поведение модели на лету.

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

• Критики считают статью псевдонаучной: излишнее математическое оформление, «LinkedIn-философия» и игнорирование необходимости детерминизма в критичных системах.
• Автору вменяют ошибку: вероятностная система не является функцией, а «переход к квантовой теории» называют переходом к недетерминизму, а не «вероятностному детерминизму».
• Многие напоминают, что человечество всегда строило гибкие инструменты; жёсткая детерминированность ПО — скорее исключение, и будущее, вероятно, объединит детерминированные обвязки с вероятностными ядрами.
• Ряд участников подчёркивает: текущие LLM-агенты ненадёжны, «GPU-powered bullshit engine» не заменит проверенную инженерную практику, а «переписывать всё каждые три недели» — нереалистично.

Dyna — декларативный логический язык с весами для исследователей машинного обучения.
Он позволяет описывать что вычислять, не заботясь о как. Примеры:

c(I,K) += a(I,J) * b(J,K).          % умножение матриц
fib(N) := fib(N-1)+fib(N-2).       % числа Фибоначчи
phrase(X,I,K) max= phrase(Y,I,J)*phrase(Z,J,K)*rule(X,Y,Z).  % CKY-разбор

История: проект начат в 2004 для сокращения разрыва между математикой и кодом.

• Dyna 1.0 добавил произвольные полукольца к Datalog.
• Dyna 2.0 убрал ограничение на единое полукольцо, разрешил свободные переменные, ленивые и энергичные вычисления, наследование через dynabases.

Актуальные исследования

• Реализация через реляционную алгебру и перезапись термов.
• Использование обучения с подкреплением для выбора оптимального порядка вычислений.

Ключевые статьи

• PhD M. Francis-Landau «Declarative Programming Via Term Rewriting» (2024).

• Автор рад, что его PhD-исследование (язык Dyna3) попало на Hacker News.
• Dyna3 — это кложурная реализация Dyna, JIT-компилятор и «артефакт из будущего» по ощущениям читателей.
• Язык обобщает Datalog на произвольные полукольца, позволяя вероятностные выводы и динамическое программирование; схож со Scallop, но Scallop ориентирован на дифференцируемость и интеграцию с нейросетями.
• Пользователи спрашивают про «max=», «*» и связь с Prolog-грамматиками; Dyna использует переписывание термов с весами.
• Есть Python-, Clojure- и Java-API, но для продакшена нужны дополнительные годы разработки.