[NeutralCrane]

The more I’ve looked at DSPy, the less impressed I am. The design of the project is very confusing with non-sensical, convoluted abstractions. And for all the discussion surrounding it, I’ve yet to see someone actually using for something other than a toy example. I’m not sure I’ve even seen someone prove it can do what it claims to in terms of prompt optimization.

It reminds me very much of Langchain in that it feels like a rushed, unnecessary set of abstractions that add more friction than actual benefit, and ultimately boils down to an attempt to stake a claim as a major framework in the still very young stages of LLMs, as opposed to solving an actual problem.

[isoprophlex]

The magic sauce seems to be, at every turn, "... if you have some well defined metric to optimize on."

And that's not really a given, in reality. It allows all sorts of tricks to do what DSPy is aiming for, which you won't be able to do in real life.

Unless I'm sorely mistaken, but that's my take on the whole thing.

[isaacbmiller]

Disclaimer: original blog author

> as opposed to solving an actual problem

This was literally the point of the post. No one really knows what the future of LLMs will look like, so DSPy just iteratively changes in the best way it can for your metric (your problem).

> someone actually using for something other than a toy example

DSPy, among the problems I listed in the post, has some scalability problems, too, but I am not going to take away from that. There are at least early signs of enterprise adoption from posts like this blog: https://www.databricks.com/blog/optimizing-databricks-llm-pi...

[curious_cat_163]

The abstractions could be cleaner. I think some of the convolution is due to the evolution that it has undergone and core contributors have not come around to being fully “out with the old”.

I think there might be practical benefits to it. The XMC example illustrates it for me:

https://github.com/KarelDO/xmc.dspy

[isaacfung]

This repo has some less trivial examples. https://github.com/ganarajpr/awesome-dspy

You can try STORM(also from Stanford) and see the prompts it generates automatically, it tries to expand on your topic and simulate the collaboration among several domain experts https://github.com/stanford-oval/storm

An example article I asked it to generate https://storm.genie.stanford.edu/article/how-the-number-of-o...

[Der_Einzige]

Agreed 100%. DSPy along with libraries inspired by it (i.e. https://github.com/zou-group/textgrad) are nothing more than fancy prompt chains under the hood.

These libraries mostly exist as "cope" for the fact that we don't have good fine-tuning (i.e. lora) capabilities for ChatGPT et al, so we try to instead optimize the prompt.

[qeternity]

Glad to see others saying this. I haven't looked at it in some months, but I previously realized it's mostly a very complicated way to optimize few-shot learning prompts. It's hardly whatever magical blackbox optimizer they try to market it as.

[dmarchand90]

My guess is it will be like pascal or smalltalk, an important development for illustrating a concept but is ultimately replaced by something more rigorous

[isaacbmiller]

> These libraries mostly exist as "cope"

> nothing more than fancy prompt chains under the hood

Some approaches using steering vectors, clever ways of fine-tuning, transfer decoding, some tree search sampling-esque approaches, and others all seem very promising.

DSPy is, yes, ultimately a fancy prompt chain. Even once we integrate some of the other approaches, I don't think it becomes a single-lever problem where we can only change one thing(e.g., fine-tune a model) and that solves all of our problems.

It will likely always be a combination of the few most powerful levers to pull.