Negative income tax is an alternative to UBI, but it's discussed less often. Does anyone know why? I feel it should be easier to implement (plugs right into the existing tax system), should be cheaper (the more you earn, the less you get), and feels more in line with the progressive tax system, whereas UBI feels like an extremely coarse first approximation.
Essentially, the tax curve starts at 0 and goes up. Why not shift it down? There's nothing special about 0.
Ironic. Every time a company measures its employee output with number of lines of code or commits, devs are the first to point out that management is dumb for using a surface-level metric. But you're doing the same thing here, except with execs and powerpoint.
Powerpoints are just the final output you see. The real work execs do is in the decisions that went into the powerpoint.
No sane board will give decision-making power to an AI they can't blame. Besides, there are probably 100 devs for every exec, so it makes no financial sense to automate execs.
What's stopping someone from placing the silicon under ab electron microscope and reading the data visually? I mean, the circuit that encrypts data has to have some way to load the key (the circuit might not be in the CPU, but it exists somewhere).
That's concerning. Could you elaborate on how you identified the traffic as cloudflare workers? Also, what sorts of HTTP attacks? wp-admin probes? Plain DDoS?
Cloudflare has (had?) a murky history with not taking down DDoS for hire services ironically hosted behind cloudflare. But while you could argue they had an incentive to do that (sell protection), I can't think of any incentive to let Workers be abused.
While OP's reply answers your question, it's important to not apply current costs to predict the future of AI. Hardware for LLMs is one step function away from unimaginable capabilities. That breakthrough could be in performance, cost, or more likely, both.
Imagine GPT-4 at 1/1000th the cost. That's where we're going. And you can bet your ass Nvidia is working on it as we speak. Or maybe someone else will leapfrog them like ARM did to Intel.
Why is everyone so confused about this? Isn't verifying the easy part? You put it into the GPT-3.5/4 API as a system prompt and see it answers like the actual chatbot. If it does, you've either extracted the actual prompt (congrats!) or something else that works just as well (congrats!). If it doesn't, it's a hallucination. If you're worried about temperature setting throwing you off, keep trying new questions until you find one that the original chatbot gives the same answer consistently.
It's far easier to do productive, useful things with AI if you just treat it as a tool, like a chainsaw or a pulley.
Everyone agrees there's a lot of hype right now but no one thinks _they're_ a part of it. You know why? It's because we're told we're on an exponential growth (we are), so everyone is trying to force it. So each time there's a breakthrough, we're desperate for it to be rocketship that takes us there.
It's time to step back and let the exponential thing happen on its own. We didn't get here because people in the 20th century sat down and plotted a way to achieve exponential growth; it just sorta happened.
I didn't bother cleaning it so it's just a code dump, but it's fairly straightforward. Not included are a Python script to parse and clean the raw documents into JSON files (used in `summarize` to output results), code to read these files and get the embeddings from OpenAI for use in `newEmbeddingJSON `, and a bunch of random parallelization shell scripts that I didn't save.
To use it, I call newDBFromJSON from a directory of JSON embedding vectors and serialize the binary representation. This takes a few minutes mostly because parsing JSON is slow, but you I only needed to do this once. When I need to search for the top 10 documents most similar to document X, I call `search` with the embedding vector for that doc. Alternatively if I need to do semantic search with natural language, I'll call the OpenAI API to get the embedding vector for the query and call `search` with that vector. It's pretty fast thanks to Go concurrency maxing out my CPU. It's super accurate with the search results thanks to OpenAI's embeddings.
It's nowhere close to production-ready (it's littered with panics), but it was good enough for me.
Hope this helps!
Edit: oh and don't use float64 (OpenAI's vectors are float16)
>Erlich: You say that like it's a bad thing. Richard, if you're not an asshole, it creates this kind of asshole vacuum and that void is filled by other assholes, like Jared.
(Note: I don't necessarily entirely agree with all of it.)
Unless you have several hundred million documents, just write a simple encoder that serializes the embedding vectors to a flat binary file.
Writing code from scratch to process and search 200k unstructured documents -- parsing, cleaning, chunking, OpenAI embedding API, serialization code, linear search with cosine similarity, and the actual time to debug, test and run all this -- took me less than 3 hours in Go. The flat binary representation of all vectors is under 500 MB. I even went ahead and made it mmap-friendly for the fun of it even though I could read it into all into memory.
Even the dumb linear search I wrote takes just 20-30ms per query on my Macbook for the 200k documents. The search results are fantastic.
You could apply the same logic to anyone ringing the alarm bells about climate change (or alarm bells in general). Just because snake oil is usually unfalsifiable doesn't mean everything _currently_ unfalsified is snake oil.
Essentially, the tax curve starts at 0 and goes up. Why not shift it down? There's nothing special about 0.