Live data from Hacker News

A guidance language for controlling LLMs

github.com

61–70 of 198 posts

Re: A guidance language for controlling LLMs

#61

I'm personally starting with learning Guidance and LMQL rather than LangChain just in order to get a better grasp of the behaviors that I've gathered LangChain papers over. Even after that, I'm likely to look at Haystack before LangChain. Just getting the feeling that LangChain is going to end up being considered a kitchen sink solution full of anti patterns so might as well spend time a little lower level while I se…

What do you think about Haystack vs LangChain?

Re: A guidance language for controlling LLMs

#62
post #38

I like this step towards greater rigor when working with LLM's. But part of me can't help but feel like this is essentially reinventing the concept of programming languages: formal and precise syntax to perform specific tasks with guarantees. I wonder where the final balance will end up between the ease and flexibility of everyday language, and the precision / guarantees of a formally specified language.

A number of years ago we were designing a way to specify insurance claim adjudication rules in natural language, so that "the business" could write their own rules. The "natural" language we ended up with was not so natural after all. We would have had to teach users this specific English dialect and grammar (formal and precise syntax, as you said).

So, in the end, we abandoned that project and years later just rewrote the system so we could write claim rules in EDN format (from the Clojure world) to make our own lives easier.

In theory, the business users could also learn how to write in this EDN format, but it wasn't something the stakeholders outside of engineering even wanted. On the one hand, their expertise was in insurance claims---they didn't want to write code. More importantly, they felt they would be held accountable for any mistakes in the rules that could well result in thousands and thousands of dollars in overpayments. Something the engineers weren't impervious to, but there's a good reason we have quality assurance measures.

Re: A guidance language for controlling LLMs

#63
post #46

This reminds me of the time when I wrote a cgi script. Basically instructing the templating engine (a very crude regex) to replace session variables, database lookups to the merge fields: Hello {{firstname}}! 1996 and 2023 smells alike.

RegEx didn't hallucinate though.

Re: A guidance language for controlling LLMs

#64

Earlier quoted context omitted.

Not quite sure what the spirit of your comment is. But, yes, they are real technologies. Very confused as to why you would even find that dubious.

Not dubious, I just read your comment and it felt like I was reading satire. Even the cadence of your words felt funny. Anyway, I’m not surprised. It’s a new market, everyone’s in on it.

It is satire. They just don’t realise it yet.

It’s pretty clear that we are in the phase where everyone is rushing to get a slice of the pie selling dubious thing and people start parroting word soup hoping they actually make sense and fearing they will miss out. That’s indeed what people often and rightfully satirise about the IT industry. That’s the joke phase before things settle.

Re: A guidance language for controlling LLMs

#65
post #38

I like this step towards greater rigor when working with LLM's. But part of me can't help but feel like this is essentially reinventing the concept of programming languages: formal and precise syntax to perform specific tasks with guarantees. I wonder where the final balance will end up between the ease and flexibility of everyday language, and the precision / guarantees of a formally specified language.

Use LLM for the broad strokes, then fall back into 'hardcore JS' for areas that require guarantees or optimization. Like JS with fallback to C, and C with fallback to assembly. I like the idea.

Re: A guidance language for controlling LLMs

#66
post #38

I like this step towards greater rigor when working with LLM's. But part of me can't help but feel like this is essentially reinventing the concept of programming languages: formal and precise syntax to perform specific tasks with guarantees. I wonder where the final balance will end up between the ease and flexibility of everyday language, and the precision / guarantees of a formally specified language.

Hear me out, just incubated a hot new lang that's about to capture the market and VC hearts: SELECT * FROM llm

I know you are probably joking, but: https://lmql.ai/

Re: A guidance language for controlling LLMs

#67
post #50

I’m not understanding how Guidence Accelerating works. It says “ This cuts this prompt's runtime in half vs. a standard generation approach.” and it gives an example of it asking LLM to generate json. I don’t see anywhere how it accelerates anything because it’s a simple json completion call. How can you accelerate that?

The interface makes it look simple, but under the hood it follows a similar approach to jsonformer/clownfish [1] passing control of generation back and forth between a slow LLM and relatively fast python

Let's say you're halfway through a generation of a json blob with a name field and a job field and have already generated

  {
    "name": "bob"
At this point, guidance will take over generation control from the model to generate the next text

  {
    "name": "bob",
    "job":
If the model had generated that, you'd be waiting 70 ms per token (informal benchmark on my M2 air). A comma, followed by a newline, followed by "job": is 6 tokens, or 420ms. But since guidance took over, you save all that time.

Then guidance passes control back to the model for generating the next field value.

  {
    "name": "bob",
    "job": "programmer"
programmer is 2 tokens and the closing " is 1 token, so this took 210ms to generate. Guidance then takes over again to finish the blob

  {
    "name": "bob",
    "job": "programmer"
  }
[1] https://github.com/1rgs/jsonformer https://github.com/newhouseb/clownfish Note: guidance is way more general of a tool than these

Edit: spacing

Re: A guidance language for controlling LLMs

#68

Earlier quoted context omitted.

Not quite sure what the spirit of your comment is. But, yes, they are real technologies. Very confused as to why you would even find that dubious.

Consider how similar your comment reads, for an outsider, to this explanation of AWS InfiniDash: https://twitter.com/TartanLlama/status/1410959645238308866

I'm not considering outsiders. Why should I. It's a reasonable assumption that readers of HN are accustomed to ridiculous sounding tech product names. Further, this is a comment on a thread regarding a particularly new technology in a particularly newly thriving domain. The expectation should therefore be that there will be references to tech even more esoteric than normal. The commenter should have instead thought: oh, new stuff, I wonder what it is, instead of being snarky and pretentious. Man, HN can be totally, digressively insufferable sometimes.

Re: A guidance language for controlling LLMs

#69
post #50

I’m not understanding how Guidence Accelerating works. It says “ This cuts this prompt's runtime in half vs. a standard generation approach.” and it gives an example of it asking LLM to generate json. I don’t see anywhere how it accelerates anything because it’s a simple json completion call. How can you accelerate that?

By not generating the fixed json structure (brackets, commas, etc...) and skipping the model ahead to the next tokens you actually want to generate, I think

Re: A guidance language for controlling LLMs

#70

Earlier quoted context omitted.

Not quite sure what the spirit of your comment is. But, yes, they are real technologies. Very confused as to why you would even find that dubious.

Not dubious, I just read your comment and it felt like I was reading satire. Even the cadence of your words felt funny. Anyway, I’m not surprised. It’s a new market, everyone’s in on it.

You should have led with generosity instead of tacking it on at the end.

It might have saved me from having a ridiculous conversation about the cadence of my words, and instead there might have been a higher chance of someone saying something substantive about my assumptions regarding the technology.

But here we are.

Post reply on HN