Так-так-так... Топ-менеджмент все еще в восторге, а команды все так же в окопах.

Wharton School изучили последние ~три года внедрений AI в бэкенд системы энтерпрайза.
Пишут такие цифры – 56% VP думают что они впереди рынка (и всей планеты), но только 28% менеджеров среднего звена с этим согласны.
Еще хуже с ROI, точнее с его субъективными оценками – 81% топов "видят позитив", а овнеры, что ближе к земле, менее "ai счастливы" – уже на 69%.

16% менеджеров более скептично настроены и считают что пока просто "рано судить" (против 8% так же настроенных VP).

Проблема, конечно не столько (и вообще) в технологии - сколько в разрыве стратегии и реальности – топы до сих пор в плотной эхокамере hype составляющей.

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

Самое интересное, что компании естестванным образом все чаще требуют AI-навыки при найме, но снизили инвестиции в обучение сотрудников на 8% по сравнению с прошлым годом. 🤔

Вывод делается такой – эра "экспериментов" заканчивается, дальше начинается эра "измеряемого ускорения" (Репорт так и озаглавлен – ACCOUNTABLE ACCELERATION: GEN AI FAST-TRACKS INTO THE ENTERPRISE) где практика, метрики, и реально рабочие решения становятся главным предметом внимания.

И это хорошо. Много более адекватный и взрослый подход.

***

Что еще интересного в отчете?

- большая часть компаний все таки видят ROI от AI (75%)
- малые компании (<$250M) получают ROI быстрее гигантов
- 43% лидеров продолжают боятся что AI сделает команды тупее
- а маркетинг и менеджмент больше всех страдают с разработкой рабочих AI решений.

Но последний пункт... Почему? Ведь казалось что эта область быстрее всех получит выхлоп от AI – генерируй контент планы, стратегии... Но нет.

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

***

Финальная мораль такова – уже до менеджеров докатывается боль. Все большая часть индустрии осознает что AI системы это не про "просто дернуть API", и что переизобрести с кондачка СhatGpt не так то и просто.

Приходит понимание ценности разработки архитектур, тестирования, целеориентированности на результат.

Открытым вопросом остается – где брать специалистов? 🤔
Если боль вам знакома, то приходите на консультацию 😌
@m0n0x41d


Источники:
- hackernoon
- Wharton School Report

Чат-бот аптеки упорно палил бюджет

Коллега из е-комм аутсорса делал AI-поисковик для португальской аптеки:

- "Какое лекарство от мигрени?"
- "Чем лечить кашель ребенка?"
- "Где купить антидепрессанты?"

Внутри был конвейер из регулярных выражений, которые собирают контекст из базы знаний и отправляют в gemini на каждый запрос 😱

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

Было понимание что строят не то, и что нужно унифицированное решение.

А решение простое - по моему совету подружили pgvector в postgresql (которую и так почти у каждого клиента разворачивают):

1. Намолотили эмбединги через fastembed (из логов + часть нагенерили с LLM)
2. Входящий запрос → эмбеддинг → поиск похожих (cosine similarity)
3. Схожесть > 0.92 → возврат из кэша ¯\_(ツ)_/¯
4. В противном случае → LLM вызов + сохранение в кэш

Классика :)

Результаты приятные:

- ~7 из 10 вопросов попадают
- Траты на токены снизились больше чем в половину
- Задержка 800ms → 80-100ms
- Клиенты счастливы, ура!

Решение на эмбеддингах лучше чем регулярки. Но, к сожалению, не работает (или работают плохо) если ответы сильно зависят от контекста диалога, данные часто и сильно меняются, или работаем с высокой уникальностью входных данных.

Для FAQ, поиска по продуктам, документации - классно!

Ребята почему то боялись пробовать, хотя читали про RAG и семантический поиск.

Если у вас хотя бы отдаленно похожая проблема/задача – не бойтесь и приходите ко мне за консультаций
@m0n0x41d 💗

#ai_on_backend

Проблема: векторные базы ищут по косинусной близости или гибридно – и то и другое связей между данными не понимает.

