@mkhoury - eviltoast
  • 5 Posts
  • 38 Comments
Joined 2 years ago
cake
Cake day: March 4th, 2023

help-circle

  • I agree that with the current state of tools around LLMs, this is very unadvisable. But I think we can develop the right ones.

    • We can have tools that can generate the context/info submitters need to understand what has been done, explain the choices they are making, discuss edge cases and so on. This includes taking screenshots as the submitter is using the app, testing period (require X amount of time of the submitter actually using their feature and smoothening out the experience)

    • We can have tools at the repo level that can scan and analyze the effect. It can also isolate the different submitted features in order to allow others to toggle them or modify them if they’re not to their liking. Similarly, you can have lots of LLMs impersonate typical users and try the modifications to make sure they work. Putting humans in the loop at different appropriate times.

    People are submitting LLM generated code they don’t understand right now. How do we protect repos? How do we welcome these contributions while lowering risk? I think with the right engineering effort, this can be done.









  • It was just an example. The same can happen at the Mastodon-level instead of the Fediverse-level. Since there is some desired interop (e.g. between Mastodon and Lemmy), services do influence each other in their feature set.

    I’m not sure what you mean by “a lot of what people are worried about Threads doing has already been done by Mastodon”. Do you mean that the decisions that Mastodon make influence the rest of the Fediverse? If so, let’s make sure we understand the difference here: Threads has a much more hostile disposition. Mastodon seems to have incentives aligned with the rest of the Fediverse services, and probably deserves the benefit of the doubt; Facebook has abused that benefit time and time again.


  • This is more a question of tolerance. We know Facebook is NOT tolerant of competitors, of the open web, of free software, etc. They cannot survive as a megacorp without a level of assurance and control that they can’t have if they’re “just another fediserver”. They WILL try to wrangle control. They WILL try to eat us all up. Why let the fox in the henhouse when you already know it’s a fox?


  • That doesn’t actually fix the issue. If Facebook is trying to set itself up like Chrome with the webplatform, or GTalk with XMPP, then they will drive the feature set of ActivityPub, whether you’re federated with them or not.

    Hypothetical example:

    Want to see this picture/video from someone on Threads? You need Facebook’s proprietary picture format, which has DRM baked in it. Even if you don’t federate, Mastodon, Lemmy, etc now have to take energy away from their work to adopt the proprietary picture format. It depends on the proportion Threads takes on the network and how they can leverage that position to put pressure.

    Threads currently has voice notes. Should all ActivityPub services support that? If so, do we adhere to Threads’ standard or not?








  • Essentially, you don’t ask them to use their internal knowledge. In fact, you explicitly ask them not to. The technique is generally referred to as Retrieval Augmented Generation. You take the context/user input and you retrieve relevant information from the net/your DB/vector DB/whatever, and you give it to an LLM with how to transform this information (summarize, answer a question, etc).

    So you try as much as you can to “ground” the LLM with knowledge that you trust, and to only use this information to perform the task.

    So you get a system that can do a really good job at transforming the data you have into the right shape for the task(s) you need to perform, without requiring your LLM to act as a source of information, only a great data massager.