ivan zakutni

#ai_on_backend

MCP сервер – это не обязательно «плагин»

Типичное отношение к MCP серверам слишком часто интуитивно - это отношение как к плагину с рядом инструментов.

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

В дефолтной интуиции разработчики MCP сервера часто тоже – «навешаю ка я в него сразу весь CRUD: create_news, update_news, delete_news, get_categories, assign_category, check_duplicate...

И вот клиент захлебывается в инструментах, контекст раздувается, со всеми небезызвестными вытекающими.

***

Вот когнитивный трюк: относитесь к MCP серверу в первую очередь как к серверу.

Как к отдельной самостоятельной сущности, что отвечает за кусок бизнес-логики и инкапсулирует её, а не просто «предоставляет наружу»!

Смотрите на разработку MCP через призму DDD/bounded contexts, и естественным образом начнете принимать правильные решения в проектировании интерфейса.

Реальный пример: Делаю новостной агрегатор - дашборда для событий и алертов. Есть сущность "новость" с категориями, комментариями.

Уже достаточно, чтобы следуя «интуитивным» подходам разработать обычный такой жирненький CRUD.

По ряду причин AI на бэкенд дашборды было решено не внедрять, а подключать извне через MCP протокол.

Это значит что агент(ы) должны подписываться на свои источники и наполнять дашборду.

Немного подумав я понял что в этом MCP нужен только один инструмент — publish_news.

И всё.

Никаких get_categories, никаких апдейтов топиков, никаких манипуляций — пока они реально не потребуются.

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

Таким образом я сильно разгрузил предыдущий вариант системы, теперь есть несколько внешних агентов-сборщиков, у которых вместо 6-8 инструментов и лишних токенов в контексте - два-три инструмента!

(инструмент от дашборды для публикации, и остальные только для работы со своим источником навостей – поисковик, кравлер, gmail, отдельные rss и так далее)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Channel name was changed to «ivan zakutni»

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

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

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

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

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

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

Если вы испытываете сложности со своим AI-проектом – Приходите на консультацию!
Разберёмся где сэкономить и сделать надёжнее
@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_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_on_backend

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

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

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

***

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

GenerateSchema[T any]() any

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

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

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

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

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

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

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

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

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

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

Внедряя AI на бэкенд, или в бизнес/разработческие процессы довольно часто хочется использовать любимые и знакомые инструменты, и при этом... тоже часно - сэкономить немного на токенах :)

Поэтому я набросал небольшой прокси на расте для инструментов используюих API Антропик, который позволяет утилизировать OpenAI-like API – OpenRouter, или SelfHosted модели, или почти что угодно еще ¯\_(ツ)_/¯

https://github.com/m0n0x41d/anthropic-proxy-rs

В уже не только экспериментальных штуках некоторые открытые модели показывают себя вполне хорошо.

Настройка и запуск этого прокси простая какая пять копеек (.env файл в удобном для вас месте) и врубается простым демоном:
anthropic-proxy --daemon

а с Claude Code дружить еще проще чем с Z.AI – всего одна переменная (модели и апстрим в конфигах прокси, очевидно):

ANTHROPIC_BASE_URL=http://0.0.0.0:3000 claude

Соберу нормальные бинари в релизы если хоть кому-то пригодится.

@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-поисковик для португальской аптеки:

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

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

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

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

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

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

Классика :)

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

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

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

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

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

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

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

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

"Мы были очень осторожны и тщательно занимались контекст инженирингом, но агент все еще периодически выбирает не правильные тулы или галлюцинирует в числах или датах, хотя дату мы прямо в промп динамически пишем :("

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

– "А как вы подходили к контекст инженерингу? Чем руководствались?",
– "Ну, мы на выступлениях услышали, что надо давать модели как можно больше контекста для выполнения задачи!"
– "А как определяли, что агенту реально нужно?"
...
¯\_(ツ)_/¯

Контекстная инженерия - это не фаршировка утки яблоками.

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

А это прямой путь к галлюцинациям.

Контекстная инженерия - это в первую очередь про ограничение контекста. Определение главной роли/ответственностей агента. И уже только потом про компрессию, перекладывание файликов, выбора тулов или любые прочие прикладные реализации.

Когда проводите такое моделирование, ответы на вопрос "Что нужно в контексте на самом деле?" возникают почти сами собой.

И сделать это проще чем кажется: поставьте себя (или эксперта в домене) "на место агента" и ответьте: какие документы, инструменты, знания и иные ресурсы мне нужны для выполнения задач? Какие действия и в каком порядке я буду выполнять?

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

@m0n0x41d

#ai_on_backend

Кто-бы как не любил (или наоборот - бурно обожал Питон), но он пока остается, если не самым, то одним из самых удобных языков для быстрой разработки AI и не AI бэкенд систем.

Ну правда ведь одно удовольствие расписывать SGR на Pydantic моделях и красиво отдавать на запрос. А с Pydantic-AI еще красивее. А FastAPI, FastMCP... Ну сказка 100x разработчика!