Запрос "найди все контракты с японскими поставщиками" возвращает случайные японские документы (Манга Берсерк?), а не логические связи между поставщиками и контрактами.

Это достаточно легко может превратиться в черную коробку — система находит что-то похожее, но не то что нужно. Бизнес платит за галлюцинации, а разработчикам сложно отладить систему. 😨

Почему так происходит? Ну "близость в векторном пространстве" это вообще не про смысловую связность, а про статистическую корреляцию в данных на которых обучалась эмбеддинг модель (паттерны совместной встречаемости токенов). Если проще, то документы могут быть семантически близки, но контекстуально далеки.

Возможное решение – Knowledge Graph RAG

Вместо тупого поиска по косинусной близости строим граф связей между сущностями в документах. Каждый узел в графе — это конкретная сущность (компания, контракт, персона), а ребра — установленная связь.

Как это работает на практике:

1. LLM анализирует документы и создает структурированный граф, формирует "долгосрочную память" (Да, вдохновлено белковыми мозгами)
2. Вместо косинусной близости делаем траверс по графу с учетом связей
3. В результате система "понимает" не только что искать, но и как связаны найденные данные

Главный профит тут это прозрачность и наблюдаемость. Становится возможным отслеживать весь путь решения и рассуждать о том как модель выбирала конкретные документы.

Большая прозрачность в проде означает:

- Более понятный дебаг – можно проследить путь обхода графа, в отличие от малопрозрачных векторных пространств (почему оно вообще сметчилось?!)
- Повышаем нашу способность наблюдать, понимать и объяснять логику решения
- Некоторое снижение рисков галлюцинаций – ведь данные такая система должна вытаскивать более релевантные

Но честно, сам процесс построения графа может вносить ошибки – LLM может неправильно извлечь сущности или связи между ними. Это просто смещает проблему с retrieval на extraction.

Microsoft уже показала в своем прошлогоднем GraphRAG исследовании, что такой подход улучшает точность в сложных кейсах с multi-hop reasoning.

Тут как всегда есть компромисы – построение графов знаний может требовать более емкой предварительной обработки данных и более сложной архитектуры чем обычный векторный поиск.

Как я уже писал вчера – для простых кейсов (FAQ, документация) обычный векторный поиск часто хорош и достаточен. GraphRAG имеет смысл для структурированных запросов с множественными связями между сущностями. А еще, если свернуть не туда то, переусложить граф, то наблюдаемость... будет не такой уж и хорошей :) Разбираться в запутанных графах то еще удовольствие.

Еще посмотреть по теме:
- mem0
- Cortex
- fast-graphrag
- Cognee

---

Если пред вами стоит задача построить внедрить на бекенд AI систему с памятью – приходите!
Я с удовольствием помогу вам в разработке @m0n0x41d 💗

Ваша новая AI-система на моднейшем no-code конструкторе (который вы выбрали калассического внедрения на бэкенд) обходится в несколько штук баксов, но не может получить данные из ERP 2010 года?

Бизнес очень хочет AI-ассистента, который знает историю заказов за последние 10 лет. Проблема: ERP нормально работает только на SOAP, база данных - Oracle 11g, а документация - уволившийся в 2019 году архитектор.

Команда бодро пытается построить "мосты" между старым и новым.

И каждый узелок в этих мостах - новая точка отказа. Каждый спринт (или может быть день?) - новый баг в интеграции 🐛

(Если вы никогда не были в такой потогонке - вам чудестным образом продолжает везти.)

Через 3 месяца система кое как работает. Данные теряются, ответы неполные, бизнес недоволен. Колумбийские интеграторы-аутсорсеры выставляют счет за 200 часов потраченных на "адаптации legacy систем". И не придерешься...

Это уже не просто "технический долг", а практически полное отсутствие enterprise/legacy integration strategy.

Знакомый ужастик? Приходите на консультацию, разберем вашу архитектуру и найдем точки интеграции, меня ораклом не напугаешь
@m0n0x41d

#ai_on_backend

Хочется Schema Guided Reasoning но на компилируемом языке c сильными гарантиями системы типов?

Cкомпилироваться – я дам
сильные типы я не дам 😏
(ну или отчасти)

