51–60 of 97 posts
I played around with simpleaichat for a few minutes just now, and I really like it. Unlike LangChain, I can understand what it does in minutes, and it looks like its primitives are fairly powerful. It looks like it's going to replace the `openai` library for me, it seems like a nice wrapper. I'm especially looking forward to playing with the structured data models bit: https://github.com/minimaxir/simpleaichat/blob/m…
I'm in the exact same spot as the author just a few days in instead of months. Frankly I could see langchain is garbage software just by looking at the code. It still helps me get shit done fast to figure out how things are supposed to work. Sort of a cookbook of AI recepies. Once I have an approach narrowed down I'll rewrite everything on top of stuff langchain is supposedly wrapping. For now it's faster than tracki…
Reading this was very cathartic, I was nodding along and laughing as I had the exact same journey of WTF. And all along I just assumed I was 100% of the problem. Hearing this perspective helps put my frustration in context. I need to lower my expectations and just get used to its quirks. Despite its issues I've had a ton of fun building with langchain and will keep using it.
My primary use of langchain has been to turn text into a vector database with chroma and then query the vector database to return source materials to an LLM to use. I’d much prefer to move away from it because like the author I find LC’s adherence to system prompts is really bad. I can handle all of the agent side of things, I just want relevant source materials from the vector DB as strings — anyone have a better mo…
This is an example of using pgvector that might be relevant for your use case:
SELECT d.id, d.doc, 1 - (embedding (SELECT embedding FROM documentation_embedding WHERE id = 1)) AS similarity FROM documentation_embedding de join documentation d on de.documentation_id = d.id ORDER BY similarity desc;
Read this page and mentally swap "chain" for "function": https://python.langchain.com/docs/modules/chains/foundationa...
They build all these adapters and integrations and make it seem like they're helping you piece together a solution, but in how many cases were they necessary as a middleman? Like I really don't need a wrapper around the openai client, and for the more complex stuff like Agents, isn't this the most critical part of your app, if it's production? And for notebooks, is it any better than coding directly against your llm api? You probably won't swap llm backends, and if you're using the notebook for education/documentation, I think I'd want to show the actual openai api calls.
OpenAI's official documentation gives you the code for a tool-running agent anyway. Taking that and editing it can probably be done faster than pip-installing langchain and navigating its docs.
It's funny that these tools try to coerce LLM to use json as intermediate format. As long as you're cycling data between LLM unstructured text is going to be just fine. Have your tools accept natural language as well, and you're golden.
GPT-4 has good json support now. It’s nice to be able to give it a a schematic get structured json back.
In between you may want some form of data storage, and natural language can be that as well, as it makes retrieval trivial for LLM.
I came to the same conclusion with author, decided to make port to Go. With a plan to just adopt the concepts and strip all the unnecessary complexity and lots things mentioned by the article. Datastore, chain, tools, model are pretty much implemented. However coming to Agent, I'm now wondering if it's the right way to do things. It does work, but is it efficient? At least I know it's not simple.
mind sharing the repo?