Но по разным причинам у нас не всегда есть/оправдан Питон ¯\_(ツ)_/¯
***

Хорошо если AI компонент системы легко выделяется и можно просто "рядом" запустить его как сервис.
Плохо если AI либо уже как-то внедряли (и перевязали с бизнес логикой слишком туго), либо сам дизайн просится "по месту в модуле" в целях сохранения этой самой модульности или ее видимости.

>Например в бэкенд монолите плотно намешана работа, и надо туда нормально внедрить AI. Это просто тупо дешевле чем переписывать несколько кусков и выносить в отдельный сервис. Ну... просто ничем не оправданно.

***

Так что там с _хорошими библиотеками_ в других языках?

tl;dr – на фоне Пайдентиков Питона все не так лучезарно, но все еще неплохо. Если вы четко уверены что будете использовать OpenAI или OpenAI Compatible интерфейс, думать нечего – смотрите сразу на клиенты поддерживаемые OpenAI.

Возможно они не всегда так выразительны как хотелось бы – но Strctured Output вы там в том или ином виде найдете.
Просто потому что мейнтейнеры этих библиотек обязаны обеспечивать все API OpenAI.

Там даже коммиты на пулреквесты выглядят как-то так:

>* Add full support for Responses API

---

Чего не скажешь про чудесные и одичалые библиотеки – либо поддержка там просто отстает (ну некогда!), либо "исповедуются" безнадежно устаревшие странности-парсеры вроде baml.

И все таки... Должны же быть хорошие oss библиотеки не спонсируемые большими компаниями?

Есть! instructor на PHP!

Единственная его проблема – чрезмерная переизбыточность, как минимум в документации/примерах в гитхабе. Я чуть было не отказался от этой библиотеки пока разбирался как же все таки отправлять запросы на Strict SO :)

>instructor-php поддерживает и те самые парсеры, и подкапотные внедрения json'ов в промпты.

Но в итоге вы получаете опыт похожий на привычный brrrrr от Пайдентика в Питоне со вложенными классами/энумами и описателями полей :)
(openai-php/client не умеет в рефлексию схем из php классов, там вам придется рисовать JSON елки руками или сторонними штуками.)

@m0n0x41d

Вы конечно можете закидать меня дизлайками, но правды это не поменяет:

AI не принес никаких кардинально новых проблем/задач в программную инженерию.

По крайней мере со стороны системного и программного дизайна.

***

Ну, посудите сами - разве раньше не было проблем с постоянным тушением пожаров, вечной войной с багами, медленными и разрушительными релизами? а? 💣

Корни этих проблем всегда находятся где-то между:

- Проблем с тестированием; Либо тесты вообще не пишутся, либо они тестируют реализацию вместо интерфейсов;
- Высокой связности, при том не важно чего – псевдо-микросервисов в распределенном монолите, или модулей в монолите обыкновенном :)
- Серьезных затруднений в рассуждении о программных системах у наших разработчиков – мало кто реально осознает разницу между прикладным уровнем системы и уровнем ее дизайна;
- Низкой наблюдаемостью – не сразу понятно (или не понятно вообще), где что сломалось и как подступаться к дебагу;
- И так далее...

Какие же тут качественно новые вызовы со внедрением AI на бекенд?

Да существенно никаких.

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

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

Так что для успешной разработки AI систем вам нужно не воображение и вера в чудеса, а инженерия ¯\_(ツ)_/¯

@m0n0x41d

Ваши AI агенты все еще застревает в циклах? Тогда я иду к вам! 💃

Меня вчера все таки выдернули на короткую консультацию (очень не хотелось работать в выходные.)

по проблеме стараой, доброй и прозаичной – "нам вообще не понятно почему оно периодически проваливается в бесконечный цикл tool-call вызовов."
При этом там одна *большая модель от гугла.*

В проекте использовался LlamaIndex с примерами прямо из документации :)

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

Разобрались ровно за один часовой звонок. И вот буквально 10 минут назад мне отписались что "утром переписали, весь день тестируем и ни одного провала в циклы!"

Решили всё с помощью серебрянной-пули Schema Guided Reasoning – по каноничному примеру с выбором нужного тула (см тут.)

Никаких promp-издевательств.
Никаких бесконечных циклов.
¯\_(ツ)_/¯

В довесок приятно было услышать что ребята послушали мой "совет на закуску" и попробовали все таки модели подешевле – всё работает хо-ро-шо!

Вот она прелесть SGR - структурируешь и свое рассуждение и рассуждения LLM, решение работает если не одинаково, то как минимум предсказуемо на разных моделях.

Ну и денег можно сильно сэкономить :)

@m0n0x41d

В вашей команде слышно такую фразу – "Если ChatGPT может, значит и мы сможем!"?

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

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

Конечно, выражение очень здорово звучит, в духе стартапа! Мы можем! Вперед! Ееее! 🤟

