I was daydreaming of a special LLM setup wherein each token of the vocabulary appears twice. Half the token IDs are reserved for trusted, indisputable sentences (coloured red in the UI), and the other half of the IDs are untrusted.
Effectively system instructions and server-side prompts are red, whereas user input is normal text.
It would have to be trained from scratch on a meticulous corpus which never crosses the line. I wonder if the resulting model would be easier to guide and less susceptible to prompt injection.
Even if you don't fully retrain, you could get what's likely a pretty good safety improvement. Honestly, I'm a bit surprised the main AI labs aren't doing this
You could just include an extra single bit with each token that represents trusted or untrusted. Add an extra RL pass to enforce it.
Yeah my point was that without everyday challenges they lose meaning.
How does one create art without understanding struggle? How can someone find love without knowing how to keep it alive?
People need to make mistakes and then reflect deeply on them. We need to integrate our experiences with our beliefs and values in order to find meaningful expression.
I think the only exception to all of this might be abstract puzzles.
The fan increases air speed at the centre of the rotor, creating a low pressure zone which then sucks in surrounding air. So it helps to place the fan away from the window (roughly far enough that the wind cone "fits" the opening).
I would have loved to see that video 2 months ago. Thanks for sharing.
I tried to put the same kind of desk fan at the window, one way and then the other, for a few hours, to see if it had any effect. It was a very hot day but colder outside than inside. The building's concrete was likely still radiating the heat from the day before and there was no wind.
I see now that my observation at the time was right: it did nothing to the temperature, and it might have worked better if I had put the fan 1-2 meters away from the window, directing it towards the window. Now, whether the effect would have been significant anyway… we'll have to wait for next summer to know, I guess. I'm not particularly looking forward to it, though.
A 20 or 24" box fan still moves a LOT of air- you should get a decent breeze if you guide the air. the largest mistake I see is forgetting that a fan can't blow if theres no air coming or going- you need openings of equal size (larger is better) between where the fan is and where you want the air to come from/go.
An easy mental model is imaging the air is water. Close a door on a room and it'll fill up and block the hose.
PS: a box fan and a 5" thick MERV13 filter makes a heck of an air filter. 2" likely also will work. MERV13 is great, but some HVAC can't handle it, and it takes a couple passes (term is air exchanges per hour, I think) to capture what HEPA does in a single pass.
Not sure then. Maybe concrete really is too hot. Where I am adobe (clay, not company) buildings have traditionally been used in some areas to even out temperatures (desert region. Too hot in the day, too cold at night).
Huh? We've had pretty good translation in some languages in many general purpose contexts for a while. The LLM stuff if you're referring to that to my knowledge only has some gains in some languages in some contexts. Which is exciting no doubt.
Compared to google translate of yore, it’s gotten way more fluent thanks to transformers. Good translation relies heavily on context of course. Voice recognition and text to speech quality have increased dramatically. And near real-time (or as real-time as is possible given a pair of languages) is becoming feasible.
Meanwhile Switzerland is implementing e-ID which gives citizens private and public keys so they can sign and prove things without leaking their whole identity.
The USPS, with their existing delivery infrastructure and massive presence, would be a great fit for doing this in the US. Think like DoD CAC cards, but for ordinary citizens.
Sometimes a problem is a weird combination of hairy/obscure/tedious where I simply don’t have the activation energy to get started. Like, I could do it with a gun to my head.
But if someone else were to do it for me I would gratefully review the merge request.
Reviewing a merge request should require at least the same activation energy as writing the solution yourself, as in order to adequately evaluate a solution you first need to acquire a reference point in mind as to what the right solution should be in the first place.
For me personally, the activation energy is higher when reviewing: it’s fun to come up with the solution that ends up being used, not so fun to come up with a solution that just serves as a reference point for evaluation and then gets immediately thrown away. Plus, I know in advance that a lot of cycles will be wasted on trying to understand how someone else’s vision maps onto my solution, especially when that vision is muddy.
The submitter should also have thoroughly reviewed their own MR/PR. Even before LLMs, coders not having reviewed their own code would be completely discourteous and disrespectful to the reviewer. It's an embarrassing faux pas that makes the submitter and the team all look and feel bad when there are obvious problems that need to be called out and fixed.
Submitting LLM barf for review and not reviewing it should be grounds for termination. The only way I can envision LLM barf being sustainable, or plausible, is if you removed code review altogether.
Writing/reading code and reviewing code are distinct and separate activities. It's completely common to contribute code which is not production ready.
If you need an example, it's easy to add a debugging/logging statement like `console.log`, but if the coder committed and submitted the log statement, then they clearly didn't review the code at all, and there are probably much bigger code issues at stake. This is a problem even without LLMs.
Just call it “committing bad code”. LLM autocomplete aside, I don’t see how reviewing own code can happen without either a split personality, or putting enough time that you completely forgot what exactly you were doing and have fresh eyes and mind.
If person A committed code that looks bad to person B, it just means person A commits bad code by the standard of person B, not that person A “does not review own code”.
Maybe it’s a subjective difference, same as you could call someone “rude” or you could say the same person “didn’t think before saying”.
Person A as can commit atrocious code all day, that's fine, but they still need to proofread their MR/PR and fix the outstanding issues. The only way to see outstanding issues is by reviewing the MR/PR. Good writers proofread their documents.
My preferred workflow requires me to go through every changed chunk and stage them one by one. It’s very easy with vim-fugitive. To keep commits focused, it requires reading every chunk, which I guess is an implicit review of sorts.
Effectively system instructions and server-side prompts are red, whereas user input is normal text.
It would have to be trained from scratch on a meticulous corpus which never crosses the line. I wonder if the resulting model would be easier to guide and less susceptible to prompt injection.
reply