51–60 of 112 posts
I wonder if linguistic and English majors would end up benefiting in this trend of "prompt engineering."
Are there established best practices for "engineering" prompts systematically, rather than through trial-and-error? Editing prompts is like playing whack-a-mole: once you clear an edge case, a new problem pops up elsewhere. I'd really like to be able to say, "this new prompt performs 20% better across all our test cases". Because I haven't found a better way, I am building https://github.com/typpo/promptfoo , a CLI t…
https://observablehq.com/@tomlarkworthy/colossal-cave-chatgp...
I wonder if linguistic and English majors would end up benefiting in this trend of "prompt engineering."
Perhaps, but this space suffers from the Armageddon astronaut/fire figher problem. It is easier to teach a Computer Science Major good english, than it is to teach an English Major computer science.
Plus when you go meta and ask LLMs to generate prompts for themselves, you own language proficiency becomes even less important.
I do think English/language proficiency will help with Generative image AIs like Midjourney. Like if someone could describe a scene in extreme detail that's more likely to produce a result closer to what you want.
I wonder if linguistic and English majors would end up benefiting in this trend of "prompt engineering."
The speed this stuff is moving prompt engineering may just be a fad and the next wave of models changes things again.
If they persist as a thing, then most of the hard work will just be abstracted away using a standard library of prompts available in a point and click fashion for 99% of use cases.
This reflects astonishingly poorly on Brex. What customer wants to hear that Brex is using "a non-deterministic model" for "production use cases" like "staying on top of your expenses"? I don't see them acknowledge the downsides of that non-determinism anywhere, let alone hallucination, even though they mention the latter. Hallucinating an extra expense, or missing one, could have serious consequences. This is also p…
Thanks very much for posting this! I haven't yet finished reading the whole thing, but even just the first section about the history of LLMs, explaining some of the basic concepts, etc., I found to be a very well-written and useful info, and it was really nice that it linked out to source material. So many times when you go into reading stuff about the latest AI technique or feature it can feel like you need to do a…
…was this written by an LLM? I’m starting to doubt anything on the internet that’s overly cherry and polite. Sigh.
That or we kick into a world of ultra short lived memes, where the models will always lag. A rolling cipher of no-context memetic emojis to indicate someone is behind the keyboard.
I wonder if linguistic and English majors would end up benefiting in this trend of "prompt engineering."
For at least the next few months anyway. The speed this stuff is moving prompt engineering may just be a fad and the next wave of models changes things again. If they persist as a thing, then most of the hard work will just be abstracted away using a standard library of prompts available in a point and click fashion for 99% of use cases.
This is a question borne of ignorance: why does Brex, a bank, care about AI like this?
I firmly believe that the introduction of LLMs will be as essential to the future of human-computer interaction as the introduction of the mouse and keyboard were. Every technology company with sufficient resources should be exploring the implications of LLMs on their business.
Most of our research for LLMs falls into three buckets:
1) Internal processes – Any area where an employee is writing or reading some kind of communication is up for grabs.
2) Developer productivity – Whether it's improving the quality of code, reducing time to implementation, or answering questions about our services and architecture... empowering our eng team with LLMs is an area of major interest.
3) Customer Experience – Employees frequently need to write memos for expenses or have questions about Travel & Expense policies (e.g. "Can I buy alcohol at this team dinner?").
We're, of course, exploring far more interesting use cases than just what's above, but that's the low hanging fruit.
Worringly, I am it sure the people working on this really understand what a Transformer is Quote from them: “ There is still active research in non-transformer based language models though, such as Amazon’s AlexaTM 20B which outperforms GPT-3“ Quote from said paper “ For AlexaTM 20B, we used the standard Transformer model architecture“ (Its just an encoder decoder transformer)
Ofc now, seq2seq just means what you said (an encoder/decoder model, which is actually what a “truly vanilla” transformer would be anyway).
The fact that any serious researcher thinks any other serious researchers are using models without self attention is the real red flag here.
No one is trying to use other models anymore because they do not scale. There’s enough variety within transformers that you could argue we need a new level of taxonomy, but transformers are basically it for now.