Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Brex’s Prompt Engineering Guide

github.com

Post reply on HN
Print view View original

101–110 of 112 posts

Re: Brex’s Prompt Engineering Guide

#101

Post by fortyseven »

dakom wrote: post #65

Why are we calling this "engineering"? Isn't engineering the application of science to solve problems? (math, definitive logic, etc.) Maybe one day we'll have instruments that let us reason about the connections between prompts and the exact state of the AI, so that we can understand the mechanics of causation, but until then, I would not think that being good at asking questions is "engineering" Are most 10 year old…

Some people are way too butt-hurt over a choice of phrasing in a language that absolutely allows for this kind of flexibility. But mostly it's probably some dork in the back fuming away, muttering "I'm a REAL engineer! I went to school to get that title! How dare these intellectual infants abscond with MY valor!"

Re: Brex’s Prompt Engineering Guide

#102

Post by unmole »

rpastuszak wrote: post #72
dakom wrote: post #65

Why are we calling this "engineering"? Isn't engineering the application of science to solve problems? (math, definitive logic, etc.) Maybe one day we'll have instruments that let us reason about the connections between prompts and the exact state of the AI, so that we can understand the mechanics of causation, but until then, I would not think that being good at asking questions is "engineering" Are most 10 year old…

If programming is alchemy, then prompt engineering is more akin to demonic conjurations (communicating with demons): - the Demon knows almost everything, but it can/will lie and trick your bullshit filters so well - then, there's the old trope that you-the conjurer might be able to trick the demon and avoid paying the price for its services (prompt injections) † (dust off your Ars Goetia, my friend) But, in all serio…

> If programming is alchemy, then prompt engineering is more akin to demonic conjurations (communicating with demons):

Honest question. Do you think this analogy is anyway helpful?

Re: Brex’s Prompt Engineering Guide

#103

Post by RC_ITR »

abidlabs wrote: post #92
RC_ITR wrote: post #60

Earlier quoted context omitted.

Yeah, I think the (worrying) confusion is that Amazon calls it a seq2seq model, which was the name of a SOTA RNN from Google a while back. 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.…

That's actually not true: https://github.com/BlinkDL/RWKV-LM

My understanding of both this and Apple AFT is that they are trained with attention, but then inference is done as an RNN.

Is your understanding different?

Re: Brex’s Prompt Engineering Guide

#104

Post by mdaniel »

TrueDuality wrote: post #99
saladtoes wrote: post #62

I've been playing Gandalf in the last few days, it does a great job at giving an intuition for some of the subtleties of prompt engineering: https://gandalf.lakera.ai Thanks for putting this together!

Whoa that was a lot of fun. Are you aware of any other games like this? A sort of CTF for AIs?

https://securitycafe.ro/2023/05/15/ai-hacking-games-jailbrea... showed up in my feed this morning but I haven't tried them to know if they're any fun

