Collecting All Causal Knowledge
CauseNet — проект по сбору всей человеческой причинной информации из веба и отделению знаний от убеждений.
Получено 11,6 млн причинных связей (точность ≈ 83 %) из полуструктурированных и неструктурированных источников. Построен первый крупный граф причинности открытого домена.
Данные
- CauseNet-Full — полный набор (11,6 млн связей, 12,2 млн понятий, 1,8 ГБ).
- CauseNet-Precision — высокоточная выборка (200 тыс. связей, 80 тыс. понятий, 135 МБ).
- CauseNet-Sample — мини-пример (264 связи, 524 понятия, 54 КБ).
Модель
Концепты соединяются отношениями «причина → следствие».
Каждая связь снабжена метаданными: источник, предложение, шаблон, временная метка и т.д.
Примеры
{
"causal_relation": {
"cause": {"concept": "smoking"},
"effect": {"concept": "disability"}
},
"sources": [{
"type": "clueweb12_sentence",
"payload": {
"sentence": "In Canada, smoking is the most important cause of preventable illness...",
"path_pattern": "[[cause]]/N\t-nsubj\tcause/NN\t+nmod:of\t[[effect]]/N"
}
}]
}
Применение: ответы на причинные вопросы, аргументация, многошаговые выводы.
Комментарии (101)
- Критики считают идею «базы всех причин» хрупкой и излишне упрощённой: примеры вроде «человеческая деятельность → изменение климата» слишком обобщены и бесполезны.
- Многие проводят параллель с провалом проекта Cyc и предупреждают о повторении тех же ошибок.
- Упрекают отсутствие неопределённости, контекста и механизмов: «болезнь → смерть» игнорирует вероятности, временные рамки и индивидуальные условия.
- Источник — Википедия — вызывает скепсис; в базе даже встречаются ложные связи («вакцины → аутизм»), что подрывает доверие.
- Пока не ясно, для чего это нужно: прогнозы, дообучение ИИ или просто каталог «что кто-то когда-то утверждал».
Why was Apache Kafka created? 💬 Длинная дискуссия
Почему появился Apache Kafka
LinkedIn, 2012 г.
Проблема интеграции
LinkedIn нужно было передавать данные активности (лайки, просмотры, публикации) в десятки систем: антифрод, ML-модели, веб-функции, витрины, Hadoop. Эти потоки — критичная инфраструктура, а не просто аналитика.
Старые трубы
- Пакетный конвейер: приложения писали XML на HTTP-сервер; раз в час файлы собирались, парсились и грузились в Oracle + Hadoop.
- Realtime-конвейер: метрики и логи уходили в Zenoss, но туда нельзя было добавить новые данные без ручной работы, а данные были изолированы.
Общие боли
- ручное сопровождение и добавление источников;
- постоянные бэклоги;
- point-to-point архитектура без обмена между системами.
Вывод
LinkedIn понял, что нужен один надёжный, масштабируемый и универсальный «шина событий», куда пишут все, а читают кто угодно. Так родился Kafka.
Комментарии (172)
- LinkedIn отказался от Kafka и создал собственную систему Northguard из-за невозможности масштабировать 32 трлн записей/день, 17 ПБ/день и 400 тыс. топиков.
- Участники спорят: Kafka мощна для «огненных шлангов» данных и многократного потребления, но требует экспертизы и ресурсов; для большинства задач достаточно Redis, NATS, RabbitMQ.
- Названа главная фишка Kafka — возможность переигрывать сообщения и строить разные консьюмеры поверх одного лога.
- Сравнивают NATS (Jetstream) и Apache Pulsar как более лёгкие альтернативы; Redpanda тоже упоминается.
- Мнения разделились: кто-то считает Kafka переоценённой и «бюрократичной», кто-то — незаменимой для больших данных.