Live data from Hacker News

Context engineering

chrisloy.dev

31–40 of 70 posts

Re: Context engineering

#31

There is nothing precise about crafting prompts and context—it's just that, a craft. Even if you do the right thing and check some fuzzy boundary conditions using autoscorers, the model can still change out from beneath you at any point and totally alter the behavior of your system. There is no formal language here. After all, mathematics exists because natural language is notoriously imprecise. The article has some…

I think it's fair to question the use of the term "engineering" throughout a lot of the software industry. But to be fair to the author, his focus in the piece is on design patterns that require what we'd commonly call software engineering to implement. For example, his first listed design pattern is RAG. To implement such a system from scratch, you'd need to construct a data layer (commonly a vector database), retri…

long shot, apropos of nothing, just recognized your name:

If you are the cincinnatian poet Caleb Kaiser, we went to college together and I’d love to catch up. Email in profile.

If you aren’t, disregard this. Sorry to derail the thread.

Re: Context engineering

#32
post #18
post #7

Are we still calling this things engineering?

Yes, and we've also decided that they deserve the title "engineering" more than software engineering does. Most engineering disciplines have to deal with tolerances and uncertainty - the real world is non-deterministic. Software engineering is easy in comparison because computers always do exactly what you tell them to do. The ways LLMs fail (and the techniques you have to use to account for that) have more in common…

I completely agree that much of software engineering is not engineering, and building systems around LLMs is no better in this sense.

When the central component of your system is a black box that you cannot reason about, have no theory around, and have essentially no control over (a model update can completely change your system behavior) engineering is basically impossible from the start.

Practices like using autoscorers to try and constrain behaviors helps, but this doesn't make the enterprise any more engineering because of the black box problem. Traditional engineering disciplines are able to call themselves engineering only because they are built on sophisticated physical theories that give them a precise understanding of the behaviors of materials under specified conditions. No such precision is possible with LLMs, as far as I have seen.

The determinism of traditional computing isn't really relevant here and targets the wrong logical level. We engineer systems, not programs.

Re: Context engineering

#33
post #18

Earlier quoted context omitted.

Yes, and we've also decided that they deserve the title "engineering" more than software engineering does. Most engineering disciplines have to deal with tolerances and uncertainty - the real world is non-deterministic. Software engineering is easy in comparison because computers always do exactly what you tell them to do. The ways LLMs fail (and the techniques you have to use to account for that) have more in common…

I completely agree that much of software engineering is not engineering, and building systems around LLMs is no better in this sense. When the central component of your system is a black box that you cannot reason about, have no theory around, and have essentially no control over (a model update can completely change your system behavior) engineering is basically impossible from the start. Practices like using autosc…

This is completely backwards. Engineers built steam engines first through trial and error and then eventually the laws of thermodynamics were invented to explain how steam engines work.

Trial and error and fumbling around and creating rules of thumbs for systems you don’t entirely understand is the purest form of engineering.

Re: Context engineering

#34
post #18
post #7

Are we still calling this things engineering?

Yes, and we've also decided that they deserve the title "engineering" more than software engineering does. Most engineering disciplines have to deal with tolerances and uncertainty - the real world is non-deterministic. Software engineering is easy in comparison because computers always do exactly what you tell them to do. The ways LLMs fail (and the techniques you have to use to account for that) have more in common…

>The ways LLMs fail (and the techniques you have to use to account for that) have more in common than physical engineering disciplines than software engineering does!

Ah yes, the God given free parameters in the Standard Model, including obviously the random seed of a transformer. What if just put 0 in the inference temperature? The randomness in llms is a technical choice to generate variations in the selection of the next token. Physical engineering? Come on.

Re: Context engineering

#35
post #34
post #18

Earlier quoted context omitted.

Yes, and we've also decided that they deserve the title "engineering" more than software engineering does. Most engineering disciplines have to deal with tolerances and uncertainty - the real world is non-deterministic. Software engineering is easy in comparison because computers always do exactly what you tell them to do. The ways LLMs fail (and the techniques you have to use to account for that) have more in common…

>The ways LLMs fail (and the techniques you have to use to account for that) have more in common than physical engineering disciplines than software engineering does! Ah yes, the God given free parameters in the Standard Model, including obviously the random seed of a transformer. What if just put 0 in the inference temperature? The randomness in llms is a technical choice to generate variations in the selection of t…

>just set temp to 0 to make LLMs deterministic

Does that really work? And is it affected by the almost continuous silent model updates? And gpt-5 has a "hidden" system prompt, even thru the API, which seemed to undergo several changes since launch...

Re: Context engineering

#36
post #22
post #18

Earlier quoted context omitted.

Yes, and we've also decided that they deserve the title "engineering" more than software engineering does. Most engineering disciplines have to deal with tolerances and uncertainty - the real world is non-deterministic. Software engineering is easy in comparison because computers always do exactly what you tell them to do. The ways LLMs fail (and the techniques you have to use to account for that) have more in common…