Вот тут можно посмотреть порт SGR Demo Рината на go -> click me

***

Это просто демка, но самая полезная функция тут (в прикладном смысле конечно) с великолепной сигнатурой...

GenerateSchema[T any]() any

А вы думали? Это вам не на Колвиновском Пидантике в парке гулять 🙂

Не смотря на небольшую корявость – все равно хорошо. Приятно иметь компактные бинарники на бэкендне, да еще и с AI внутри. Go шустрый и в целом на нем можно успшено строить качественные AI платформы!

#ai_on_backend

pgvector в туториалах (и часто в моих постах тоже) выглядит идеально: добавил расширение, создал индекс, поиск работает – считай вот и внедрили AI на бэкенд 🥂

В большом проде всё иначе. Я смело использую pgvector когда знаю – тут есть, был и будет постгресс, датасет до ~100-200K векторов, и тут не будет резких пивотов и приростов трафика.

Потому что за этими границами резко начинается веселье.

Проблема №1: Бесконечный ад тюнинга индексов

IVFFlat деградирует со временем - у него падает точность поиска, и периодически надо пересобирать. HNSW на огромных датасетах может жрать 10+ гигов оперативки на билд. Для 1M векторов размерности 384 это дело займет минуты, а вот для 10M+ векторов, например, размерности 1536 – часы. При этом ваша база должна продолжать обслуживать запросы.

Решать это можно по всякому, например писать в отдельную таблицу, строить индекс "офлайн", делать свопы. Ну или держать два инекса одновременно ¯\_(ツ)_/¯

pgvector 0.7.0+ улучшил параллельную пересборку для HNSW, но проблема масштаба все равно остается. Настраивать ef_construction (грубо говоря, это параметр который регулирует "качество" грава HNSW индекса) приходится методом тыка – чем выше значение тем, очевидно - дольше билд.

Проблема №2: Планировщик запросов не понимает векторы

Хорошо оптимизированный запрос: ~50ms. Плохо оптимизированный: ~5 секунд. Пу-пу-пу. Разница в 100 раз на одних и тех же данных, потому что планировщик постгресса вообще не понимает кост модели для векторных операций.

Фильтруете после поиска – получаете неполные результаты. Фильтруете до поиска – перебираете миллионы векторов. Золотой середины нет, приходится тюнить каждый запрос руками со всеми вытекающими из остальных пунктов.

Проблема №3: Добавление данных в реальном времени

IVFFlat: быстрые вставки, но без пересборки новые вектора попадают в неоптимальные кластеры – точность поиска деградирует. HNSW: каждая вставка обновляет граф, вызывает блокировки, всплеск записей в базе и снова выжирает память. Ни один из индексов не любит высокую нагрузку на запись, векторные не исключение.

Что в итоге:

Либо раздувается буфер базы в разы (настраивать maintenance_work_mem и VACUUM помогает, но не сильно), либо принимаете "eventual consistency" (документы не ищутся N минут после добавления), либо строите сложную инфраструктуру с репликами и staging-таблицами/базами (удачи с поиском хорошего dba.)

Нужен комбинированный поиск (векторный + полнотекстовый)? Придётся реализовывать самим – взвешивать оценки от разных алгоритмов, нормализовать их, комбинировать результаты (RRF – Reciprocal Rank Fusion один из подходов, но это всё равно код, который надо писать и поддерживать).

Про альтернативы

Специализированные векторные БД (Qdrant, Weaviate, Milvus, Chroma и тд) решают часть проблем, но естественным образом добавляют свой оверхед на поддержку – ещё одна БД в стеке, синхронизация данных, мониторинг и пр. Поэтому я считаю что для небольших проектов с постгрессом в стеке pgvector всё таки разумный выбор.

Я уже писал про Knowledge Graph RAG как альтернативу чёрному ящику векторного поиска. Напомню – близость в векторном пространстве ≠ смысловая связь. А ещё векторный поиск очень сложно дебажить в production. А еще... вы точно уверены что индекс все таки не вырастет x200 раз в течении пары-тройки лет?

Мораль:

