3 ms·
So much "Yes!" for LangChain being bad practice. An unnecessarily bloated abstraction over what should be simple API calls.
by ukuina 3y ago
So much "Yes!" for LangChain being bad practice. An unnecessarily bloated abstraction over what should be simple API calls.
- yinser 3y agoDo you have a recommendation of how to easily connect a language model to a python repl, apify, bash shell, and composable chaining structures if not langchain? I find those structures invaluable but am curious where else I could build these programs.
- ntonozzi 3y agoIt’s great for prototyping and seeing what is possible but for running in production you’ll likely need to write it yourself, and it will just take a few minutes.
- jmccarthy 3y agoCould be we're in a (short?) interregnum analogous to pre-Rails Ruby: there are lots of nascent frameworks, but the dominant one hasn't been born yet. FWIW - DIY is working well for me.
- kordlessagain 3y agoCheck out https://www.featurebase.com/blog/doctorgpt-harnessing-the-power-of-semantic-knowledge-graphs-for-unstructured-data https://www.featurebase.com/blog/doctorgpt-harnessing-the-po... and the DoctorGPT repo for doing some things with documents and LLMs, without a framework. I use simple templating and vectors to assemble prompts.
- ukuina 3y agoThe current trend for productionizing LLM-based applications is to write your own (really thin) wrappers around the actual LLM call. The majority of your code should be business logic independent of the LLM, anyway: information retrieval, user interface, response logging, and so on. In my experience with cloud-based and local models, LLM chaining compounds errors; I would urge you to look at few-shot, single-query interaction models for business applications using LLMs as a new unit of compute.