espadrine

Yes, they employed security terminology for something that was instead data pipeline contamination. As the saying goes, garbage in: garbage out. I don't mean to be harsh on them though: experimentation is useful, and it became a great lesson on red teaming models.

> 4chan basically found an “echo” type debug command or something like that

That is certainly what Microsoft wanted people to think[0]:

> a coordinated attack by a subset of people exploited a vulnerability in Tay.

Realistically, though, Tay’s website was open about using tweets directed at it as part of its training set[1]:

> Data and conversations you provide to Tay are anonymized and may be retained for up to one year to help improve the service.

So all that this group did was tweet racist things at it, and it ended up in its training set. Microsoft hints at it in the earlier blog post:

> AI systems feed off of both positive and negative interactions with people. In that sense, the challenges are just as much social as they are technical.

There are technical solutions for this issue however; for instance, when creating ChatGPT, the OpenAI team designed ChatML[2] to distinguish assistant messages from user messages, so that it would send messages in the style of the assistant only, not in the style of the user. Along with RLHF, it allowed OpenAI to use ChatGPT messages as part of their training set.

[0]: https://blogs.microsoft.com/blog/2016/03/25/learning-tays-in...

[1]: https://web.archive.org/web/20160323194709/https://tay.ai/

[2]: https://github.com/MicrosoftDocs/azure-docs/blob/main/articl...

Here is an authoritative source[0]:

> consent is not required [for] cookies that are strictly necessary to provide an online service that the person explicitly requested. e.g. […] when your customers use a shopping basket

So shopping carts (user clicked to add to cart) and notification preferences (user clicked to indicate preference) don’t require consent. Same for authentication cookies.

The page is quite clear; the confusion likely arises from how companies implement it.

[0]: https://europa.eu/youreurope/business/dealing-with-customers...

A number of AI companies have a naming/reproducibility issue.

GPT4 Turbo, released last November, is a separate version that is much better than GPT-4 (winning 70% of human preferences in blind tests), released in March 2023.

Claude 3 Opus beats release-day GPT-4 (winning 60% of human preferences), but not GPT-4 Turbo.

In the LMSys leaderboard, release-day GPT-4 is labeled gpt-4-0314, and GPT4 Turbo is labeled gpt-4-1106-preview.

Another element is that Mamba required a very custom implementation down to custom fused kernels which I expect would need to be implemented in deepspeed or the equivalent library for a larger training run spanning thousands of GPUs.

It is disallowed by the executive order “on Addressing United States Investments in Certain National Security Technologies and Products in Countries of Concern”: https://www.whitehouse.gov/briefing-room/presidential-action...

The part of MCTS that matters for solving it is the Bellman equation, which is a component of the Bellman-Ford shortest-path algorithm, so all of those methods are part of a continuum.

Which one works best is pretty sensitive to the exploratory decisionmaking algorithm: do I search this cell first, or that one? That heuristic is the differentiator, whether it is put on top of a Dijkstra-style algorithm (A*) or a Bellman-Ford-style algorithm (MCTS).

As a data point, using the Huggingface Transformers 4-bit quantization yields reasonable results: https://twitter.com/espadrine/status/1760355758309298421

Do you have an example text in mind?

You can use this playground to test it out: https://huggingface.co/spaces/Xenova/the-tokenizer-playgroun...

Hard to say definitively. Mistral’s token embeddings only account for <2% of the 7B parameters, while Gemma’s larger token vocabulary vampirized over 10%, leaving less space for the more important parts of the network. It is a somewhat surprising tradeoff given that it was pretrained towards an English bias.

It mostly means that there are tokens dedicated to rarer sequences of characters, even in foreign languages (note that Gemma is not intended to be good multilingually): “説明書” (instruction manual) has its own token, and so does “Nixon”, “آباد” (a city suffix, I believe), and the HTML sequence "\"><!--".

Huh, indeed, that's what the config.json[0] says; the report[1] indicates “Feedforward hidden dims: 49152”.

[0]:https://huggingface.co/google/gemma-7b-it/blob/main/config.j...

[1]: https://storage.googleapis.com/deepmind-media/gemma/gemma-re...

It is already part of the release on Huggingface: https://huggingface.co/google/gemma-7b/blob/main/gemma-7b.gg...

It is a pretty clean release! I had some 500 issues with Kaggle validating my license approval, so you might too, but after a few attempts I could access the model.

