lambdaprompt

more recently switched to just using the raw requests ourselves and writing out the logic ourselves in the product. For our main product, the code just lives in our next app, and deploys on vercel.

/github.com/approximatelabs/sketch Core things it does: Uses jinja templates, does sync and async, and most importantly treats LLM completion endpoints as "function calls", which you can compose and build structures around just with simple python. I also combined it with fastapi so you can just serve up any templates you want directly as rest endpoints. It also offers callback hooks so you can log & trace execution graphs. All together its only ~600 lines of python. I haven't had a chance to really push all the different examples out there, so I think it hasn't seen much adoption outside of those that give it a try. I hope to get back to it sometime in the next week to introduce local-mode (eg. all the open source smaller models are now available, I want to make those first-class)

n see being really valuable, as I believe there has been some traction with these style integrations with data catalog systems recently. People like to ask data questions to other people in slack, adding a bot that tries to answer might short-circuit a lot of this! We built a prototype where we applied similar techniques to the pandas-code-writing part of the stack, trying to help keep data scientists / data analysts "in flow", integrating the code answers in notebooks (similar to how co-pilot puts suggestions in-line) -- and released https://github.com/approximatelabs/sketch a little while ago.

with anyone else) a "chain" is `a = 'text'; b = p1(a); c = p2(b)` where p1 and p2 are LLM prompts. What comes next (in my opinion) is other programming constructs: loops, conditionals, variables (memory), etc. (I think LangChain represents some of these concepts as their "areas" -> chain (function chaining), agents (loops), memory (variables)) To offer this code-style interface on top of LLMs, I made something similar to LangChain, but scoped what i made to only focus on the bare functional interface and the concept of a "prompt function", and leave the power of the "execution flow" up to the language interpreter itself (in this case python) so the user can make anything with it. https://github.com/approximatelabs/lambdaprompt I've had so much fun recently just playing with prompt chaining in general, it feels like the "new toy" in the AI space (orders of magnitude more fun than dall-e or chat-gpt for me). (I built sketch (posted the other day on HN) based on lambdaprompt) My favorites have been things to test the inherent behaviors of language models using iterated prompts. I spent some time looking for "fractal" like behavior inside the functions, hoping that if I got the right starting point, an iterated function would avoid fixed points --> this has eluded me so far, so if anyone finds non-fixed points in LLMs, please let me know! I'm a believer that the "next revolution" in machine-written code and behavior from LLMs will come when someone can tame LLM prompting to self-write prompt chains themselves (whether that is on lambdaprompt, langchain, or something else!) All in all, I'm super hyped about LangChain, love the space they are in and the rapid attention they are getting~

ing the library to share with others! I mainly use lambdaprompt in two main ways: (1) to quickly try out "map" applying a LLM prompt against multiple inputs, to see how it behaves on a fixed set of inputs (2) to quickly iterate on a prompt-chain (taking the output of a prompt, and passing it to other prompts) to create complex behavior. An example of (2) that worked quite well is a Text-2-SQL prototype: It generates multiple SQL options, then executes each against the database (if it errors, asks `Codex-EDIT` to fix the errors and retry), then takes the most "consistent" answer as the valid answer. Simply by adding this prompt-chain on top of codex, we saw an improvement from ~75% to ~85% on a spider Text-2-SQL benchmark (On just a small sample of N=200). To increase usability it also ships (extras) with a fastapi app that registers any defined prompts as endpoints directly, and hosts the functions to be directly callable via HTTP-GET requests. This makes it easy to build client-applications off of these prompts, while allowing the prompt itself to be arbitrarily complex (composition of prompts) I hope you enjoy using it! Also, I'm super curious to hear if anyone else has been thinking about LLMs (composing them, building interfaces to them, etc.) in similar ways and what learnings have been (even if not though this library)