Tri-Fort: от regression model к Construction Intelligence Engine
Команда Tri-Fort — AI-платформы для оценки стоимости строительства в Кении — несколько месяцев вела продукт через классический ML-пайплайн, но после аудита данных заморозила деплой и перешла к Construction Intelligence Engine с rule graph и reasoning traces. разбор на dev.to Это не «провал нейросети», а инженерный выбор: при малом и «грязном» датасете предметные правила надёжнее модели, обученной на чужих оценках.
ML-first: готовый продукт и стоп перед продом
Исходная схема выглядела привычно для прикладного ML: поля пользователя — локация, тип проекта, площадь, этажность, уровень отделки, предпочтения по материалам — проходили feature engineering, затем regression model выдавала прогноз стоимости.
К моменту публикации у платформы уже были API, аутентификация, отчётность и инфраструктура под продакшен. Деплой остановили после аудита: модель училась на estimated cost, а не на final actual cost — то есть воспроизводила чужие оценки, а не фактические итоги проектов.
Вывод для AI-продуктов в узкой домене: «работающий» ML-контур не гарантирует готовность к деплою, если таргет в данных не совпадает с реальностью, которую обещает продукт.
Аудит данных: когда объём обманывает
Строительные источники — BoQ, графики работ, cost books, отчёты quantity surveyor, спецификации, market research, исторические прайсы, сметы подрядчиков — на практике приходили как PDF, сканы, Excel и OCR-выгрузки, часто в нескольких ревизиях одного проекта. Для пайплайна это выглядело как разные объекты.
Команда собрала data discovery and audit pipeline: инвентаризация файлов, группировка проектов, поиск дубликатов, оценка качества OCR, cost recovery analysis, dataset readiness scoring.
Цифры после аудита жёсткие:
- из десятков документов и тысяч извлечённых строк — 9 различимых проектов;
- только у 2 есть свидетельства финальной фактической стоимости;
- остальное — оценки, не факт.
При таком балансе слабо обученная модель проигрывает domain knowledge — в их случае официальному QS cost handbook. ML сняли с приоритета; в центр поставили данные и предметные правила.
Construction Intelligence Engine: три слоя вместо одной модели
Термин Construction Intelligence Engine в материале раскрывается как гибрид трёх источников intelligence.
Handbook Intelligence. Официальный Quantity Surveying cost handbook обработан не как статичный PDF, а как структурированный knowledge source: региональные ставки, cost benchmarks, классификации зданий, стандарты измерений, корректирующие коэффициенты. Extraction pipeline превращает handbook в rule graph — регионы, rate schedules, building classes, construction categories, cost multipliers — и дальше в Cost Intelligence Engine. Числа не размазаны хардкодом по приложению: движок «рассуждает» из правил.
Historical Project Intelligence — восстановленные BoQ и проектные данные после аудита и группировки.
User Feature Intelligence — тот же пользовательский ввод через estimator, что и в ML-версии.
Текущий поток расчёта:
User Inputs → Feature Engine → Handbook Intelligence → Historical Cost Intelligence → Cost Engine → Explainable Estimate
Explainable estimate вместо чёрного ящика
Вместо непрозрачного прогноза система выдаёт reasoning traces — цепочку поправок с обоснованием. Пример из материала:
- базовая ставка 54 000 KES/sqm;
- локация Nairobi +20%;
- luxury finish +15%;
- двухэтажность +8%;
- historical correction −2%;
- итоговый пример оценки — KES 18 400 000 с пояснением каждого шага.
Сравнительного бенчмарка «ML-only vs hybrid» с метриками accuracy или latency автор не приводит — аргумент строится на стабильности, доверии пользователя и прозрачности, а не на таблице A/B-тестов.
Стек и инженерная сдержанность
Под intelligence-слой лёг привычный продуктовый стек:
| Слой | Технологии |
|---|---|
| Backend | FastAPI, PostgreSQL, domain-driven architecture, background tasks |
| Frontend | Next.js, TypeScript, responsive dashboard |
| Infra | Docker Compose, Caddy, HTTPS automation, environment-driven config |
Деплой описан как сценарий на VPS: git pull и docker compose up -d --build без production-веток и ручных правок кода на сервере. Лицензия, open source и коммерческая модель Tri-Fort в тексте не названы — статус продукта как OSS или закрытой платформы остаётся открытым.
ML в roadmap — но только после «грязной» правды о данных
Долгосрочное видение machine learning команда не отменяет. Roadmap привязан к накоплению final accounts, completion certificates, contractor invoices, variation orders и actual project costs.
Целевая формула автора: Domain Knowledge + Historical Projects + Machine Learning + Human Explainability — AI усиливает экспертизу, а не подменяет её.
Три правила перед перезапуском:
- не доверять размеру датасета без аудита;
- при скудных данных domain knowledge важнее ML;
- пользователям нужны точные ответы, а не алгоритмы как самоцель.
Для разработчиков прикладного AI это узнаваемый паттерн: сначала доказать, что данные и предметная область выдерживают модель, и только потом возвращать ML в архитектуру — уже как усилитель, а не как единственный источник истины.
Источники
- Building Tri-Fort: Why We Abandoned Pure Machine Learning and Built a Construction Intelligence Engine Instead — dev.to, автор wolfof420street, опубликовано 18 июня 2026 г.