I see a few comments about how the interface should be better.
I would argue that the current interface is broad and can be adapted to a wide range of needs.
The real value I see (and an area I've been exploring recently) is creating abstractions around prompt engineering.
The idea is that at the moment, the better the prompt -> the more relevant the output.
However businesses that act as proxies for chatgpt can take user input -> inject it into their prompt-engineering system -> deliver better results.
As a basic example:
1) You provide an application that helps people maintain their cars
2) You have a freeform question input about specific car maintenance tasks
3) Knowing certain prompt-segments that typically lead to better results for the category of "novice car maintainer", you parse their question, upgrade it with your prompt-generator, then send that question to chatgpt
Additionally, you can go even further by generating the information _before your customers even ask_.
Ask chatgpt what the most common questions are about each piece of car maintenance (could be installation instructions, cost of parts, etc) and have these available straight in the application.
It's as if chatgpt is the database, and prompt engineering systems are the query-optimizers. I know certain things I can alter about a prompt to increase the relevance and usefulness of the results to my target audience.
Additionally, it will be interesting to see how people use learning methods to auto-generate the best prompts (it's a bit of machine-learning on machine-learning happening). I've spoken to one person working in this space, and it's interesting how effectively the outer layer is reversing the prompt-parsing layer buy scoring the end-to-end results.
Currently working with a couple of people in this space and it's exciting the types of results that user-focused engineering can bring to an improved user-experience.
Interesting. It's almost the exact same structure (although better organized) that I have built in my "AI Programmer" project (also in Node). Which by the way I hope to have a new release within a week or so. I am not mentioning the domain name again until I have the new release because it much, much better than the version I have up now.
The core idea is that you need a certain structure in order to deal with the limitations of GPT-3.5 or whatever. To get the best output, you give it a brief overview of what you want, a few examples, and the history of interaction. OpenAI's API does not remember the interaction history for you. And the limit is 4000 or 8000 tokens so you will need to truncate the beginning of the conversation at some point.
So this library provides a structure since it's something you will need to repeat for just about every significant text completion application or module.
I’m surprised Bing’s chat meltdowns haven’t had more air time on HN. People are going to start calling it a living creature.
It works in Python too: https://github.com/microsoft/prompt-engine-py
Tangentially related: has anyone here tried to figure out what programming language a LLM-based generator would be most successful at writing? Or what language features are necessary for LLM's success at code generation?
I've tried but unfortunately all of my searches return results about languages used for building models (e.g., Python, for some reason).
I figure it'd probably be a typed language with a meaty standard library, good type inference, and high-quality low-code packages that would require fewer generated tokens to do useful work. Or maybe a language with fewer ways to do basic tasks -- if there is somehow only one way to do a thing, then the generator would be most likely to write code using that one way. I'll fully admit that these guesses are naive and based on limited understanding of how LLMs work.
If we're adjusting the way we speak to AIs, are we training them or are they training us?
Interesting, I just made myself something similar[1] because I found myself using the same prompts over and over again in either the OpenAI playground or in ChatGPT.
The simple tool quickly provides builds up a form that either myself, or my staff can use.
So far my pre-canned prompt forms are as follows[2].
[1] https://files.littlebird.com.au/Screen-Recording-2023-02-16-...
[2] https://files.littlebird.com.au/Screen-Shot-2023-02-16-14-25...
I am getting old: I read the description two times and checked examples yet still don't understand the utility. I do understand Midjourney prompt engineering though.
I can’t help shake the feeling that something closer to code (or specific training?) and further from natural language should be being used to configure these models at this stage of development. I was _astounded_ by the ‘Sydney document’ being MS’s way of ‘configuring’ New Bing.
Admittedly I have closer to a layperson’s understanding than an expert’s, but with some knowledge of how neural networks work, and having played moderately with ChatGPT, prompt engineering just seems _so unlikely_ to me to ever be able to create systems that behave as we desire them to behave anywhere close to 100% of the time, at least until the systems are orders of magnitude better at understanding (if that’s even possible).
Maybe once we develop a large enough library of prompts then we can either build a prompt selection prompt or find a common pattern in successful prompts that might allow a prompt generating prompt.
How does this compare or contrast to LangChain? It seems similar in that it is an abstraction on top of a lower level API but aside from that at a glance I can't tell the difference.
Brings to mind a quote from The Hitchhiker's Guide to the Galaxy:
> "Only once you do know what the ultimate question actually is, you'll know what the answer means."
Does anyone know what is the difference between Bing/Sydney and ChatGPT3 in terms of "generative power"?
Which job title sounds cooler: Senior Prompt Engineer or Senior Prompt Designer?
Why we call this prompt "engineering"? The prompt is just a way to interact with the whatever ML model is behind... in that regard it's similar SQL or any other interface. Sure thing I've never heard of "SQL engineering" or something like that.
Mercifully it doesn't force you to use TypeScript
Does it Speak Lebowski
Isn't the point of having such a simple interface that we should not have to think hard about how we ask the question? I feel like defining a structure for the query such that the machine outputs something useful is something we figured out a long time ago. Or maybe I'm just a luddite that doesn't understand the utility of something like this. Plus: if you know what the answer is supposed to be, why are you asking the computer?
/r
I'm just astounded by Microsoft's execution in both business and open source. It's such a stark contrast to the Ballmer era. They were a closed ecosystem. And now they invest so heavily in being open. It's amazing to see really. Hugely beneficial for the entire industry. Not everything that comes out of there is going to be gold but this is great.
I actually sketched out an API for my own version of this:
def ask(question: str) -> str:
pass # call ChatGPT
How is this different from the Open Assistant [1] project? Featured recently: Open Assistant: Conversational AI for Everyone - https://news.ycombinator.com/item?id=34654809
[1]: https://projects.laion.ai/Open-Assistant/docs/intro
edit: changed OA reference to docs homepage
[dead]
[dead]
[flagged]
Very cool! But for hard enough problems, prompt engineering is kind of like hyperparameter tuning. It's only a final (and relatively minor) step after building up an effective architecture and getting its modules to work together.
DSP provides a high-level abstraction for building these architectures—with LMs and search. And it gets the modules working together on your behalf (e.g., it annotates few-shot demonstrations for LM calls automatically).
Once you're happy with things, it can compile your DSP program into a tiny LM that's a lot cheaper to work with.
https://github.com/stanfordnlp/dsp/