crustycoder

há 2 mesesdiscuss

Yes, exactly. The issue detection step isn't particularly well-suited to a LLM, as it will tell you itself. The issues can be established deterministically by examining the Cloud resource data with a set of relatively simple rules, and Prolog is ideal for that. Where a LLM comes into the picture is analysis of the symptoms - resource relationships, ages, ownership, hypothesising root causes, generating cleanup plans, management reporting and so on. The interface between Prolog and the LLM is a JSON file containing the detected symptoms which is described to the LLM by a Skill. It all works pretty well.

crustycoder

há 2 mesesdiscuss

It's not that sophisticated ;-) There's command editing using readline, result pagination using less and I output links to the reports and the Cloud console using ANSI HTTP link escapes. Primitive but sufficient.

crustycoder

há 2 mesesdiscuss

I think in many real-life cases it's a mix - for example impure code that deals with the outside world to set up the data needed for the pure "core" of the app to run over.

crustycoder

há 2 mesesdiscuss

You could always read the docs?

https://www.swi-prolog.org/pldoc/man?section=clpfd-integer-a...

https://www.swi-prolog.org/pldoc/doc_for?object=!/0

crustycoder

há 2 mesesdiscuss

I've just rolled out an internal SWI Prolog app that is similar to one linked to elsewhere in the thread [1]. We have a large Cloud estate with 10s of thousands of resources in it. Detecting unused or misconfigured resources manually isn't practical, and there are significant cost savings to be had by cleaning things up. The Prolog app reads in JSON resource snapshots, creates an in-memory database of facts from it and then applies rules to detect issues. Most of the rules are simple and the ones for detecting unused resources (3 LOC) or resources that reference other non-existent resources (7 LOC) are entirely generic. There's also link metadata that models the possibility of links existing between resource types, even if they aren't always there in practice.

There's TUI that allows querying of issues and the resource hierarchy. Issues can also be output as JSON which is fed into a LLM to produce cleanup actions and management reporting.

The Prolog app is very fast, considering what it's doing, largely because it makes heavy use of tabling so once an issue has been detected it's not recomputed when queries are made.

[1] https://web.archive.org/web/20190525163234/https://dev.to/da...

crustycoder

há 2 mesesdiscuss

I get what he's saying but I think it's overstated. I'd categorise his list as "Things to be careful with" not "Coding horrors". For example, "The primary means to make your programs defective in this way is to use predicates like assertz/1 and retract/1" is an unqualified statement that makes it sound like you should never ever use them, and that's not the case. I have a real-life Prolog app that applies rules to facts read from JSON data files. I could do that two ways:

1) Read the JSON with Prolog (there's a library) and assertz() the facts from that, building an immutable database in the first phase before applying the rules in the second phase.

2) Externally transform the JSON into Prolog facts, load that into the app on startup and apply the same rules to it.

I agree that mutating the database in the second phase is probably a bad idea, but that's not the same as saying "assertz() always bad". I'd read his site before it appeared on HN and whilst there a lot of very good stuff on it, some of it reminds me of FP purist edicts - fine if you want to go that way and it's appropriate to your problem, but that isn't always going to be the case. That was the basis of my earlier (downvoted) "Mostly overblown" comment.

But nice to see Prolog mentioned at all on HN :-)

crustycoder

há 2 mesesdiscuss

Mostly overblown.

crustycoder

há 3 mesesdiscuss

Name me a new bit of tech that hasn't been hyped beyond reasonable bounds. And yes, this is one of the worst examples. But saying it doesn't have its uses isn't reasonable either.

crustycoder

há 3 mesesdiscuss

Go figure it out, it will be a useful challenge for you.

crustycoder

há 3 mesesdiscuss

I'd tell you to read it again, but you seem to be struggling.

crustycoder

há 3 mesesdiscuss

I'm not going to repeat myself, I've already explained the context to you - funny how you seem to have ignored that. If you want to find out, do the experiment yourself.

crustycoder

há 3 mesesdiscuss

You clearly missed the "The truth is somewhere in between" bit.

crustycoder

há 3 mesesdiscuss

Picking phrases from what I said and deliberately misquoting them out of context does not make you right.

crustycoder

há 3 mesesdiscuss

"exactly this inspection" != "what does it exactly do"

crustycoder

há 3 mesesdiscuss

Nicely put. I haven't seen anyone say that the introspection abilities of LLMs are up to much, but claiming that it's completely impossible to get a glimpse behind the curtain is untrue.

crustycoder

há 3 mesesdiscuss

Yes of course there's a risk it may still be incorrect but querying the LLM with the limited facilities it provides for introspection is more likely to have at least some connection with facts than the alternative that some people use, which is to simply guess as to why it produced the output it did.

If you have an alternative approach, please share.

crustycoder

há 3 mesesdiscuss

I don't owe you anything. If you want to go find out, go do it yourself.

You could even ask a LLM to help you if you,like...

crustycoder

há 3 mesesdiscuss

People have applied "think" to the actions of software for decades. Of course it LLM's don't "think" in the human sense, but "What the output of the model indicates in an approximate way about its current internal state" is a bit long winded...

crustycoder

há 3 mesesdiscuss

"Not in the slightest" is an overreach, the paper the second level down from that link doesn't really support the conclusion in the blog post - the paper is much more nuanced.

Are they going to fib to you sometimes? Yes of course, but that doesn't mean there's no value in behavioural metaqueries.

Like most new tech, the discussion tends to polarise into "Best thing evah!" and "Utter shite!" The truth is somewhere in between.

crustycoder

há 3 mesesdiscuss

> It would be interesting to see one of these evals and how it generated the score, to work out whether it is in fact arbitrary or based on some scale of points.

So go repeat the exercise yourself. I've already said this was a short-enough-to-post rollup of a much longer LLM assessment of the skills and that while most of the points were fair, some were questionable. If you were doing this "for real" you'd need to assess the full response point-by-point and decide which ones were valid.

> If you really believe this you should perhaps re-evaluate the trust you appear to place in the conclusions of LLMs, particularly about their own workings and what makes a good skill or prompt for them.

What on earth are you on about? The whole point of of the sentence you were replying to was that you can't blindly trust what comes out of them.

comments