Taming LLMs – A Practical Guide to LLM Pitfalls with Open Source Software
https://www.souzatharsis.com/tamingLLMs/markdown/toc.htmlBy sebg at
huqedato | 3 comments | 2 weeks ago
Just read this paragraph: "In conclusion, while managing output size limitations in LLMs presents significant challenges, it also drives innovation in application design and optimization strategies. By implementing techniques such as context chunking, efficient prompt templates, and graceful fallbacks, developers can mitigate these limitations and enhance the performance and cost-effectiveness of their applications. As the technology evolves, advancements in contextual awareness, token efficiency, and memory management will further empower developers to build more robust and scalable LLM-powered systems. It is crucial to stay informed about these developments and continuously adapt to leverage the full potential of LLMs while addressing their inherent constraints."
tarboreus | 0 comments | 2 weeks ago
simonw | 1 comment | 2 weeks ago
zbyforgotp | 4 comments | 2 weeks ago
WesleyJohnson | 0 comments | 2 weeks ago
I read through the article and it provided a lot of helpful information on the pitfalls with LLMs which, based on the title, is its intended purpose. I didn't take it as a shining recommendation for LangChain. If your point is that suggesting LangChain means they're not keeping up, as someone else stated, and because of that the other information is probably dated as well - that's far more helpful.
I wouldn't mind seeing a current guide on pitfalls and practical examples of interacting with LLMs with raw python - from someone who "has a clue".
pkkkzip | 3 comments | 2 weeks ago
a_bonobo | 2 comments | 2 weeks ago
tonyoconnell | 2 comments | 2 weeks ago
_neil | 0 comments | 2 weeks ago
mavelikara | 0 comments | 2 weeks ago
d4rkp4ttern | 0 comments | 2 weeks ago
In Apr 2023 we (CMU/UW-Madison researchers) looked into this lib to build a simple RAG workflow that was slightly different from the canned "chains" like RetrievalQAConversation or others, and ended up wasting time hunting docs and notebooks all over the place and going up and down class hierarchies to find out what exactly was going on. We decided it shouldn't have to be this hard, and started building Langroid as an agent-oriented LLM programming framework.
In Langroid you set up a ChatAgent class which encapsulates an LLM-interface plus any state you'd like. There's a Task class that wraps an Agent and allows inter-agent communication and tool-handling. We have devs who've found our framework easy to understand and extend for their purposes, and some companies are using it in production (some have endorsed us publicly). A quick tour gives a flavor of Langroid: https://langroid.github.io/langroid/tutorials/langroid-tour/
3abiton | 0 comments | 2 weeks ago
knowsuchagency | 0 comments | 2 weeks ago
factormeta | 2 comments | 2 weeks ago
lgas | 1 comment | 2 weeks ago
mritchie712 | 0 comments | 2 weeks ago
I agree with this, but would argue it's not even useful for exploratory work. Most of it's function can be generated in a single prompt for your use case.
gr3ml1n | 1 comment | 2 weeks ago
Uehreka | 4 comments | 2 weeks ago
jackmpcollins | 0 comments | 2 weeks ago
Also recently released is pydantic-ai, which is also based around pydantic / structured outputs, though works at level of "agents". https://github.com/pydantic/pydantic-ai
oersted | 1 comment | 2 weeks ago
LLMs are hard to tame at scale, the focus is on tightly controlling the LLM inputs, making sure it has the information it needs to be accurate, and having detailed observability over outputs and costs. For that last part this new wave of AI observability tools can help (Helicone, Langsmith, W&B Weave...).
Frameworks like LangChain obscure the exact inputs and outputs and when the LLM is called. Fancy agentic patterns and one-size-fits-all RAG are expensive and their effectiveness in general is dubious. It's important to tightly engineer the prompt for every individual use-case and to think of it as a low-level input-output call, just like coding a good function, rather than a magical abstract intelligent being. In practice, I prefer to keep the control and simplicity of vanilla Python so I can focus on the actually difficult part of prompting the LLM well.
spacemanspiff01 | 2 comments | 2 weeks ago
oersted | 0 comments | 2 weeks ago
The reason why I keep procrastinating it is that, again, experience has shown me that LLMs are not really at a point where you can afford to abstract away the prompting. At least in the work I have been doing (large-scale unstructured data extraction and analysis), direct control over the actual input string is quite critical to getting good results. I also need fine-grained control over costs.
The DSPy pitch of automagically optimizing a pipeline of prompts sounds costly and hard to troubleshoot and iteratively improve by hand when it inevitably doesn't work as well as you need it to out-of-the-box, which is a constant with AI.
But don't get me wrong, I know I sound quite skeptical, but I intend to keep giving all these advancements a serious try, I'm sure one will actually be a big upgrade eventually.
NeutralCrane | 0 comments | 2 weeks ago
I think we are at a stage where people are so eager to build something around LLMs to become the next shovel-maker, that a lot of what is being built doesn’t actually serve anyone’s needs.
NeutralCrane | 0 comments | 2 weeks ago
baobabKoodaa | 0 comments | 2 weeks ago
LangChain never solved a real problem to begin with, so there's nothing that needs to be replaced.
Just write your own Python code that does the same thing that LangChain needs 10 layers of abstraction to do.
constantinum | 0 comments | 2 weeks ago
[1] https://www.souzatharsis.com/tamingLLMs/notebooks/structured...
[2] https://unstract.com/blog/comparing-approaches-for-using-llm...