pgvector работает. Но его операционная поддержка и особенности (впрочем как и любой другой зависимости в стеке) часто недооценивается на этапе выбора инструментов. Если у вас <100-200K векторов, постоянная инфраструктура и нет хайлоада на запись – смело берите. Дальше считайте TCO с учётом инженерного времени.

Со всем этим планированием и оценкой я помогаю на консультациях, пишите в личку @m0n0x41d

Целый квартал внедряешь AI на бэкенд. Продумываешь оркестрацию, пишешь промпты, прикручиваешь и откручиваешь тулы. Тестируешь, фиксишь пограничные случаи. Выкатываешь в прод. Работает.

Через два месяца выходит новая модель. Большая часть архитектуры превращается в легаси.

В этом году примеров была масса, вспомните хотя бы последний горячий релиз GPT-5 и как круто начал на ней работать курсор.

Новые LLM могут менять поведение AI системы непредсказуемо. Иногда хуже. Иногда наоборот становится много лучше — выходит реально умная модель и твоя сложная оркестрация оказывается вообще не нужна.

Смена моделей не похожа на framework churn во фронтенде. Это фундаментально хуже. Нет ченджлогов, гайдов или автоматической миграции. Система может быть просто завязана на чёрный ящик.

---

Разработчики не переписывают софт под новую версию PostgreSQL.
DevOps не пересобирают всю инфру под новый Kubernetes.

Но AI-системы часто строят как монолит вокруг модели.

Чем это отличается от платформы которая в процессе разработки смертельным узлом завязалась на Stripe, и другие платежные системы не внедряет годами, не смотря на просьбы клиентов? (не внедряет не сколько потому что все равно, а потому что игра не стоит свеч – переписывать слишком много, ну или просто не знают как переписать, чтобы ничего не сломать)

Проблема не в том, что модели меняются.
Проблема в том, что модель делают частью big-ball-of-mud архитектуры.

Правильный подход: модель = внешняя зависимость. Как БД. Как API.

Не "система на GPT". Система с LLM-модулем.

Как такое строить:

1. Model-agnostic контракты — система не знает что внутри Claude или GPT. Только контракты входа-выхода.
2. Тестируйте внешнее поведение — модель меняется, промпты меняются. Eval тесты остаются.
3. Изолируйте model-specific логику — оркестрация, память, планирование живут отдельно от генерации токенов и от ключевой бизнес логики.
4. Версионируй это, версионируй то — промпты, конфиги, eval датасеты. Откатиться должно быть возможным намного быстрее чем тушить пожар.

Это не защита от переписывания. Это защита от того, чтобы переписывание не превращалось в спринты боли.

Разрабатываете AI систему и хотите обсудить архитектуру которая переживёт GPT-6?
Приходите на консультацию @m0n0x41d 💗

Многие начинающие AI-инженеры, программисты, предпринимающие первые попытки внедрения AI в формате «разговорный интерфейс», допускают болезненную ошибку – всегда делают поддержку контекста диалога.

Контекст распухает, биллинг за токены вызывает дрожь в пятках.

(цитирую: "Алерт от порогов в OpenAI пришёл на 2 недели раньше чем мы рассчитывали.")

А решение часто на виду, просто оно контринтутивно – не делать поддержку контекста диалога вообще.
Особенно для MVP.

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

Когда вы и ваша команда думаете над новой фичей/продуктом – не уходите на уровень реализации прежде, чем хотя бы немного формально опишете сценарии использования.

Если вы испытываете сложности со своим AI-проектом – Приходите на консультацию!
Разберёмся где сэкономить и сделать надёжнее
@m0n0x41d ❤️

Вы сами не до конца понимаете что делает ваш AI модуль на бекенде?

Ничего, похоже это "нормально" в настоящих реалиях.

Я не открою новых секретов, арка уже классическая – чтобы четко понимать что делает ваша AI система нужна понятная, читаемая, и хотя-бы немного формальная спецификация/дока.

Ключевые слова тут – "хотя-бы немного", потому что я прекрасно понимаю ритмы команд, особенно стартапов. Это ведь норма и база – быстро создавать MVP и итерироваться.

