Writing is fundamentally the transfer of information from your brain to my brain. If you have 1000 bits of semantic information you want to transfer, you can't give 300 bits of semantic information to an LLM and have it fill in the remaining 700, because it doesn't know what those 700 bits are. If it's able to guess those 700 bits correctly, then they aren't true semantic information, and you really only have 300 bits you want to transfer. You might as well transfer those bits to me directly, rather than having the LLM add on an extra superfluous 700 bits that I then have to filter out.
I will give you a use case where this is absolutely not the case.
I have a bunch of CLI utils I run for various clients and their peculiar setups. They now have man pages with descriptions and examples in them because the LLM went and read my code and did the needful.
I no longer have to re read my own code, rather I can just use the manual page.
Format and description came from semantics and context that (barely) existed elsewhere and I was not going to retain or transmit, but I have now.
I never liked information theory because information theory as Shannon envisioned it fundamentally did not deal with semantics.
AIT tried solving it? But AFAIK it's a lot of pretty results with not much real application.
A better approximation is something of a "shared model"; then you can actually state things like, the transfer of information sometimes is "trivial" because, well, it's right there in your compressor/decompressor.
My understanding is that to unambiguously quantify information, you need to have a known model within which that information fits. In this context, talking about LLMs adding value (or not) via inserting new semantic information, we're assuming that public knowledge on the internet is not new semantic information, and the quantity of information of contained in text talking about public knowledge is equal to the ~32 bits needed to point to that knowledge.
I was just trying to understand this about a month ago and it is interesting how little there is in terms of semantic information vs Shannon.
An Outline of a Theory of Semantic Information by Carnap was the early attempt.
Fred Dretske wrote Knowledge and the Flow of Information in 1981.
Luciano Floridi has a few recent books.
I couldn't find much else. I don't think AIC really solves the problem of meaning either.
I think the Dretske book was the first time I really understood where Shannon was coming from but I gave up when it got to his actual semantic ideas.
I think I ran across a recent paper that motivated trying to back track what work had been done in this area but I don't recall the name of the paper.
I've have shelved all this for now as over my head.
But then the LLMs aren't adding new information, they're just reading your code and translating that information from e.g. python to english. Rather than sending someone an LLM-generated doc to someone, send the code and your own personal thoughts on the code. If your reader doesn't want to read and understand your code, they can ask an LLM to analyze it, within the context of their specific use case and your personal thoughts if any.
You're making a big assumption that the code is what is being executed, and not a compiled binary.
Where is the code: My repo? the clients? If it's in mine, the client does not have access and the CLI is a first stop to debugging. They arent in the context of written docs, more likely a production error from a log (thats now spitting out a message to check the CLI).
Less steps, less tools, more context in line and available in an interface your already using.
> they can ask an LLM to analyze it, within the context of their specific use case and your personal thoughts if any.
Or I can skim the man page it generated and make sure it looks good. The "work" (the tokens) dont have get spent over and over again.
hatthew · · focus · HN ↗
Writing is fundamentally the transfer of information from your brain to my brain. If you have 1000 bits of semantic information you want to transfer, you can't give 300 bits of semantic information to an LLM and have it fill in the remaining 700, because it doesn't know what those 700 bits are. If it's able to guess those 700 bits correctly, then they aren't true semantic information, and you really only have 300 bits you want to transfer. You might as well transfer those bits to me directly, rather than having the LLM add on an extra superfluous 700 bits that I then have to filter out.
zer00eyz · · focus · HN ↗
I have a bunch of CLI utils I run for various clients and their peculiar setups. They now have man pages with descriptions and examples in them because the LLM went and read my code and did the needful.
I no longer have to re read my own code, rather I can just use the manual page.
Format and description came from semantics and context that (barely) existed elsewhere and I was not going to retain or transmit, but I have now.
sigbottle · · focus · HN ↗
AIT tried solving it? But AFAIK it's a lot of pretty results with not much real application.
A better approximation is something of a "shared model"; then you can actually state things like, the transfer of information sometimes is "trivial" because, well, it's right there in your compressor/decompressor.
hatthew · · focus · HN ↗
Exercita · · focus · HN ↗
An Outline of a Theory of Semantic Information by Carnap was the early attempt.
Fred Dretske wrote Knowledge and the Flow of Information in 1981.
Luciano Floridi has a few recent books.
I couldn't find much else. I don't think AIC really solves the problem of meaning either.
I think the Dretske book was the first time I really understood where Shannon was coming from but I gave up when it got to his actual semantic ideas.
I think I ran across a recent paper that motivated trying to back track what work had been done in this area but I don't recall the name of the paper.
I've have shelved all this for now as over my head.
hatthew · · focus · HN ↗
zer00eyz · · focus · HN ↗
You're making a big assumption that the code is what is being executed, and not a compiled binary.
Where is the code: My repo? the clients? If it's in mine, the client does not have access and the CLI is a first stop to debugging. They arent in the context of written docs, more likely a production error from a log (thats now spitting out a message to check the CLI).
Less steps, less tools, more context in line and available in an interface your already using.
> they can ask an LLM to analyze it, within the context of their specific use case and your personal thoughts if any.
Or I can skim the man page it generated and make sure it looks good. The "work" (the tokens) dont have get spent over and over again.