The threading macro in Clojure provides a more readable way to compose functions together. It’s a bit like a Bash pipeline. The following function takes a string, splits on a : and trims the whitespace from the result. The threading macro denoted by -> passes the threaded value as the first argument to the functions. (defn my-fn [s] (-> s (str/split #":") ;; split by ":" second ;; take the second element (str/trim) ;; remove whitespace from the string ) ) There is another threading macro denoted by ->> which passes the threaded value as the last argument to the functions.
This past week, OpenAI added function calling to their SDK. This addition is exciting because it now incorporates schema as a first-class citizen in making calls to OpenAI chat models. As the example code and naming suggest, you can define a list of functions and schema of the parameters required to call them and the model will determine whether a function needs to be invoked in the context of the completion, then return JSON adhering to the schema defined for the function.
I was interested to learn more about the developer experience of Cloudflare’s D1 serverless SQL database offering. I started with this tutorial . Using wrangler you can scaffold a Worker and create a D1 database. The docs were straightforward up until the Write queries within your Worker section. For me, wrangler scaffolded a worker with a different structure than the docs discuss. I was able to progress through the rest of the tutorial by doing the following:
I tried out jsonformer to see how it would perform with some of structured data use cases I’ve been exploring. Setup python -m venv env . env/bin/activate pip install jsonformer transformers torch Code ⚠️ Running this code will download 10+ GB of model weights ⚠️ from jsonformer import Jsonformer from transformers import AutoModelForCausalLM, AutoTokenizer model = AutoModelForCausalLM.from_pretrained("databricks/dolly-v2-12b") tokenizer = AutoTokenizer.from_pretrained("databricks/dolly-v2-12b") json_schema = { "$schema": "", "title": "RestaurantReview", "type": "object", "properties": { "review": { "type": "string" }, "sentiment": { "type": "string", "enum": ["UNKNOWN", "POSITIVE", "MILDLY_POSITIVE", "NEGATIVE", "MILDLY_NEGATIVE"] }, "likes": { "type": "array", "items": { "type": "string" } }, "dislikes": { "type": "array", "items": { "type": "string" } } }, "required": ["review", "sentiment"] } prompt = """From the provided restaurant review, respond with JSON adhering to the schema.
Imagine we have a query to an application that has become slow under load demands. We have several options to remedy this issue. If we settle on using a cache, consider the following failure domain when we design an architecture to determine whether using a cache actually is a good fit for the use case. Motivations for using a cache When the cache is available and populated it will remove load from the database.
I’ve written several posts on using JSON and Pydantic schemas to structure LLM responses. Recently, I’ve done some work using a similar approach with protobuf message schemas as the data contract. Here’s an example to show what that looks like. Example Imagine we have the following questionnaire that we send out to new employees when they join our company so their teammates can get to know them better. What are your hobbies or interests outside of work?
Plenty of data is ambiguous without additional description or schema to clarify its meaning. It’s easy to come up with structured data that can’t easily be interpreted without its accompanying schema. Here’s an example: { "data": [ 12, "21", true, { "name": "John Doe", "age": 30 } ] } You can argue that this is “bad” structured data, but if you have this data structure, there is little meaning you can derive without additional insight into what the data represents.
The most popular language model use cases I’ve seen around have been chatbots agents chat your X use cases These use cases are quite cool, but often stand alone, separate from existing products or added on as an isolated feature. Expanding production use cases for language models I’ve been thinking about what could it look like to naturally embed a call to language model in code to flexibly make use of its capabilities in a production application.
It’s necessary to pay attention to the shape of a language model’s response when incorporating it as a component in a software application. You can’t programmatically tap into the power of a language model if you can’t reliably parse its response. In the past, I have mostly used a combination of prose and examples to define the shape of the language model response in my prompts. Something like: Respond using JSON with the following shape:
Auto-GPT is a popular project on Github that attempts to build an autonomous agent on top of an LLM. This is not my first time using Auto-GPT. I used it shortly after it was released and gave it a second try a week or two later, which makes this my third, zero-to-running effort. I installed it python -m venv env . env/bin/activate pip install -r requirements.txt and then ran it