Lol. This has to be a troll. No way someone seriously wrote this and meant it.

In the absence of a clear indicator, either interpretation could be possible:

https://en.wikipedia.org/wiki/Poe's_law

Re: Context engineering

#37
post #35
post #34

Earlier quoted context omitted.

>The ways LLMs fail (and the techniques you have to use to account for that) have more in common than physical engineering disciplines than software engineering does! Ah yes, the God given free parameters in the Standard Model, including obviously the random seed of a transformer. What if just put 0 in the inference temperature? The randomness in llms is a technical choice to generate variations in the selection of t…

>just set temp to 0 to make LLMs deterministic Does that really work? And is it affected by the almost continuous silent model updates? And gpt-5 has a "hidden" system prompt, even thru the API, which seemed to undergo several changes since launch...

It famously does not: https://thinkingmachines.ai/blog/defeating-nondeterminism-in...

Re: Context engineering

#38
post #35
post #34

Earlier quoted context omitted.

>The ways LLMs fail (and the techniques you have to use to account for that) have more in common than physical engineering disciplines than software engineering does! Ah yes, the God given free parameters in the Standard Model, including obviously the random seed of a transformer. What if just put 0 in the inference temperature? The randomness in llms is a technical choice to generate variations in the selection of t…

>just set temp to 0 to make LLMs deterministic Does that really work? And is it affected by the almost continuous silent model updates? And gpt-5 has a "hidden" system prompt, even thru the API, which seemed to undergo several changes since launch...

Strictly speaking, it should work. We don't have a _real_ RNG yet and with the same seed any random function becomes deterministic. But behind the blackbox of LLM providers who know what's tunned processing your request.

But my point stands. The non-deterministic nature of LLMs are implementation details, not even close to physical constraints as the parent comment suggest.

Re: Context engineering

#39
post #37
post #35

Earlier quoted context omitted.

>just set temp to 0 to make LLMs deterministic Does that really work? And is it affected by the almost continuous silent model updates? And gpt-5 has a "hidden" system prompt, even thru the API, which seemed to undergo several changes since launch...

It famously does not: https://thinkingmachines.ai/blog/defeating-nondeterminism-in...

Hey Simon, do you have any posts diving into how one might be able to deal with evaluating LLMs or Machine Learning models in general when reproducibility is so difficult given non-determinism? Pytorch has an article on it https://docs.pytorch.org/docs/stable/notes/randomness.html but then doesn't really go into how one would then take this deterministic result, and evaluate a model that is in production (which would very likely need for performance reasons the non-determinism features enabled).

While this affects all models it seems, I think the case gets worse for in particular LLMs because I would imagine all backends, including proprietary ones, are batching users prompts. Other concurrent requests seem to change the output of your request, and then if there is even a one token change to the input or output token, especially on large inputs or outputs, the divergence can compound. Also vLLM's documentation mentions this: https://docs.vllm.ai/en/latest/usage/faq.html

So how does one do benchmarking of AI/ML models and LLMs reliably (lets ignore arguing over the flaws of the metrics themselves, and just the fact that the output for any particular input can diverge given the above). You'd also want to redo evals as soon as any hardware or software stack changes are made to the production environment.

Seems like one needs to setup a highly deterministic backend, by forcing non-deterministic behavior in pytorch and using a backend which doesn't do batching for an initial eval that would allow for troubleshooting and non-variation in output to get a better sense of how consistent the model without the noise of batching and non-deterministic GPU calculations/kernels etc.

However then, for production, when determinism isn't guaranteed because you'd need batching and non-determism for performance, I would think that one would want to do multiple runs in various real-world situations (such as multiple users doing all sorts of different queries at the same time) and do some sort of averaging of the results. But I'm not entirely sure, because I would imagine the types of queries other users are making would then change the results fairly significantly. I'm not sure how much the batching that vLLM does would change the results of the output; but vLLM does say that batching does influence changes in the outputs.

Re: Context engineering

#40
post #18
post #7

Are we still calling this things engineering?

Yes, and we've also decided that they deserve the title "engineering" more than software engineering does. Most engineering disciplines have to deal with tolerances and uncertainty - the real world is non-deterministic. Software engineering is easy in comparison because computers always do exactly what you tell them to do. The ways LLMs fail (and the techniques you have to use to account for that) have more in common…

The tools mechanical and civil engineers use are predictable. You're confusing the things these engineers design, which have tolerances and things like that, with the tools themselves.

If an engineer built an internal combustion engine that misfired 60% of the time, it simply wouldn't work.

If an engineer measured things with a ruler that only measured correctly 40% of the time, that would be the apt analogy.

The tool isn't what makes engineering a practice, it's the rigor and the ability to measure and then use the measurements to predict outcomes to make things useful.

Can you predict the outcome from an LLM with an "engineered" prompt?

No, and you aren't qualified to even comment on it since your only claim to fame is a fucking web app

Post reply on HN