I also found the nondeterministic behavior of Gandalf robbed it of being "fun," to say nothing of the 429s (which they claim to have fixed but I was so burned by the experience I haven't bothered going back through the lower levels to find out)

Re: Brex’s Prompt Engineering Guide

#105

Post by [deleted] »

unmole wrote: post #102
rpastuszak wrote: post #72

Earlier quoted context omitted.

If programming is alchemy, then prompt engineering is more akin to demonic conjurations (communicating with demons): - the Demon knows almost everything, but it can/will lie and trick your bullshit filters so well - then, there's the old trope that you-the conjurer might be able to trick the demon and avoid paying the price for its services (prompt injections) † (dust off your Ars Goetia, my friend) But, in all serio…

> If programming is alchemy, then prompt engineering is more akin to demonic conjurations (communicating with demons): Honest question. Do you think this analogy is anyway helpful?

[deleted]

Re: Brex’s Prompt Engineering Guide

#106

Post by nlh »

sigstoat wrote: post #42
nlh wrote: post #36

Earlier quoted context omitted.

…was this written by an LLM? I’m starting to doubt anything on the internet that’s overly cherry and polite. Sigh.

> I’m starting to doubt anything on the internet that’s overly cherry and polite. > …was this written by an LLM? do you find that asking this is constructive?

I do actually. While I personally am excited about LLMs' potential for good, I think a large swath of the world is ready and equally as excited about their potential for harm / spam / fraud / etc. I'm already seeing bots popping up all over other social channels (Reddit in particular), posting a series of overly-cheery LLM-generated content designed to build up high-karma accounts which then get bought and sold on the not-so-open market so that end users can be further spam'd / defrauded. It sucks.

So I'm personally curious in fine-tuning my own "algorithm" for detecting fake content, and pointing it out is helpful for me and, I presume, others who think similarly (and I know there are others).

In this case I may absolutely have been wrong, but even the comments above added to my knowledge and helped.

So yes, I found it very constructive. I hope others did too.

Re: Brex’s Prompt Engineering Guide

#107

Post by ecnahc515 »

dakom wrote: post #83
sgk284 wrote: post #80

Earlier quoted context omitted.

Tweaked my comment a little bit to clarify. Surely we'd agree that not everyone who uses software is a software engineer, but writing software is generally agreed upon as "software engineering". If you consider my comment as a whole, and the linked document, then the application of the definition makes sense. Large Language Models are incredibly similar to black-box non-deterministic interpreters. And prompt engineer…

I've never heard of non-deterministic programming languages. Is that really a thing? (I mean - cue the JS jokes and all, but, really?) Fwiw, to me, writing prompts feels most similar to management, directing, maybe psychotherapy (though I never worked in that, just guessing). Knowing how to adapt and use language to guide the "other" to achieve a goal, but without having insight into the exact way they go about it. I…

I mean, quantum programming is basically non deterministic. It's not a nature of the program though, but the underlying "hardware".

Re: Brex’s Prompt Engineering Guide

#108

Post by ukuina »

typpo wrote: post #18

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…

Thank you so much for this, especially for allowing custom LLM calls to allow testing of local models.

Re: Brex’s Prompt Engineering Guide

#109

Post by ukuina »

akisej wrote: post #55

This seems overall well-written and well-explained, but curious for that piece on fine-tuning. This article only recommends it as a last resort. That makes sense for a casual user, but if you're a company seriously using LLMs to provide services for your customers, wouldn't the cost of training data be offset by the potential gains you have and the edge cases you might automatically cover by fine-tuning instead of tr…

The concern with finetuning, even for specialized use-cases, is that you are binding yourself to the underlying model. Given rapid advancements in the field, this does not seem a prudent use of engineering time.

Having a hierarchy of prompts with context stuffing allows for rapid switching across models with a few (non-trivial) surface-level prompt updates while the deeper prompts stay static.

Re: Brex’s Prompt Engineering Guide

#110

Post by dakom »

martythemaniak wrote: post #97
dakom wrote: post #65

Why are we calling this "engineering"? Isn't engineering the application of science to solve problems? (math, definitive logic, etc.) Maybe one day we'll have instruments that let us reason about the connections between prompts and the exact state of the AI, so that we can understand the mechanics of causation, but until then, I would not think that being good at asking questions is "engineering" Are most 10 year old…

> Isn't engineering the application of science to solve problems? (math, definitive logic, etc.) Most definitely not. Engineering more often than not preceeds the science. You don't have to have an analytical and theoretical understanding of something in order to harness it and make practical use of it. In reality, there's a strong feedback loop, where practical hacks will guide the science, the development of which…

Let's take airplanes as an example.

1. Do we start calling travel agents "aviation engineers" because they use airplanes to solve problems?

2. I sure hope the engineers who build planes aren't just winging it (ba doom pssh)

3. Context matters. Scientific knowledge increases over time, but isn't there a difference between willfull and unavoidable ignorance? If an engineer from the early days of flight were transported to SpaceX today, but they ignored the math and constructed rockets that we know with certainty will not fly, but they are convinced it will work due to sheer inner conviction, that's no longer engineering imho. Even if it may have been in their time, as long as they were using the known science of their day.

Post reply on HN