TL;DR. Финансовая модель в таблице разваливается при смене периода расчёта. Я честно старался, был аккуратен как мог, но период в модели хранится в геометрии листа: колонка — это месяц, а формулы адресуют ячейки по абсолютным координатам. На Хабре на эту боль есть два описанных ответа, оба уходят от таблиц: перенести логику в OLAP-куб с семантическим слоем или написать модель на Python. Здесь описан третий: оставить табличный интерфейс, но вынести диапазон и период в параметры модели, а адресацию перевести с координат ячеек на имена строк и колонок. Перевод модели из 10 листов с месяцев на кварталы стоит тогда 2 действия вместо 460–3060 — расчёт по шагам приведён в тексте.

Крупный промышленный холдинг разослал по рынку анкету: больше 130 критериев к «умной таблице», которая должна заменить у него Excel. Мы её заполнили, защитили перед архитектором и службой безопасности, подали коммерческое предложение — и не получили даже отказа. Просто тишина. Разбор этого случая — ниже, и он объясняет, почему так заканчивается почти всегда.

Разберем также других кандидатов — что с ними не так и почему они безнадежны.

Я оценил доработку учётной системы в 300 часов, заказчик ответил, что это очень много. Я для него посчитал тот же объём тремя независимыми способами: снизу вверх по пользовательским действиям, через функциональные точки с отраслевыми показателями производительности ISBSG и через COCOMO II. Результат оказался обратным ожидаемому.

Коротко, о чём речь, — для тех, кто пришёл по слову «Яндекс» и предыстории не знает. Когда ИИ-ассистент помогает чинить баг, самое ценное — не сочинить ответ с нуля, а вспомнить: похожий симптом уже разбирали, вот issue, вот причина, вот PR с фиксом. Вопрос ровно один — достаёт ли ассистент это прошлое решение из памяти. Мы это померили на своём корпусе тикетов и получили две цифры. Обычный семантический поиск (по смыслу слов) находит нужный прошлый фикс по симптому лишь в 38% случаев; обход явных причинных связей «issue → закрывший его PR» — в 87%. То есть сходство слов упирается в треть, а явные связи поднимают recall в разы.

Сразу отвечаю на вопрос, который вы задали бы в первом же комментарии: а почему не pgvector?

Короткий ответ: ровно то, что pgvector делает хорошо — генерацию кандидатов (найти top‑k ближайших по косинусу) — мы и советуем отдавать pgvector, если он у вас есть. Свой ANN мы написали, потому что (1) pgvector есть не везде, где должна работать наша память, и (2) самое ценное в нашей задаче — вообще не генерация кандидатов. Про это вся статья, так что давайте по порядку.

«Bad CaRMa» — глава из Dreaming in Code Скотта Розенберга (каламбур на CRM и «карму») про CRM-систему Vision в компании Upstart. Архитектор задумал предельно гибкую схему: одна-единственная таблица DATA, куда сложили все 150+ бизнес-сущностей — 240+ колонок с именами вроде string82 и numeric31, метаданные и данные вперемешку. Схему ведь больше «никогда не придётся менять».

На днях наш агент собрался дежурно отчитаться об успехе. Прежде чем нажать «готово», он сверился с собственной памятью — и нашёл там запись из прошлой сессии: эту идею он уже проверял на реальных данных, и она провалилась. Он остановил сам себя, до ложного отчёта.

Это не рекламная зарисовка, это лог из жизни. Ниже — два таких лога подряд, и во втором память заставила нас выбросить фичу, которой мы гордились.

Про GEO (Generative Engine Optimization) на Хабре уже много писали: разметка schema.org, доступный HTML, таблицы вместо простыни текста, чек-листы «как попасть в нейровыдачу». Это тактика, а вопрос интереснее на уровне механики: чем ранжирование в рекламном аукционе в принципе похоже на то, как модель что процитирует, и как за счёт этого сходства писать один текст, который работает в обеих системах, а не гнаться за двумя разными зайцами.

У рекламного аукциона и у ответа ИИ-агента всё больше общего, и чистая ИИ-выдача неизбежно потеряет свою прелесть, как ранее потеряли её электронная почта, мессенджеры, телефон и поисковики.

Задача широко знакома в узких кругах: наш каталог товаров встречается с каталогом контрагента — по сути одни и те же позиции, но названы по-разному. Надо найти совпадения и предоставить коллегам список подходящих наших артикулов для каждой их позиции.

В разобранном ниже случае это картриджи: 22 тысячи записей у контрагента против сотен тысяч наших номенклатур. Для такой задачи матерый программист берёт Elasticsearch, алгоритмы нечёткого поиска и тратит много времени, иногда в меру матерясь. Здесь подбор ведется с помощью токенизации, запросами в стиле no-code и без ИИ.

Предельная унификация a.k.a. IDEAV — хранение вообще всего как список Entity — Attribute — Value с дополнительным полем ID. Звучит пугающе, но реализация скрыта под капотом, а снаружи нам доступен максимально родной и дружественный интерфейс.

Бум No-code начался в 2022 году, и сейчас многие компании стараются так или иначе внедрить функционал «low-code» в свои продукты. У участников IT-индустрии пока нет согласия о границах применимости технологий «без кода», хотя адепты этих технологий обещают, что они позволят создавать практически любые приложения.

В этой заметке мы рассмотрим один из основных аспектов создания приложений – его масштабируемость в средней и дальней перспективе. Для этого сам продукт под капотом должен быть построен на чем-то более мощном, чем MS Excel, Airtable, Notion и Make, и такие продукты уже есть на рынке.

Фатальные проблемы масштабируемости проявляются с ростом объемов данных и количества пользователей, которые с ними работают – с этого мы и начнём.

Архитектура фон Неймана. Существующая архитектура и основанные на ней подходы к развитию аппаратного и программного обеспечения, очевидно, устарели. Это приводит к очень низкому КПД используемых ресурсов и неоправданно большим затратам на единицу полезного действия. Большую часть времени современные компьютеры решают искусственно созданные проблемы, порожденные, в частности, привязкой к принципам построения вычислительных машин времен середины прошлого века.