Comments 11
Но каждая строка — моя, понятная, тестируемая, дебажимая.
Это вам понятно, а когда вы решите сменить работодателя? Другим будет понятно?)
Security: меньше зависимостей — меньше attack surface
Есть же и обратная сторона, вы ничего не сказали, как вы сканируете на секьюрность ваш маленький фреймворк.
Сложилось впечатление, что при переходе на другого ллм провайдера вы просто подкручиваете промты, а с langchain почему так нельзя? А если даже не только промпты? Почему нельзя настроить два рабочих langchain пайплайна для основного ллм провайдера и для fallback?
про «понятно вам, а другим?:
Справедливое замечание. Но «моя» в контексте статьи — не «самописный хаос», а «код без слоёв чужих абстракций между мной и логикой». Protocol-based интерфейсы, Pydantic-схемы, явные контракты агентов — это стандартный Python, который поймёт любой бэкендер. А вот RunnableSequence → RunnableLambda → LCEL-пайплайн — это LangChain-специфичные абстракции, которые новый разработчик должен изучать отдельно. По сути вопрос: что проще понять новому человеку — чистый FastAPI + httpx + Pydantic, или то же самое, но обёрнутое в слой фреймворка со своей терминологией?
про подкрутку промптов — а с LangChain почему нельзя?:
Можно. Технически ничто не мешает в LangChain держать разные промпты для разных провайдеров. Проблема в том, что LangChain продаёт и поощряет другой подход — единый промпт через единую абстракцию. И когда ты начинаешь хранить отдельные промпты, писать отдельную валидацию, делать eval-тесты для каждого провайдера — от LangChain остаётся только import. Ты борешься с абстракцией, которая предполагает, что провайдеры взаимозаменяемы, а они нет. В какой-то момент проще убрать прослойку, чем обходить её на каждом шагу.
Почему Langchain - это лишний фреймворк, котрый сложно изучить, а, например, FastApi не лишний....
Очень странная логика, так можно вообще без фреймворков остаться и в БД не писать, а csv, потому что так прям нет зависимостей.
И приятнее читать, если вы сами пишете коменты, а не иишкой...
Ну как будто бы тесты действительно должны быть разные и независимые для разных моделей вне зависимости от того какой framework.
Проблем там огромное количество. Во первых используется когнитивная нагрузка в виде mcp протоколов и тул колинга. Даже несчастная запись в файл делается через джсон. Люди не могут понять, что создавая когнитивную нагрузку, нагружают модель ненужным форматированием. А нужно использовать маркдаун или вообще простую горизонтальную линию, после которой идет аутпут.
Кроме того в самом проекте ланг чеин промпты весьма наивные и думают что модель ответит верно с 1 раза. Нет мульти аутпута и ранжирования ответов llm судьями. Да и вообще нет даже элементарной проверки на self bleu или rouge. И тд.
Все это говорит о том что наработки и абстракции ланг чеин можно юзать, но только в ознакомительных целях.
Отличный пост, спасибо. Это отличный ворк кейс. Короткий вопрос, не присматривались к другим self hosted векторным дБ к примеру Weaviate,OpenSearch?
Мультиагентная система без LangChain: почему абстракции ломаются и как строить production на чистом Python