killthebuddha

It feels a little bit odd that a newsletter + project that's directly motivated by Penrose's book and also appropriates the book's title does not mention the book. For example, the GitHub repo's readme:

  Welcome to the Road to Reality!

  The Road to Reality is an essay series by me, Sam Ritchie. Starting with the 
  basics of Lisp (the Clojure programming language, specifically), we'll build a 
  modern computer algebra system and use that system to explore and simulate 
  gems of modern physics like variational mechanics and general relativity.

Maybe it's just me, but I think if I was Roger Penrose I'd be like "uh, wtf".

I think you might have committed a straw man error. My point is not that approximate or vague language is always good, it's that it's sometimes good. Sometimes imprecise communication is good and useful, sometimes it's doublespeak.

IMO the argument is sound in one direction: the precision, structure, and unforgiving nature of programming languages is a feature rather than a bug. That said, I think this does not mean that there is no benefit to natural language interfaces to machines. I think he goes wrong here:

> When all is said and told, the "naturalness" with which we use our native tongues boils down to the ease with which we can use them for making statements the nonsense of which is not obvious.

I would say that he leaves out a critical detail: the nonsense of which is not obvious _and also not important_.

I'm not an outsider but I also don't understand the reaction. I'm going to randomly think of 5 names for technologies and see how they sound:

React, Supabase, Next, Kafka, Redis

I mean, IMO "LangChain" is kind of a silly name but I feel like there's nothing to see here.

I agree, it looks great. A couple similar projects you might find interesting:

- https://github.com/newhouseb/clownfish

- https://github.com/r2d4/rellm

The first one is JSON only and the second one uses regular expressions, but they both take the same "logit masking" approach as the project GP linked to.

I'm skeptical that the streaming API would really save that much cost. In my experience the vast majority of all tokens used are input tokens rather than completed tokens.

This looks really interesting, great work! Is there somewhere in the docs that describes the essence of how LMQL works? My initial assumption was that it's a compiler that transforms LMQL queries into prompts, but then I realized that there also needs to be some kind of query execution engine to do prompt chaining, retries, etc. More generally, I'm trying to figure out how difficult it would be to use LMQL from Node.js.

I think it makes a lot of sense in theory to consider adding CPUs as horizontal scaling, but in practice I'm not sure it makes sense. Moving your app to a machine with twice as many CPUs is more like moving it to a machine with twice as much RAM than it is like doubling the number of machines your app is deployed to.

I meant vertical scaling, but it sounds like our understanding of vertical scaling is different. My framing is "horizontal scaling = more machines, vertical scaling = more powerful machines". I guess one way to think about it is that Elixir makes scaling the number of cores a strictly vertical kind of scaling.

I love elixir, but I feel like there’s something off about the focus on reliability and error handling. At least for web applications, it’s pretty boring the idea that a single error won’t take down the entire system. At worst, a single error might take down an entire process, but that’s really not that terrible. Also, error handling code that is not colocated with the logic that threw seems like a mess. Error handlers have to decide whether we can recover and whether we need to report the problem, and that doesn’t really change just because an error won’t bork an entire system. IME error handling is mostly about deciding what is best for the user.

What I love most about elixir is the ridiculously dead-simple vertical scaling. A close second is The World’s Best Take On ORMs (aka Ecto).

For the most part. It’s the system prompt + user/assistant structure that encourages second-person system prompts. You could write a prompt that’s like

System: Complete transcripts you are given.

User: Here’s a transcript of X

But that, to me, seems like a bit of a hack.

One related behavior I’ve noticed with the OpenAI chat completions endpoint is that it is very trigger happy on completing messages that seem incomplete. It seems nearly impossible to mitigate this behavior using the system prompt.

For raw text completion I agree with you that it's a bit discordant. IMO text completion prompts work better when you use more of a first-person, here-is-the-beginning-of-some-transcript style.

The OpenAI chat completion endpoint encourages the second-person prompting you describe, so that could be why you see it a lot. My understanding is that a transformation is applied to the user input prompts before being fed to the underlying model, so it's possible that the model receives a more natural transcription-style prompt.

You might be interested in this paper, which explores ways to help non-experts write prompts https://dl.acm.org/doi/abs/10.1145/3544548.3581388.

