原贴链接

讨论总结

这是一个关于在不使用LangChain的情况下构建LLM代理应用程序的讨论。许多用户指出LangChain存在文档缺乏、功能臃肿、过于复杂等问题，分享了使用LangChain时遇到的困难，如构建速度慢、调试困难等。同时，大家积极推荐了众多替代方案，如Llama_index、Autogen、Semantic Kernel等，并阐述了各自的优势，还讨论了构建LLM代理应用的不同思路和工具选择。

主要观点

  1. 👍 LangChain存在诸多问题，如文档缺乏、功能臃肿且复杂
    • 支持理由：许多用户提到在使用LangChain时遇到困难，如实际链、LCEL不佳，将重要内容隐藏在抽象背后等。
    • 反对声音：有用户提到LangChain有统一接口、重试机制等优点。
  2. 🔥 可以使用多种替代方案构建LLM代理应用程序
    • 正方观点：很多人推荐了如Llama_index、Autogen、Semantic Kernel等替代方案，并阐述了各自优势。
    • 反方观点：无（大多是正面推荐）。
  3. 💡 构建应用时可根据自身情况选择不同的工具和方法
    • 解释：如经验丰富的工程师可从pydantic和litellm开始构建，初学者可选择PydanticAI；还可使用如grpc微服务、自己编写编排程序等不同方法。

金句与有趣评论

  1. “😂 Documentation is very lacking, everything is overcomplicated and it’s painful to do even very default stuff.”
    • 亮点：直接指出LangChain文档缺乏且默认操作都困难的问题。
  2. “🤔 I can do everything I can in langchain, but with less lines of code in pure python. Doing it this way also hides nothing and I have full control over everything.”
    • 亮点：强调用纯Python能实现LangChain功能且更具掌控力。
  3. “👀 Langchain was outdated when it was released, now it looks like a fucking npm package…”
    • 亮点：以比较犀利的语言表达对LangChain的不满，认为其过时且糟糕。

情感分析

总体情感倾向对LangChain为负面，主要分歧点在于LangChain是否有用。大部分用户认为LangChain存在诸多问题，不适合用于构建LLM代理应用，但也有部分用户认可其某些优点。可能的原因是不同用户在使用LangChain时有不同的体验，以及对构建应用的需求和期望不同。

趋势与预测

  • 新兴话题：可能会有更多关于推荐工具（如PydanticAI等）的深入使用和比较讨论。
  • 潜在影响：对于LLM代理应用的构建者来说，能有更多元化的选择，推动构建方式更加灵活高效，也可能促使LangChain改进自身的不足。

详细内容：

《关于不使用 LangChain 构建 LLM 代理应用的热门讨论》

在 Reddit 上，一个题为“How would you build an LLM agent application without using LangChain?”的帖子引起了广泛关注。该帖子获得了众多点赞和大量评论，引发了一场关于构建 LLM 代理应用时是否使用 LangChain 以及替代方案的热烈讨论。

讨论的焦点主要集中在以下几个方面：

有人认为 LangChain 存在诸多问题，比如文档缺乏、过于复杂、功能臃肿，难以进行自定义和调整。例如，有用户分享道：“Documentation is very lacking, everything is overcomplicated and it’s painful to do even very default stuff, for example: How I can do rag + function calling + text streaming with local model? It will be very difficult to get this right with docs. You have examples for each thing separetly but they don’t fit with each other.” 还有用户表示：“It’s weirdly goofy how things are set up. Want to customize one of the samples to do basically anything different than how the sample does it, to add actual functionality? Nope!”

然而，也有用户认为 LangChain 有其优点，比如统一接口、重试和回退机制等。一位实际使用过 LangChain 的用户说：“Actual Langchain user here: there’s no obvious way of having the good parts from the bad parts without experience. Most of it is just junk and feature bloat. The good so far: unified interface for different LLMs, retry/fallback mechanisms, langfuse/smith tracing and profiling (especially for out - of - the - box RAG setups), some RAG building blocks, structured outputs. The bad: the actual chains (a kitten dies every time some dumbnut tries clever things with operator overloading in Python and breaks code introspection), LCEL, documentation. I steered away from almost everything due to the latter. I’d only interact with the bad parts if you need powerful tracing, the ramp up is a nightmare and there’s no guarantee of API stability at this point (the upside is that v0.3 trimmed down the fat a lot).”

同时，大家纷纷提出了各种替代方案和个人经验。比如，[JCAPER] 表示：“There may have been some fault of my own, but months ago I made a telegram bot with python and used langchain for LLM responses. After a while, the script would always crash. Tried now with ollama’s own library, and now it works like a charm, out of the box, no problems whatsoever.” 还有用户提到了 LlamaIndex、phidata、haystack 等替代框架。

关于是否可以直接复制粘贴开源框架的代码，也引发了争议。有人认为在遵循许可的情况下可以，有人则认为这违背了开源精神。

总之，这场讨论展现了大家对于构建 LLM 代理应用时选择框架的不同看法和丰富经验，为开发者提供了多方面的思考和参考。