Comments 32
Не нужно выбирать "Python против Java" или "Python против C#". В реальной работе часто получается так:
Python -> эксперименты, прототипы, пайплайны, AI инструменты Java/C# -> интеграция в основной enterprise контур Backend -> безопасность, сопровождение, production качество
Очень сомнительные выводы сделаны автором... Подозреваю что автор далёк от мира linux, где python это стандарт. И странная классификация где backend выделен как отдельная сущность
Про linux согласен python там давно стандартный инструмент для скриптов, автоматизации и glue кода. В статье фокус был уже не python как linux инструмент, а python как быстрый вход в llm/rag задачи для back разработчика из java/c# мира.
А back в схеме не отдельный стек, тут формулировка могла быть точнее. Имелись в виду back практики доступы, безопасность, логи, сопровождение и production качество, которые нужны независимо от языка.
Зачем бэкенд, - разработчику пайтон?
Затем же, зачем бэкенд-разработчику - пайтон … ,)))
Ещё Python удобен для того, чтобы навайбкодить себе MCP для решения локальной задачи, под которую нет инструмента, и руками докрутить, где необходимо. Можно, конечно, пойти в FizzBuzz Enterprise Edition на Go, но для быстрого решения Python весьма хорош.
Используем бэкенд python также для NLP, NER задачек - удобная экосистема. Для прода камнем преткновения вижу GIL, который проник во все либы, а также типобезопасность. В тоже время радует зрелость экосистемы анализа данных (pandas и тд) для проведения RnD.
Мне кажется было бы забавнее опрос сделать: какой моделью сгенерирована данная статья? (Не осуждаю, сейчас все статьи такие) По формулировкам, тону и избитым фразам склоняюсь к тому что писал (или если вам так удобнее, редактировал) opus 4.7 (но точно Клод), угадал? :)
Важна не модель как таковая, а сколько мусора она привнесла в статью. То, что можно описать парой предложений, раздуто до невозможности
Нет, не угадали)
Если по содержанию есть конкретные замечания по rag, python, back интеграции, безопасности или enterprise контексту с интересом обсудим. Гадание по модели вряд ли что то добавит к теме статьи.
Складывается ощущение, что Python для backend-разработчика сегодня нужен исключительно как переходник к LLM и data science. FastAPI-обёртка вокруг модели, RAG-прототип, пара экспериментов с embeddings и можно возвращаться в "серьёзный" стек.
А я маргинально и упрямо продолжаю писать на нём сервисы (нас таких не мало на самом деле). Иногда даже получается:)
Согласен, python это не только переходник к llm, на нём вполне пишут нормальные back сервисы.
В статье фокус был на взгляд c#/java back разработчика, у которого python появился именно через llm/rag задачи. Поэтому я больше писал про прототипы, embeddings, rag и ai инструменты, а не про python как основной back стек.
Про полноценный back на python это, скорее отдельная большая тема.
У меня на питоне несколько больших живых сервисов у разных заказчиков и прототипирование всего протокольного, что потом переписывается на плюсы ради высокой производительности, такой цикл разработки крайне хорошо себя показал :)
Постановка вопроса смешная, на самом деле. Каждый дополнительный язык - это дополнительные возможности. Рискну предположить, что среди дата-сайнтистов пайтон на уровне понимания внутренних механизмов работы знают единицы.
Мне кажется это вообще относится не только к python. Среди разработчиков на java, c# или js тоже далеко не все глубоко понимают устройство JVM, CLR или движка V8.
Для большинства задач важнее уметь эффективно решать проблему с помощью инструмента, чем знать все внутренние детали его реализации.
У меня python просто появился через интерес к llm, а дальше уже постепенно появился интерес и к самому языку, и к его экосистеме.
Я у нейросетевых питонистов на собесе любил спрашивать про asyncio...
А кто такие нейросетивые погрмисты?
Вайбкодеры жеж :)
На самом деле - те, кто строит нейросетки во всяких Torch-ах и прочих TensorFlow. Типа, тоже питонисты.
Вайбкодеров пока не встречал
Те кто строит нейросетки в пайторчах у них ка бэ свои очень специфические задачи зачем им знать про asyncio?
Думаю если человек в основном занимается обучением моделей в PyTorch, то asyncio ему может быть вообще не нужен.
Но вокруг нейросетей часто есть не только само обучение модели, есть ещё инференс сервисы, api, очереди, стриминг ответов, параллельные запросы к внешним сервисам, обвязка вокруг llm и т.д. И вот там уже понимание async/await и asyncio может оказаться вполне полезным.
То есть я бы не сказал, что “всем кто пишет на PyTorch обязательно знать asyncio”. Предполагаю это пример того, что python используется в очень разных контекстах и глубина знания языка сильно зависит от задач.
спасибо за развернутый ответ, да сложно не согласится с приведенной аргументацией.
Видел с десяток уже проектов где ллм приложения не работают из за того что есть юпитерноутбук от датасанстистов и есть тру бэкендероры но чего то нехватает)
Получается что нужен еще МЛ инженер в команду что бы это все заработало по идее он должен знать про ассинхроность и многопоточность но не обязательно. Его задлача взять юпитер ноутбук и переписать в его в приложение с обработкой эксепшенов с логгированием, причем логирование в таких проектах специфическое не только в плане МЛ метрик, но и специфические инструменты например MLflow, langfuse а не привычные прометеусы с графанами
Тут появляется отдельный инженерный слой между “работает в Jupyter” и “работает в проде”.
Кто это делает ml engineer, backend разработчик с ml контекстом или команда зависит от проекта, но задачи уже не только в модели, нужно ещё вынести код в сервис, добавить обработку ошибок, логи, метрики, трассировку, тестовые вопросы и контроль того, какие документы/чанки реально попали в prompt.
Без такой диагностики llm/rag быстро становится чёрным ящиком, вроде что то отвечает но непонятно почему именно так.
согласен что не во всех проектах важны всякие NDCG и понимать чем векторный поиск отличается от bm25, или как именно работает реранкер на би энкодере.
Но если бэкендер с трудом отличает прессижн от реклла то в проекте не обойтись без МЛ инженера.
Плюс есть отличия между систем дизайном и мл систем дизайном если есть арихитектор который шарит или МЛщик который не только шарит но и может донести свою мысль тогда ок, в противном случае будет вот это вот что сейчас на проектах Сбера откуда выгали "дорогих" синьоров под предлогом оптимизации и оставили мидлов и тру бэкендеров в итоге RAG для бизнеса отвечает либо None либо совсем не то что спрашивали. Тру стори
Бэкендеру не обязательно становиться ml инженером, но базу по retrieval и метрикам качества понимать надо, иначе получается классика: api есть, модель отвечает, ui есть а бизнесу прилетает либо none либо ответ вообще не про то.
RAG всё равно нужно отдельно проверять: тестовые вопросы, качество найденного контекста, precision/recall хотя бы на базовом уровне.
RAG всё равно нужно отдельно проверять: тестовые вопросы, качество найденного контекста, precision/recall хотя бы на базовом уровне.
Вот это вот все есть в джупитере у ДСа а вот в проде есть только None
precision/recall - это классические оффлановые метрики, их так просто не посчитаешь на проде, значит нужно собирать какие то прокси метрики, но какие именно и в каких частях системы, до ретривера после ретривера, до генерации или после, как это все интерпретировать и т.д и т.п.
Вот и получается что у ДСа нет понимания как работает сервис целиком, а у бэкендера нет компетенций по АИшной/МЛной части.
Так и живем
Про recision/recall скорее имел в виду как offline проверку на заранее подготовленном наборе вопросов, а не как то что можно просто посчитать в production. В проде конечно нужны уже proxy метрики: score у top-k, доля no context ответов, сколько запросов дошло до generation, latency по этапам, частые провальные вопросы и т.п.
И да тут как раз видно, что RAG это не только ml часть и не только backend. Если смотреть только из ноутбука или только со стороны API, легко не увидеть где именно всё ломается.
Я у нейросетевых питонистов на собесе любил спрашивать про asyncio...
Не удивлён)
Наверное почти в каждом стеке есть такие темы, в java можно спросить про устройство JVM и GC, в c# про CLR и async/await под капотом. Пользоваться инструментом и глубоко понимать его внутренности всё таки разные уровни.
Во первых спасибо что поделился своим взглядом на разработку ЛЛМ приложений, достаточно познавательно.
Особенно в свете последних событий когда есть дата сотонист готорый написал 1200 строк кода на пистоне в джупитере и есть тру бэкендер на джаве/си шарпе, но как итог в проде RAG на половину запросов отвечает None а на вторую не то что его спрашивали.
Как быть в такойм случае?
В таком случае смотрел не на язык а на весь RAG pipeline. Если система на половину запросов отвечает none а на вторую половину отвечает не то, значит нужно разбирать не только llm, а retrieval: какие документы попали в индекс, как они нарезаны на chunks, какие sources поднимаются, какие scores, что уходит в prompt и когда backend вообще должен отказаться от генерации.
Для production RAG на мой взгляд обязательны request_id, sources, debug endpoint, negative tests, метрики retrieval/generation и набор контрольных вопросов. Без этого получается не система а “надеемся что vector search и prompt как нибудь справятся”.
Сейчас заканчиваю статью про этот переход. Там хочу показать это на локальном примере.
какие scores, что уходит в prompt и когда backend вообще должен отказаться от генерации.
Для production RAG на мой взгляд обязательны request_id, sources, debug endpoint, negative tests, метрики retrieval/generation и набор контрольных вопросов
Вот это очень интересные вопросы с удоволствием бы почитал ответы.
Какие скоры, какие метрики на проде для retrieval/generation и как связаны контрольные вопросы и прод
Это как раз про переход от “embeddings + prompt” к back системе. Scores сами по себе не универсальны, они зависят от модели, чанкинга и корпуса. Поэтому на проде важнее смотреть top-k sources, что ушло в prompt, latency retrieval/generation, долю запросов без контекста, ошибки/timeouts и случаи, где модель ответила не по sources.
Контрольные вопросы это regression tests для RAG: positive, negative, exact token и stale index сценарии, после смены модели, prompt, chunking или thresholds они показывают не сломалось ли поведение.
Сегодня опубликовал статью с локальным примером: https://habr.com/ru/articles/1048252/
Зачем backend разработчику Python, если он не собирается становиться data scientist