Live data from Hacker News

DSPy: Framework for programming with foundation models

github.com

41–50 of 56 posts

Re: DSPy: Framework for programming with foundation models

#41
post #38

Earlier quoted context omitted.

Ah okay makes sense, yeah we'll release more examples. This is just an intro to the key concepts/modules.

The problem is, there is a big song and dance about string template prompts. …but, carefully crafted string templates would be a) simpler and b) arguably better with existing solutions for this task, because it’s a trivial task and you can hand massage your string template prompts for that. So, the narrative really doesn’t make sense, unless you’re doing something hard , but the example just shows doing something eas…

@wokwokwok Okay now we disagree. This task is not easy, it's just easy to follow in one notebook. (If it were easy, the RAG score wouldn't be 26%.)

As for "carefully crafted string templates", I'm not sure what your argument here is. Are you saying you could have spent a few hours of trial and error writing 3 long prompts in a pipeline, until you matched what the machine does in 60 seconds?

Yes, you probably could have :-)

Re: DSPy: Framework for programming with foundation models

#42

Just yesterday I was thinking to myself "I wonder how long it will be until we start generating prompts using code and then we're just writing code again"

You're not the first to think that to yourself :)

> It may be illuminating to try to imagine what would have happened if, right from the start our native tongue would have been the only vehicle for the input into and the output from our information processing equipment. My considered guess is that history would, in a sense, have repeated itself, and that computer science would consist mainly of the indeed black art how to bootstrap from there to a sufficiently well-defined formal system.

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/E...

Re: DSPy: Framework for programming with foundation models

#44
post #32
post #31

Earlier quoted context omitted.

I really want to understand that second part! I think that's the part I haven't been able to get my head around yet.

Here's the key idea. You give DSPy (1) your free-form code with declarative calls to LMs, (2) a few inputs [labels optional], and (3) some validation metric [e.g., sanity checks]. It simulates your code on the inputs. When there's an LM call, it will make one or more simple zero-shot calls that respect your declarative signature. Think of this like a more general form of "function calling" if you will. It's just tryi…

Hi Omar - thanks for engaging here. I have a similar question to simonw, it _feels_ like there is something useful here but I haven't managed to grok it yet, after sitting through the tutorial notebooks.

Specifically, to your description above, I'd love seeing specific retrieval examples, where you need more-complex pipelines. Zero shot QA (1-step), few-shot QA (2-step), retrieval + few-shot QA (3-step) all make sense, but when the README starts talking about demonstrations, I can't really follow when is that actually needed. Also, it starts feeling too magical when you introduce "smaller LMs" since I don't know what those are.

Re: DSPy: Framework for programming with foundation models

#45
post #32
post #31

Earlier quoted context omitted.

I really want to understand that second part! I think that's the part I haven't been able to get my head around yet.

Here's the key idea. You give DSPy (1) your free-form code with declarative calls to LMs, (2) a few inputs [labels optional], and (3) some validation metric [e.g., sanity checks]. It simulates your code on the inputs. When there's an LM call, it will make one or more simple zero-shot calls that respect your declarative signature. Think of this like a more general form of "function calling" if you will. It's just tryi…

I'm trying to wrap my head around this project too, since it does seem interesting. Similar to what OP wrote, the sense I got from poking around (and of course from reading the bit in the README that basically says exactly this) was that there are two distinct pieces here, the first being a nice, clean library for working directly with LLMs that refreshingly lacks the assumptions and brittle abstractions found in many current LLM frameworks, and the second being everything related to automatic optimization of prompts. The second half is the part I'm trying to better understand - more specifically, I understand that it uses a process to generate and select examples that are then added to the prompt, but am unclear if it's also doing any prompt transformations other than these example-related improvements. I guess to put it another way, if one were to reframe the second half as a library for automatic n-shot example generation and optimization, made possible via the various cool things this project has implemented like the spec language/syntax, is there anything lost or not covered by the new framing?

As more of an aside, I gave the paper a quick skim and plan on circling back to it when I have more time - are the ideas in the paper an accurate/complete representation of the under-the-hood workings, and general type of optimizations being performed, of the current state of the project?

As another related aside, I vaguely remember coming across this a month or two ago and coming away with a different impression/understanding of it at the time - has the framing of or documentation for the project changed substantially recently, or perhaps the scope of the project itself? I seem to recall focusing mostly on the LM and RM steps and reading up a bit on retrieval model options afterwards. I could very well be mixing up projects or just had focused on the wrong things the first time around of course.

Re: DSPy: Framework for programming with foundation models

#46
post #45
post #32

Earlier quoted context omitted.

Here's the key idea. You give DSPy (1) your free-form code with declarative calls to LMs, (2) a few inputs [labels optional], and (3) some validation metric [e.g., sanity checks]. It simulates your code on the inputs. When there's an LM call, it will make one or more simple zero-shot calls that respect your declarative signature. Think of this like a more general form of "function calling" if you will. It's just tryi…

I'm trying to wrap my head around this project too, since it does seem interesting. Similar to what OP wrote, the sense I got from poking around (and of course from reading the bit in the README that basically says exactly this) was that there are two distinct pieces here, the first being a nice, clean library for working directly with LLMs that refreshingly lacks the assumptions and brittle abstractions found in man…

Thanks! Lots to discuss from your excellent response, but I'll address the easy part first: DSPy is v2 of DSP (demonstrate-search-predict).

The DSPy paper hasn't been released yet. DSPy is a completely different thing from DSP. It's a superset. (We actually implemented DSPy _using_ DSPv1. Talk about bootstrapping!)

Reading the DSPv1 paper is still useful to understand the history of these ideas, but it's not a complete picture. DSPy is meant to be much cleaner and more automatic.

Re: DSPy: Framework for programming with foundation models

#48
I'd love to see some more examples!

This seems like it could be particularly useful in restricting the domain of the LLM. I.e. ensuring it outputs specific values and few-shot training these steps.

I think there may a really powerful integration here with LMQL. Has there been any thinking about doing so? LMQL seems quite powerful in constraining values and limiting the number of tokens used. This could be a great option for some steps. I.e. a categorization "is this task type X or type Y" before continuing in the logic flow.

Re: DSPy: Framework for programming with foundation models

#49

Just yesterday I was thinking to myself "I wonder how long it will be until we start generating prompts using code and then we're just writing code again"

I welcome programming English++ with open arms so long as I can scold it when it makes mistakes and it doesn’t require move semantics. I’m joking of course but I do think LLM’s will become part of the programming language lexer of some kind. If not already being looked into.

Introducing non-deterministic inputs into programs is already wild.

I think once we get past "make the LLM generate #$%!#@ JSON" we will start seeing a lot more of this, since we will then be able to constrain the code-paths that are followed.

I could absolutely see LLM-powered operators being introduced at some point, that we use just like an if statement.

Imagine "if(input like LLM(greeting))" or while(LLM(input) like "interested")

essentially distilling unstructured inputs into a canonical form to be used in control flows:

Switch(LLM(input)): - case request - case question - case query

Re: DSPy: Framework for programming with foundation models

#50
post #22

Looks interesting and seems to not make some of the mistakes that other frameworks make (langchain, llamaindex, etc.) I was pretty apprehensive when I looked at your short hand signature API. I'm really not a fan of these custom mini languages, but it looks like it's fairly constrained at the moment and has an expanded form with a sane Python API. My only concern is that the short hand signatures spiral out of contro…

Is anyone working on this? I'd love be able to work with a full spec.

I think colang from Nvidia seems like the "closest" so far, and that is pretty specifically focused on chatbots which is to bad.

Post reply on HN