| ▲ | sethkim 5 hours ago | |||||||
We build a product that's somewhat similar in spirit to DSPy, but people come to us for different reasons than the OP listed here. 1) It's slow: you first have to get acquainted with DSPY and then get hand-labeled data for prompt optimization. This can be a slow process so it's important to just label cases that are ambiguous, not obvious. 2) They know that manual prompt engineering is brittle, and want a prompt that's optimized and robust against a model they're invoking, which DSPy offers. However, it's really the optimizer (ex. GEPA) doing the heavy-lifting. 3) They don't actually want a model or prompt at all. They want a task completed, reliably, and they want that task to not regress in performance. Ideally, the task keeps improving in production. Curious if folks in this thread feel more of these pains than the ones in the article. | ||||||||
| ▲ | sbpayne 5 hours ago | parent [-] | |||||||
I think in some sense, this is the real thing everyone wants. Everything else is kind of an implementation detail! Would be really curious to see what you're building! | ||||||||
| ||||||||