Проблема в том что часто не происходит своевременная смена лыж, и разработка продолжается в режиме бесконечного интуитивного "творчества."

Минимальный формальный подход тут возможен такой – смотреть на то что именно система должна делать – не в ваших фантазиях, и не в фантазиях ваших клиентов, а что именно решается в реальности, вот в той где бьешься мезинцем об угол стола.

Так что гораздо выгоднее (при том в любой перспективе) немного притормозить и рассмотреть фичи именно в функциональном разрезе.

Например оказывается, что несколько логических "веток" пайплайна извлекающего намерения пользователя вовсе не разные ветки, потому что по итогу заканчиваются в очень похожей, или вообще в одной и той-же бизнес логике.

Если вовремя это не исправить, это потенциальная дорога в наслоение неоптимизированных концепций в систему и промпт(ы), а значит – дорога в галлюцинации, дорогую и медленную разработку в будущем.

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

Твист в том что это удивительно редкий навык - вовремя остановиться и переключиться на стратегическую работу.

Проведите вот такое упражнение:

Возьмите свою AI систему и для каждой ее "фичи" выпишите одно предложение - что она делает для конечного пользователя. Если предложения похожи - возможно у вас дубликаты.

Приходите на консультацию, разберемся с любыми "реальностями"!
@m0n0x41d 💗

СТО в вашем стартапе на сегодняшнем мите сказал: "Нам в команде хватит 3 сеньоров вместо 10 разработчиков".

Возможно он не шутит.

Скорее всего вы уже забыли про исследование METR, где обнаружилось что AI в прикладной работе разработчиков часто замедляет, а не ускоряет.

А вот свежее от Anthropic – на базе 100K разговоров с Claude 132-ух инженеров внутри компании.

Результат - 80% экономии времени. Дарио Амодей говорит: "70-80-90% кода в Anthropic пишет Claude" 👀

Один из их инженеров: "Такое чувство, что я прихожу на работу каждый день, чтобы самого себя этой же работы лишить".

Как так?

METR: AI замедляет на 19%
Anthropic: AI ускоряет на 80%

Разница в 99 процентных пунктов. Кто врёт?

Никто.

Это не про инструмент. Это про то, как мы работаем.

Вот как это движение в правильную сторону выглядит на практике:

Anthropic сегодня анонсировали прокаченный Claude + Slack. Тегаешь @Claude в треде - и он теперь решает сам: либо просто ответить в контексте, либо автоматически создать сессию Claude Code и делегировать задачу туда.

От алерта до PR с минимальным участием человека.

Раньше баги или отправлялись в вечный беклог, или лениво копились в "in progress" и нагружали и без того уставших разработчиков дополнительным переключением внимания.

Просто METR измеряли "дали разработчику Cursor и смотрим что будет". А Anthropic измеряли AI, встроенный в процессы разработки, скорее всего еще и с довольно строгой инженерной культурой и методами работы с этим AI.

Вот разница.

Первое, это когда вы купили дорогой инструмент и ждёте магии. А второе, это когда вы перестроили процессы и методы работы под сильные стороны AI, именно то за что я всю дорогу топлю в этом блоге.

А теперь представьте недалекое будущее:

Команда из 10 разработчиков: -> 7 фиксят техдолг, баги, клепают мелкие круд задачи → 3 синьора/техлида проектируют новое

VS

Команда ТОЛЬКО из тех самых 3 сеньоров++ с Claude: -> Claude фиксит техдолг, баги, круд (тегаешь @claude в Slack с Sentry алертами) -> 3 инженера проектируют новые фичи и решения

Производительность выше. Затраты ниже. И да, очень гурбо, но ~7 человек больше не нужны.

Эти ресурсы можно перераспределить или на маркетинг, или компенсировать за повышенное число закрываемых задач мега-сеньорам 🙂

Будем честны, AI помогает решать больше задач параллельно, но мозги все равно знатно от этого устают – никто не выкидвает инженера из цикла, ему все равно ревьювить PR от LLM и прочее.