I notice a few divergences to common models:

- The feedforward hidden size is 16x the d_model, unlike most models which are typically 4x;

- The vocabulary size is 10x (256K vs. Mistral’s 32K);

- The training token count is tripled (6T vs. Llama2's 2T)

Apart from that, it uses the classic transformer variations: MQA, RoPE, RMSNorm.

How big was the batch size that it could be trained so fast?

https://huggingface.co/mistralai/Mistral-7B-Instruct-v0.2/bl...

There is no question in my mind that the transformer architecture will not stop to evolve. Already now, we are stretching the definition by calling current transformers that way; the 2017 transformer had an encoder block which is nearly always absent nowadays, and the positional encoder and multi-head attention have been substantially modified.

VRAM costs and latency constraints will drive architectural changes, which Mamba hints at: we will have less quadratic scaling in the architectures that transformers evolve into, and likely the attention mechanism will look more and more akin to database retrieval (for way more evolved database querying mechanisms than is often seen in relational databases). One day, the notion of a maximum context size will be archaeological. Breaking the sequentiality of predicting only the next token would also improve throughput which could require changes. I expect experts to also evolve into new forms of sparsity. More easily quantizable architectures may also emerge.

In part, yes! But also because what used to define it was the human-curated datasets: SL contained input/output pairs, while RL contained episodes with sporadic rewards.

Nowadays, many datasets have different forms or are synthetic. DPO uses datasets with both positive and negative examples (instead of just a target output as with traditional SL); RLHF uses synthetic rewards.

DPO is as close to RL as RLHF. The latter also uses the LLM as a reward model.

I'm not a fan of the RL/SL dichotomy, because the line gets so foggy. If you squint, every loss is a negative reward, and every policy improvement a supervised target.

Still, what the code does isn't what is described in the paper that the page links to.

What will each party gain from the contract they signed? The first few sections left me with a lot of questions.

From what I can tell, based on the later sections:

> new experiences for Google Cloud customers to easily train and deploy Hugging Face models within Google Kubernetes Engine (GKE) and Vertex AI

I assume that means a new API field like `huggingface_model: "google/flan-t5-base"`?

> Models will be easily deployed for production on Google Cloud with Inference Endpoints

That seems to mean the GCP button which is currently disabled in the Inference "Create a new endpoint" page (https://ui.endpoints.huggingface.co) will now be enabled, which is the clearest part of the announcement.

It is certainly interesting, and I would love to try it for my hobbyist use-cases. I don’t do much research at work, but a fair bit on the weekends.

Are you filtering users however? I cannot sign up in a personal capacity with a GMail email. The page raises this error: “Please use a valid institutional or company email address.”

Demis Hassabis of Deepmind echoes a similar sentiment[0]:

> I still think there are missing things with the current systems. […] I regard it a bit like the Industrial Revolution where there was all these amazing new ideas about energy and power and so on, but it was fueled by the fact that there were dead dinosaurs, and coal and oil just lying in the ground. Imagine how much harder the Industrial Revolution would have been without that. We would have had to jump to nuclear or solar somehow in one go. [In AI research,] the equivalent of that oil is just the Internet, this massive human-curated artefact. […] And of course, we can draw on that. And there's just a lot more information there, I think, it turns out than any of us can comprehend, really. […] [T]here's still things I think that are missing. I think we're not good at planning. We need to fix factuality. I also think there's room for memory and episodic memory.

[0]: https://cbmm.mit.edu/video/cbmm10-panel-research-intelligenc...

> Mistral's latest just released model is well below GPT-3 out of the box

The early information I see implies it is above. Mind you, that is mostly because GPT-3 was comparatively low: for instance its 5-shot MMLU score was 43.9%, while Llama2 70B 5-shot was 68.9%[0]. Early benchmarks[1] give Mixtral scores above Llama2 70B on MMLU (and other benchmarks), thus transitively, it seems likely to be above GPT-3.

Of course, GPT-3.5 has a 5-shot score of 70, and it is unclear yet whether Mixtral is above or below, and clearly it is below GPT-4’s 86.5. The dust needs to settle, and the official inference code needs to be released, before there is certainty on its exact strength.

(It is also a base model, not a chat finetune; I see a lot of people saying it is worse, simply because they interact with it as if it was a chatbot.)

[0]: https://paperswithcode.com/sota/multi-task-language-understa...

[1]: https://github.com/open-compass/MixtralKit#comparison-with-o...

No. Without the inference code, the best we can have are guesses on its implementation, so the benchmark figures we can get could be quite wrong. It does seem better than Llama2-70B in my tests[0], which rely on the work done by Dmytro Dzhulgakov[1] and DiscoResearch[2].

But the point of releasing on bittorrent is to see the effervescence in hobbyist research and early attempts at MoE quantization, which are already ongoing[3]. They are benefitting from the community.

[0]: https://twitter.com/espadrine/status/1733505332293288256

[1]: https://github.com/dzhulgakov/llama-mistral

[2]: https://huggingface.co/DiscoResearch/mixtral-7b-8expert

[3]: https://github.com/TimDettmers/bitsandbytes/tree/sparse_moe

Once on llama.cpp, it will likely run on CPU with enough RAM, especially given that the GGUF mmap code only seems to use RAM for the parts of the weights that get used.

The latest update I see on that link is from 2023.11.21 on “Expanding Bard’s understanding of YouTube videos.” Is it possible that there are country-specific update pages?

Edit: I found a Google page indicating that Gemini Pro is not accessible in Europe, with no ETA for when it will be released there: https://support.google.com/bard/answer/14294096

Bard shows “PaLM2” in my answers, and it says “I can't create images yet so I'm not able to help you with that” when I ask it to do so, which Gemini ought to be able to since its transformer can output images.

I don’t think Bard is using Gemini Pro, perhaps because the rollout will be slow, but it is a bit of a blunder on Google’s part to indicate that it now uses it, since many will believe that this is the quality that Gemini assumes.

I understand the feeling. It may be caused by habit rather than objectivity, though. Those open-source AI hacks are undergoing early productization: while they were only research, their modularity mattered for experimentization, but as they get closer to something that can ship, the one-click binary form factor is a nice stepping stone.

It is similar in my mind to the early days of Linux, where you had to compile it yourself and tweaked some compiler flags, compared to now, where most people don’t even think about the fact that their phone or Steam deck runs it.

If you have the key to a ciphertext, you can decrypt it, but that doesn't make the cipher insecure. It is the same principle for the seed of a CSPRNG. In fact, a common cipher construction (ChaCha20, for instance) relies on a random stream seeded by the key, generated by the sender to encrypt data, which the recipient re-generates from that same key to decrypt the data.

There are ways to make much faster PRNGs; I designed one that reaches 53 GB/s[0] (0.06 cycles per byte) with better quality than those listed in the article.

But I agree with tczajka: good engineering practice ought to be to start with a CSPRNG. First make it work, then make it fast. With truly random data, you know your algorithm works, and can then check if there is a quality loss when switching away. The performance of CSPRNG is so optimized that it is seldom the bottleneck anyway.

[0]: https://github.com/espadrine/shishua#comparison

They're not, but I am more interested in their ability to follow instructions, and here Yi did the opposite of what was requested.

A non-code example: “Can you take this list of groceries and order it alphabetically? (Salad, cherries, garlic, cheese, milk.)”

Yi:

  - Cherries
  - Garlic
  - Milk
  - Salad
  - Cheese

Zephyr:

  cheese, cherries, garlic, milk, salad

The fine-tuning is nice! It is only SFT, though, which may have limited its improvements. I tested it against the Zephyr 7B model (which used DPO) on a sample question:

  How can I code p*log(p) in Julia in a way that doesn't return NaN for any probability value?

Yi gave:

  function safe_p_log(p::Float64)
      if p > 0.999 && p < 1.001 # or use a more precise threshold if needed
          return 1 - (1 / p)
      elseif p > 0.001 && p < 0.01  # or use a more precise threshold if needed
          return log(p * 1e8)  # or use another small number instead of 1e-8
      end
      return p * log(p)
  end

It warned that it would not work for p = 0 or 1. After saying that probabilities can be 0 or 1, it added a `if p == 0.0 || p == 1.0; return NaN` at the start.

Zephyr answered:

  function p_log_p(p::AbstractFloat) :: AbstractFloat
      return (p <= 0.0) ? 0.0 : p * log(p)
  end

Sometimes it returns an error or minus infinity (I also got `p * log(max(min(p, 1.0), 1e-10))`, which is cute), but it does follow the request.