341–348 of 348 posts
I agree with the sentiment, but I think the conclusion should be altered. When you hit the limit of prompting, you need to move from using LLMs at run time to accomplish a task to using LLMs to write software to accomplish the task. The role of LLMs at run time will generally shrink to helping users choose compliant inputs to a software system that embodies hard business rules.
Earlier quoted context omitted.
I noticed that too. Unless you _ask_ for a script, they throw away the scripts they write. They are particularly bad at complex multiline parsing. Writing all sorts of weird/crude python/awk scripts and getting confused in the process. I wish they would use Perl6/Grammer or Haskell/Parsec or similar and write better parsing scripts.
For the non haskell folks like myself, what would that look like/ why is parsing better? Perl i get
Perl6/Raku has built in grammers that can do that idiomatically.
If you have a couple minutes, give this a glance. It will give you an idea.
https://andrewshitov.com/2018/10/31/a-simple-parser-in-perl-...
I am no expert in haskell either. But parsec is similar in concept.
Earlier quoted context omitted.
Wait... why? Making an unreliable, nondeterministic system give reliable results for a bounded task with well-understood parameters is... like half of engineering, no? There's a huge difference between "generate this code here's a vague feature description" and "here's a list of criteria, assign this input to one of these buckets" -- the latter is obviously subject to prompt engineering, hallucination, etc -- but so…
>the latter is obviously subject to prompt engineering, hallucination, etc -- but so can a human pipeline! ...which is why we write deterministic code to take the human out of the pipeline. One of the early uses of computers was calculating firing tables for artillery, to replace teams of humans that were doing the calculations by hand (and usually with multiple humans performing each calculation to catch errors). If…
- Get humans to check each other's work
- Systematize the process -- breaking it down into smaller and smaller tasks where the likelihood of mistakes decreases
- Replace as much as possible with deterministic code
There's absolutely no reason you can't do this with LLMs -- and it might help quite a bit since LLMs are cheap. There's also hybrid systems -- where human checkers are replaced or augmented with LLM checkers.
For example -- I have an LLM check all my scientific papers for typos and minor errors. It's caught quite a few, and when it caught something that was not actually an error, it was usually something whuch would benefit from clarification anyways.
Now -- if I could afford to pay a grad student to do that, would be even better! But I can't, and if I could, not all the work which warrants a few cents of tokens warrants a few hundred dollars of tedious grad student labor -- especially when the latter has a very strong incentive to say LGTM (nothing here is life critical!)
Likewise, we could imagine:
- A deterministic process with a heuristic + an LLM in the loop checking, for example -- "is this likely correct?" -- perhaps escalating to a human (or a bigger LLM) in case of anomaly. I can see this being amazingly useful for automated refactors.
- Automatic paperwork/customer service processing -- if the cost-of-failure can be bounded (say X$) and testing shows failure happens on average only reasonably often (say Y% of the time) -- it might be cheaper to run an AI system and eat that cost, especially if continuous monitoring lets you know if you have to "shut it down."
In both cases -- there's nothing stopping an LLM from potentially having better-than-human average performance, and perhaps delegating real edge cases to actual experts. Remember: you're not competing with motivated PhDs, you're competing with minimum wage labor reading a list of instructions which is like a prompt except poorly formatted and missing steps.
Earlier quoted context omitted.
Wait... why? Making an unreliable, nondeterministic system give reliable results for a bounded task with well-understood parameters is... like half of engineering, no? There's a huge difference between "generate this code here's a vague feature description" and "here's a list of criteria, assign this input to one of these buckets" -- the latter is obviously subject to prompt engineering, hallucination, etc -- but so…
Because it's not possible . There is nothing you can say to the LLM that will guarantee that something happens. It's not how it works. It will maybe be taken into consideration if you're lucky. But if you're trying to tell me that every time you list criteria you get them all perfectly matched, you're clearly gifted.
I wonder if a part of the problem isn't just the misapplication of LLMs in the first place. As has been mentioned elsewhere, perhaps the agent's prompt should be to write code to accomplish as much of the task in as repeatable/verifiable/deterministic a way as possible. This would hopefully include validation of the agent's output as well. The overall goal would be to keep the LLM out of doing processing that could b…
I think there is a flow in most organizations from: llm -> prompt -> result llm -> prompt + prompt encoded as skill -> result llm -> prompt + deterministic code encoded as skill -> result I do think prompting to generate code early can shortcut that path to deterministic code, but we're still essentially embedding deterministic code in a non-deterministic wrapper. There is a missing layer of determinism in many cases…
This is why I frequently refer to "next generation AIs" that aren't just LLMs. LLMs are pretty cool and I expect that even if we see no further foundational advancement in AIs that we're going to continue to see them exploited in more interesting ways and optimized better. Even if the models froze as they are today, there's a lot more value to be squeezed out of them as we figure out how to do that. However, there ar…
Actual memory, in my opinion. Right now memory is broadly speaking like a system of sticky notes the AI writes itself and checks every time, rather than an integrative system that allows learning and can trigger more flexibly.
This is exactly the problem I've been working on and I see others are too. When you implement quality control gates, everything works better. It solves so many of the basic problems llms create - saying code is finished when it isn't. Skipping tests, introducing code regressions, basic code validation etc I am finding that the better the quality gates are the lower quality llm you can use for the same result (at a co…
Earlier quoted context omitted.
But then, if an agent picks the best response, how would you know that that is reliable?
Obviously you have multiple agents justify why they picked a certain response and then create another agent that picks the solution with the best justification.