This account is being kept for the posterity, but it won’t see further activity past February.

If you want to contact me, I’m at /u/lvxferre@mander.xyz

  • 1 Post
  • 177 Comments
Joined 4 years ago
cake
Cake day: April 9th, 2021

help-circle






  • The source that I’ve linked mentions semantic embedding; so does further literature on the internet. However, the operations are still being performed with the vectors resulting from the tokens themselves, with said embedding playing a secondary role.

    This is evident for example through excerpts like

    The token embeddings map a token ID to a fixed-size vector with some semantic meaning of the tokens. These brings some interesting properties: similar tokens will have a similar embedding (in other words, calculating the cosine similarity between two embeddings will give us a good idea of how similar the tokens are).

    Emphasis mine. A similar conclusion (that the LLM is still handling the tokens, not their meaning) can be reached by analysing the hallucinations that your typical LLM bot outputs, and asking why that hallu is there.

    What I’m proposing is deeper than that. It’s to use the input tokens (i.e. morphemes) only to retrieve the sememes (units of meaning; further info here) that they’re conveying, then discard the tokens themselves, and perform the operations solely on the sememes. Then for the output you translate the sememes obtained by the transformer into morphemes=tokens again.

    I believe that this would have two big benefits:

    1. The amount of data necessary to “train” the LLM will decrease. Perhaps by orders of magnitude.
    2. A major type of hallucination will go away: self-contradiction (for example: states that A exists, then that A doesn’t exist).

    And it might be an additional layer, but the whole approach is considerably simpler than what’s being done currently - pretending that the tokens themselves have some intrinsic value, then playing whack-a-mole with situations where the token and the contextually assigned value (by the human using the LLM) differ.

    [This could even go deeper, handling a pragmatic layer beyond the tokens/morphemes and the units of meaning/sememes. It would be closer to what @njordomir@lemmy.world understood from my other comment, as it would then deal with the intent of the utterance.]


  • Not quite. I’m focusing on chatbots like Bard, ChatGPT and the likes, and their technology (LLM, or large language model).

    At the core those LLMs work like this: they pick words, split them into “tokens”, and then perform a few operations on those tokens, across multiple layers. But at the end of the day they still work with the words themselves, not with the meaning being encoded by those words.

    What I want is an LLM that assigns multiple meanings for those words, and performs the operations above on the meaning itself. In other words the LLM would actually understand you, not just chain words.


  • Complexity does not mean sophistication when it comes to AI and never has and to treat it as such is just a forceful way to make your ideas come true without putting in the real effort.

    It’s a bit off-topic, but what I really want is a language model that assigns semantic values to the tokens, and handles those values instead of directly working with the tokens themselves. That would be probably far less complex than current state-of-art LLMs, but way more sophisticated, and require far less data for “training”.









  • It’s less complicated than it looks like. The text is just a poorly written mess, full of options (Fedora vs. Ubuntu, repo vs. no repo, stable vs. beta), and they’re explaining how to do this through the terminal alone because the interface that you have might be different from what they expect. And because copy-pasting commands is faster.

    Can’t I just download a file and install it? I’m on Ubuntu.

    Yes, you can! In fact, the instructions include this option; it’s under “Installing the app without the Mullvad repository”. It’s a bad idea though; then you don’t get automatic updates.

    A better way to do this is to tell your system “I want software from this repository”, so each time that they make a new version of the program, yours get updated.

    but I have no idea what I’m doing here.

    I’ll copy-paste their commands to do so, and explain what each does.

    sudo curl -fsSLo /usr/share/keyrings/mullvad-keyring.asc https://repository.mullvad.net/deb/mullvad-keyring.asc
    echo "deb [signed-by=/usr/share/keyrings/mullvad-keyring.asc arch=$( dpkg --print-architecture )] https://repository.mullvad.net/deb/stable $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/mullvad.list
    sudo apt update
    sudo apt install mullvad-vpn
    

    The first command boils down to “download this keyring from the internet”. The keyring is a necessary file to know if you’re actually getting your software from Mullvad instead of PoopySoxHaxxor69. If you wanted, you could do it manually, and then move to the /usr/share/keyrings directory, but… it’s more work, come on.

    The second command tells your system that you want software from repository.mullvad.net. I don’t use Ubuntu but there’s probably some GUI to do it for you.

    The third command boils down to “hey, Ubuntu, update the list of packages for me”.

    The fourth one installs the software.



  • They’re still providing the code for people who buy the compiled software. And they are not restricting their ability to redistribute that code. So it’s still compliant with the GPL in the letter. However, if you redistribute it, they’ll refuse to service you further versions of the software.

    It’s clearly a loophole because they can argue “ackshyually, we didn’t restrict you, we just don’t want further businesses with you, see ya sucker”.


  • Lvxferre@lemmy.mltoOpen Source@lemmy.mlThoughts on Post-Open Source?
    link
    fedilink
    arrow-up
    21
    arrow-down
    1
    ·
    11 months ago

    I think that the RHEL example is out-of-place, since IBM (“Red Hat”) is clearly exploiting a loophole of the GNU Public License. Similar loopholes have been later addressed by e.g. the AGPL and the GPLv3*, so I expect this one to be addressed too.

    So perhaps, if the GPL is “not enough”, the solution might be more GPL.

    *note that the license used by the kernel is GPLv2. Cue to Android (for all intents and purposes non-free software) using the kernel, but not the rest.