Да, сейчас в интеграции Claude Code в слак есть баг - контекст треда не передаётся в сессию. Но это просто баг. Его исправят за неделю, максимум две. (Скорее всего намного быстрее – ибо это ломает смысл интеграции более чем полностью)

Так что будущее вот вот наступит, да?

И это будущее не в том, чтобы дать каждому разработчику AI-ассистента и ждать не пойми чего. Ускорение генерации плохого кода мы уже проходили.

Будущее в том, чтобы встроить AI в процессы: от алерта до PR с минимальным участием человека.

Кстати, в METR исследовании не до конца понятна компетенция разработчиков в системном мышлении и работе с LLM ассистентами. Возможно, проблема не в AI, а в том, как люди с ним работают.

Даёте команде AI-инструменты и ждёте magic? Получите -19%.
Встраиваете AI в процессы? Получите +80%.

Разница не в инструментах. Разница в том, как вы их используете.

Не знаете, как это делать правильно?
Приходите на консультацию: @m0n0x41d ❤️

Здравствуйте дорогие подписчики! У меня для вас обещанный лонгрид, и обещаннный инструмент!

Последние несколько дней я очень взволнован и впечатлен этой штуковиной... Итак, поехали 🤟

***

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

В прошлое воскресенье я участвовал в семинаре Мастерской Инженеров Менеджеров, где Анатолий Левенчук рассказывал про First Principles Framework (FPF) – гримуар системного мышления над которым он работает последние месяцы.

Я очень вдохновился и сделал Crucible Code 🐸

Название крутое (ну мне так кажется), но это "просто" набор команд для Claude Code, который превращает его из отличного codding ассистента в методичного системного мыслителя.

И вас тоже за собой по этой дорожке тянет❗️

FPF очень большой, и очень сложный. Целиком запихнуть его в рамки команд или скиллов Claude Code – невозможно. И наверное имеет мало смысла, если мы хотим чтобы Claude Code не отупел от заполнения контекста и не потерял продуктивность.

Но я сделал MVP настолько следующим FPF, насколько смог.

И знаете что? Оно работает просто ЗАМЕЧАТЕЛЬНО 😮

Я начинал писать этот лонгрид когда была еще только первая версия Crucible Code, и в ней было еще меньше кусочков FPF... А сейчас на гитхабе последняя – 2.1.0.

В этой версии он стал ещё умнее и стабильнее.

В статье по ссылке выше можно прочитать больше, в README.md FPF – еще больше :)

Совсем в паре слов – Crucible Code это не автопилот и не очередная попытка насадить свору "специальных агентов".

Это скорее экзоскелет для наших собственных мозгов и мыслительного процесса.

А еще это память... А еще это задокументированные решения... А еще...

Пожалуйста – пробуйте, делитесь, создавайте issues в гитхабе или пишите в личку с вопросами или предложениями!

От себя добавлю – AI Assisted Engineering с Claude Code лично для меня никогда не был так хорош и качественно продуктивен, каким он становится сейчас с Crucible Code.

@m0n0x41d

Crucible Code обновлен до 2.2.0 – теперь есть нормальный инсталлятор и поддержка для Cursor, Gemini CLI и Codex CLI!

Кажется что в ближайшее время обновлять уже нечего :)

Crucible Code в Gemini CLI и курсоре открывает новые горизонты для экспериментов

В первую очередь благодаря здоровенному контексту gemini-3-pro.

Можно исследовать поведение crucible со всей оригинальной спекой First Principles Framework в контексте (например прямо в GEMINI.md)

Правда это история скорее уже про более глубокие и широкие исследования, чем про прикладную разработку.

Хотя… кто знает?
🤷‍♂️🤷‍♂️🤷‍♂️

Первые отзывы пока делятся на две категории:

1) мне это не понятно и совсем не нужно, я и сам могу определиться с архитектурным решением
2) те кто все таки установил и дал шанс :)

А вы уже пробовали Crucible Code?

@m0n0x41d

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

Поэтому именно они занимаются внедрением AI-решений как инноваций.

Однако возникают одни и те же проблемы: ваши AI-системы фунционируют паршиво.