I'm very unsure that I understand your requirements, but if I squint really really hard it looks like you're asking for a blockchain.

DISCLAIMER: I think Yudkowsky is a serious thinker and his ideas should be taken seriously, regardless of whether not they are correct.

Your comment triggered a random thought: A perfect name for Yudkowsky et al and the AGI doomers is... wait for it... the Yuddites :)

> a decline into a contrived and pretentious quest where the artist, instead of attempting to make known the divine plan, tries to put himself in the place of God

and 40 years later we have TikTok

I think this is a great way to think about it. Hallucinations are the default and an LLM app is one that channels hallucinations rather than avoids them.

Interesting, I didn’t know that.

I completely agree. IMO anthropomorphisms of LLMs leave out extremely important details.

A ChatGPT plugin that can answer search queries over your favorite sites would be basically trivial to build and would probably work very, very well. Not only that, but it would be immediately composable with any other ChatGPT plugin. All that said, I'm all for building alternatives to ChatGPT. I think we're heading to a future where the ChatGPT plugin store is the iOS app store of LLM apps.

IMO this leaves out some salient details. For example, I'd say ChatGPT is a very, very good junior developer. The kind of junior developer that loves computer science, has been screwing around with miscellaneous algorithms and data structures its whole life, has a near-perfect memory, and is awake 24/7/365, but has never had to architect a data-intensive system, write future-proof code, or write code for other developers. Of course, these last three things are a big deal, but the rest of the list makes for a ridiculously useful teammate.

Copilot is highly usable and I'm pretty sure it works the same way.

Definitely maybe, but also I think pinecone is putting a lot of resources into devrel. For example, see their learning center [1] and examples [2].

Oh man, now I sound like I'm part of the brigading :) FWIW I recently evaluated pinecone and alternatives and decided not go with pinecone (pgvector).

[1] https://www.pinecone.io/learn/

[2] https://docs.pinecone.io/docs/examples

Having myself recently bootstrapped an understanding of language models et al, I would not be surprised if the pinecone learning center gets a lot of traffic.

ChatGPT plugins aren't out of beta yet, but this is 100% going to be eaten by one.

Edit: I guess that's not a super productive comment. I commend the authors for building and shipping something useful, I would personally use something like this.

Makes sense. I wonder if it would actually make more sense to just plug a function that generates the mask because in general it's just:

  fn complete(input, masker):
    completion = input
    while (not done yet):
      mask = masker(completion)
      completion = complete(complete, mask)
    end
    return completion
  end

is that accurate?

I would run postgres with pgvector https://github.com/pgvector/pgvector.

I wouldn't call postgres lightweight of course, but it's definitely lightweight in the sense that it doesn't add a whole bunch of new garbage to an otherwise traditional application.

I imagine it's because there is a *massive* scramble to incorporate language models into existing applications and most of the time you need a vector database to do that. As a proxy for understanding the scale of this scramble, ChatGPT is the fastest growing software product ever by a pretty substantial margin.

In the last 24 hours I've seen a bunch of projects doing LLM -> JSON. I think we want to be focusing on markdown instead. An intuition I have developed is that an ideal prompt has a very clear narrative structure and very tight "semantic locality" (the instruction is at the end, the most salient data is close to the instruction, etc).

JSON is admittedly way easier to work with up front, but markdown seems to be a more scaleable choice.

Of course, this is all very much an opinion and highly anecdotal at the moment.

That would almost certainly work to improve reliability but you would probably need something like this anyway, wouldn't you?

In general, it seems like building a production-ready LLM-based application requires _a lot_ of these little tricks and methods to hammer results into shape before sending them downstream.

That sounds like a real risk but also the kind of thing you would need to implement a solution for anyways.

It seems like there's two clear paths:

- Allow the model to complete whatever it wants and then anneal the structure into compliance - Force the model into a compliant structure and then anneal the quality

I think both options can make sense in different cases.

One case I'm thinking about where the second option feels simpler is when you want to implement a boolean function using a language model. I'm imagining a probability distribution that looks like:

- (40%) the answer is true - (39%) True - (21%) False

In this case it seems significantly more straightforward to force the model into completing T or F. I guess you then run into the "dangerous case" where you have

- (40%) the answer is false - (39%) True - (21%) False

This seems extremely similar to https://github.com/newhouseb/clownfish