Остановил Python сервис с моделью машинного обучения, .NET API продолжил работать и вернул HTTP 503. После восстановления Python запрос снова завершился с HTTP 200, без перезапуска основного приложения.

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

Architecture Baseline определяет границы системы и ключевые архитектурные решения. Но настоящая проверка начинается тогда, когда эта архитектура превращается в работающий код.

В этой статье про переход к первой Full Stack вертикали Enterprise GenAI Platform: React, ASP.NET Core, EF Core и PostgreSQL, модуль Chats, границы frontend и backend, observability, автоматические проверки и End-to-End acceptance.

Главный вопрос “как перейти от архитектурной модели к реализации, не разрушив её преждевременным усложнением”.

Корпоративную GenAI платформу легко начать с выбора LLM, LangChain, vector database или Kubernetes. Но до этого полезнее ответить на другие вопросы: кто имеет доступ к данным, где проходит security boundary, какие компоненты действительно нужно разделять и что должно войти в первую версию.

В статье разберу, как спроектировать корпоративную GenAI платформу до начала реализации: требования и NFR, C4, Modular Monolith, разделение.NET и Python, PostgreSQL + pgvector, RabbitMQ, LLM Gateway, ADR и границы MVP.

Хотел разобраться где заканчивается простой вызов локальной LLM и начинается backend система.

Сначала всё выглядело просто: frontend отправляет вопрос, FastAPI принимает POST /ask, backend вызывает локальную модель через Ollama и возвращает ответ. Но стало понятно: для помощника по документации этого мало. Модель отвечает, но непонятно на какие документы она опирается, какие фрагменты попали в prompt, сколько времени занял каждый этап и что делать, если индекс устарел.

В статье показываю не "как вообще устроен RAG", а путь от простого вызова локальной LLM к небольшому backend/RAG-проекту с API контрактом, request_id, логированием, sources, timings, rebuild index, negative tests и честными ограничениями.

Запустил openai/gpt-oss-20b в варианте MXFP4 GGUF на обычном ноутбуке без дискретной видеокарты: только CPU, встроенная Radeon 780M и общая оперативная память.

Тест проводился на ASUS Vivobook S 16 M3607HA: Ryzen 7 260, Radeon 780M, 32 GB DDR5 5600, Windows 11 и LM Studio 0.4.16-1 x64. Модель ноутбука указываю не ради привязки статьи к конкретному устройству, а для воспроизводимости. В таких тестах важны не только CPU и RAM, но и охлаждение, лимиты питания и shared memory у встроенной графики.

Главный вопрос был практический: можно ли реально пользоваться локальной 20B-моделью на ноутбуке с 32 GB RAM, если отдельной видеокарты нет?

Сразу оговорюсь это не научный benchmark, а пользовательский case study на конкретном железе. Проверял скорость, расход RAM/CPU/GPU, поведение при разных лимитах контекста и качество ответов на технических prompt сценариях.

Долго воспринимал Python как язык из соседнего мира. Где то там data science, pandas, ноутбуки, модели, эксперименты. А у меня обычный backend: API, микросервисы, Kafka, БД, CI/CD и продакшен.

C# и Java для этого хватало.

Но когда начал разбираться с LLM быстро понял, вызвать модель можно из любого языка, а вот руками потрогать RAG, embeddings, локальные модели, чанкинг и evaluation проще всего через Python.

И ещё быстрее стало понятно другое, LLM это не просто «отправить prompt и получить ответ». Как только речь заходит о реальной системе появляются привычные backend вопросы «доступы, логи, стоимость, latency, качество ответа, безопасность данных и сопровождение».

Поэтому для меня Python стал не заменой C# или Java, а инструментом который помогает быстрее зайти в новый слой backend задач.

C# я до сих пор считаю одним из самых удобных языков для backend разработки. В нём много вещей к которым быстро привыкаешь: свойства, LINQ, async/await, generics без type erasure, хороший tooling и понятная модель разработки.

Но банковский enterprise редко выбирает стек только по удобству языка. На практике важны не только синтаксис и экосистема, но и инфраструктура, сопровождение, безопасность, регламенты, legacy, найм, CI/CD, требования к платформам и долгосрочная стратегия организации.

Так я оказался в ситуации где C# мне субъективно нравится больше, но Java объективно стала полезнее в конкретном банковском контуре.

Эта статья не про холивар C# vs Java. Это попытка спокойно разобрать почему backend разработчику в enterprise иногда приходится расширять стек, даже если текущий язык его полностью устраивает.

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

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

В статье рассмотрим, почему прямое удаление сообщений не подошло, какие варианты были рассмотрены и как в итоге был применён комбинированный подход: стабильный Kafka key, tombstone-сообщения, compact/delete policy и проверка состояния таксономии на стороне consumer.

Оптимизация обработки больших отчетов в .NET Core: от памяти к потокам

Отчёты росли, память заканчивалась. Пришлось отказаться от словарей в пользу потоковой сериализации JSON. Делюсь, как реализовал запись отчёта «на лету» и заставил.NET работать с гигабайтами данных без OutOfMemory.