Вы не можете утверждать, что ваши сотрудники некомпетентны. Но они стабильно жалуются на низкую точность системы, новые ошибки и сложность поддержки. Они винят природу LLM, говорят что «галлюцинации это норма». Жалобы не прекращаются.

А бизнес требует надежных AI решений, потому что видит: у конкурентов такие решения ЕСТЬ, и они работают. Бизнесу плевать как, но вы должны сделать так же.

Только вот два ваших техлида уже третий месяц возятся, а результата все нет.

Ваши коллеги говорят: «мы использовали ChatGPT и повысили точность. Нам кажется, что мы увеличили её примерно до 96%»

Вы слышите в этой фразе дребезг?

Во-первых, они называют API OpenAI – ChatGPT, как будто это одно и то же.

Во-вторых, им кажется, что они повысили точность. У вас нет метрик.

Вы не знаете, правда ли стало лучше или просто на тестовых примерах повезло в очередной раз ¯\_(ツ)_/¯

***

Проблема в том, что AI - это одна из самых требовательных к высокой инженерной квалификации область в широком IT.

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

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

И часто непонятно: переписывать ли всю систему целиком или просто что-то конкретное изменить?

Но что?! Что надо изменить, чтобы повысилась настоящая точность, а не та, которая кажется? Где вообще искать проблему, когда два senior разработчика сами не понимают, что чинить и чего от них на самом деле хотят?

Если вы оказались в подобной ситуации – давайте разберем конкретно вашу задачу и проблемы на консультации. Посмотрим и менно и в каком порядке можно сделать, чтобы перейти от «работает иногда» к «работает предсказуемо».

Оставляйте заявки здесь

@m0n0x41d ❤️

Несмотря на все усилия отдохнуть за новогодние праздники, я просто не устоял и откликнулся на задачку, с которой обратился один товарищ в личку на Реддите:

"RAG у нас работает нормально, даже отлично, но последнее время пользователи всё чаще жалуются на неактуальные ответы. Мы проверили метрики - поиск быстрый, точность высокая, достаёт вроде бы правильные документы… Только жалобы никуда не деваются, уже не знаем как дебажить"

Начали копать, что там нормально работает, а там такое… Интересное!

На первый взгляд система написана хорошо, много важных метрик (как по учебнику).

Только вот мониторили всё, кроме главного – насколько свежие данные система реально отдаёт пользователям.

База знаний долгое время была небольшой. Но когда подписали новых клиентов – стремительно выросла до 80.000+ документов (и продолжает расти, пользователи постоянно догружают контракты и прочую сопутствующую бухгалтерию.)

Тут мы нашли архитектурный баг 🐞

Раньше документов было меньше, и обновление поисковой базы делалось "в лоб" – просто пересобирали весь индекс раз в сутки ночью. Работало нормально, всех устраивало.
МVP → $$$! Какие вопросы?

На новых объёмах этот процесс стал занимать 10+ часов.
А алертов на это никто не организовал.

Так что выхоило следующее – документ обновили, например, утром, а в поиске он появится только завтра где-то к обеду! Система весь день уверенно отдаёт вчерашнюю версию... 🥲

Что мы сделали:
1. Перешли на более умное обновление (инкрементальная индексация) – теперь система обрабатывает только изменённые/новые документы, а не всю базу целиком. Да, оказывается это не очевидно, или в режиме стартапов просто забывается ¯\_(ツ)_/¯

2. Добавили приоритет свежести – при прочих равных система теперь предпочитает более свежие документы

3. Настроили мониторинг устаревания – если данные начинают "протухать", команда сразу видит алерт в слаке.

Результат по первичным оценкам такой:
- Задержка обновления снизилась с ~14 часов до ~10 минут (на самом деле меньше, это пессимистическая оценка)
- Жалобы на неактуальную информацию – пока полностью пропали, ждем!
- Никаких изменений в самой AI-модели

Мораль, думаю, тут такая: RAG может ломаться не из-за плохого AI, а из-за невидимых проблем с данными, которые попросту упустили из внимания.

Если узнаёте свою ситуацию – заполняйте короткую заявку тут, разберём!