Но одновременно с этим воодушевлением факт того что ChatGPT и OpenAI API с моделями это совершенно разные продукты опускается из внимания более чем полностью.

А заострять внимание на этой разнице важно с самого начала.

Разработчики рано или поздно это понимание обретают, когда начинают замечать разницу, в каком нибудь распознавании картинок плохого качества, например.

Только вот понимание это натурально выстрадано через стодесять переделок.

***

Когда то один веб-разработчик мне сказал – "Ну так там а чо там... Там же просто апишку open-ai дергать надо, не рокет-саенс."

Ну, конечно же не рокет-саенс. Но такое отношение недопустимо в разработке продуктовых AI решений.

ChatGPT — это система. С препроцессингом, fine-tuned промптами, какой нибудь fallback логикой, и так далее (никто не расскажет сколько там и каких примочек на самом деле :)

API — это голая модель + ваш промпт ¯\_(ツ)_/¯

Хотите результаты уровня работы ChatGPT или лучше?
Тогда проектируйте систему, а не просто дергайте API.

В каких то случаях надежное решение получается благодаря много более простым подходам. А в каких то придется и правда нагородить небольшую ракету.

Приходите на консультацию ❤️
@m0n0x41d

дешевый но хороший OCR документов.

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

Вообще, типичное такое внедрение AI на бэк с наскока – модели в проекте использовались большие (openai, google), а разультаты... Ну скажем так – результаты были неплохие, но оставляли желать лучшего.

В проекте было достаточно популярных проблем (вроде отсутствия достаточного количества eval тестов), но главной технической проблемой, по моему мнению, являлся как раз таки BAML.

Почему? Ответ прозаичен – BAML не умеет в Structured Output моделей и не хочет в него уметь. Нет SO – нет SGR. Нет SGR – нет возможности без мучений моделировать и создавать надежные AI системы.

***

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

И вот меня не покидала идея попробовать сделать OCR на маленьких VLM моделях.

Благодаря Валерию, который сейчас хостит Qwen3 VL 8B Instruct и бесплатно дает ее попробовать, я наконец закрыл этот гештальт :)

Главная цель была набросать OCR фотографий чеков;
Результат... просто отличный! ☀️

Наколеночный POC вы можете посмотреть в этом репозитории, забрать себе и попробовать запустить OCR сами.

Это очень ограниченная, простая реализация чтобы просто проверить модель. Продуктовая OCR система, разумеется, потребует некоторых важных доработок (подсказываю в REAME.md).

Но этого сниппета достаточно чтобы:

- посмотреть неплохой пример SGR
- набросать туда побольше файлов и тестов чтобы оценить качество этой или других VLM моделей предметно.

А квен этот мне очень нравится! Год-полтора назад мне сложно было представить что так дешево можно собрать вполне себе качественный и умный OCR.

@neuralstack

ai workslop часть 2.

Привет, часть 1 была тут.

А часть 2... Я начал писать ее на тему того что работает и не работает в AI ассистированном программировании. Все шло хорошо до тех пор, пока мне не попалась под руку очередная статья с откровенной брехней. А брехня это всегда золотой материал для концептуального рефакторинга :)

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

Милости прошу -≥ тыц.

TL;DR:

“10 PR в день” и “$12k на токены” - в ваккуме это красные флаги карго-культа, а не показатели продуктивности

Спецификации ≠ реальность. Код выражает инварианты системы, которые нужно понимать, а не просто генерировать

Мой эксперимент: переписывание 5k строк без просмотра кода заняло 3 дня вместо 1. На каждой задаче нужны были правки

Правильный подход: AI генерит → ты проверяешь. Human-in-the-loop это не опция а необходимость

Реальные метрики: не количество PR, а стабильность в проде, покрытие тестами и понимание кодовой базы командой

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

https://www.ai-dev.live/

Первый доклад стартует в 14:00 GMT+3

Всех ребят я читаю, и имхо – все на правильной стороне луны.
За рекламу мне никто не платил, рекомендую присоединяться от чистого сердца 💖

@neuralstack

техническое поражение в AI кодинг битве засчитываю облачному codex 😠

Решил я, значит, устроить дуель между Jules и Codex Cloud.

Остороно – Юмористическое.

Дано:

- Простецкий проект на питоне, где есть молотилка векторов, chroma, sqlite и все это обернуто в mcp сервер (ну да да, типичная AI раг на бэкенде)
- Крайней разжованный implementation_plan.md в под-директории

Задача с одинаковым oneshot промптом, tldr – "вот те репа, вот те сабдир с планом, давай делай"

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

Я, все таки, ставил на codex, ну... ну хвалят же за работу с большими блобами!?

Но уснуть я не успел 😁

Результат работы codex cloud вы видите на кринж-шоте поста. Пояснений не дает, ни в логах ни в ответах.

Jules, бедолага, бадается упорно, утром посмотрим что сделает)

@neuralstack