That's a great question - right now it is only looking at the results from a battery of several dozen indicators that we compute upstream of the model itself (which saves massively on tokens)
As small models continue to improve, and edge hardware becomes more capable, we would really like to run larger models that could incorporate full page content and screengrab data, which would be more likely to catch these kinds of attacks.
But we also find that sites that do one shady thing usually do others, which is a big reason why a tiny model like this can work - and why we are betting on low latency being a differentiating factor in real-world impacts.
CLAVIER is amazing, the wire system alone is such a huge improvement over ORCA, and it's now feasible to make much larger patches and refactor safely, kudos to River for all the hard work on the polish and quality-of-life.
Love 100r! There aren't a ton of examples online, but their livecoding music software/language, ORCA, is a remarkable instrument.
https://100r.co/site/orca.html
I work with data warehouses, but I'm really jealous of the way our Finance team uses some abysmal plugin to directly query our GL from inside Excel - building something like that the can make the contents of a modern data warehouse available to Excel users has always been a holy grail for me.
My hunch is that exposing free-form SQL in Excel doesn't work, but something more like structured metrics (something roughly like dbt metrics) could potentially work? And tooling like this is probably what I'd want to prototype with.
Airbnb wrote a few great blog posts about why they built a standardized metrics layer - I think this one gives better technical context on the "what" and "why" than this announcement does:
In practice - complicated time series metrics, especially on top of derived temporal-logic attributes like funnels, activation, etc., are phenomenally difficult to write by hand in SQL for most analysts. We are in the process of switching to dbt metrics and it cuts the effort down for this kind of thing 5x-10x, and the SQL code dbt generates runs signficantly faster too.
One of Transform's strong suits is their Tableau integration - they have really good tooling for pushing metrics out to Tableau, rather than relying on Tableau to pull them in. Apparently AirBnb was/is still a very dedicated Tableau shop.
The biggest win to me is: when your data pipelines are in SQL, changes and maintenance can be somebody else's problem.
I've had a ton of success asking our marketing and business teams to own changes and updates to their data - very often they know the data far better than any engineer would, and likewise they actually prefer to own the business logic and to be able to change it faster than engineering cycles would otherwise allow.
But in general - as an industry, we aren't there yet. All judgments about Meta's practices aside - no large organization likely has the ability to comply with a law like this without years or decades of engineering work, and the law seems pretty clearly intended for selective enforcement.
One change I have seen in recent years is that I find fewer and fewer new engineers learn SQL, especially folks entering the industry from bootcamps. And conversely, more and more folks from a business/econ/etc background learn at least a little bit along with excel.
I've been thinking about this a ton lately -
I think the holy grail is something that extends the spreadsheet UX with the capability to address much larger data sets, roughly equivalent in power to a Jupyter notebook.
This probably means constraining some of the totally free-form data entry and imposing some kind of discipline onto columns? As well as some way to intuitively group together groups of cell-level formulas into a logical "row", and describe row-level operations, with some kind of rough type checking or duck typing?
But you might want to still retain an ability to lay out the result of computations free-form for invoice and other reporting uses that Excel is still great for?
Better graphical visualization would be nice too and I think that's actually in reach - there are great open source options like vegalite and apache echarts that open up a lot of possibilities for new tools.
Algol 60 had lexical scoping in 1960 (while Lisp was in development) and this was known to be equivalent to the lambda calculus by the folks working on it by 1965 or so -
https://dl.acm.org/doi/10.1145/363744.363749
I think the consensus is that Scheme was the first Lisp to fully embrace lexical scope, in 1975?
Always an interesting read. A ton of insights, but I always find it a bit hard to make sense of, and it feels so disconnected from a modern distributed systems context.
In retrospect, I think a lot of the Spark SQL Dataframe workflow comes pretty close to what D/Tutorial D aspire to - static typing, functions on relations, imperative style but fundamentally unordered, etc.; however, it's only a processing system, not a storage system.
I have kept my distance from the "data lake" buzzword circles, but maybe a transactional, Spark-based data lake does approximate what Darwen/Date are going for? The only thing really missing might be nested relations?
I think I shared this last time Sonic Pi got posted here, but Sonic Pi is also extremely flexible when you bus the MIDI output to other tools - Ableton, external synthesizers, etc. I posted a clip on IG a while back -
I have a question the planned Alpha 7 feature: "smaller than 32-bit values (char/byte)" - I'm so used to bytes being a fundamental primitive in programming languages that it's hard for me to imagine not immediately having access to them.
Can you explain a bit why this is non-trivial, and what the implementation is going to look like?
This is really exciting! I've been building a data engineering practice around jupyter notebooks, Netflix's papermill, and k8s cronjobs for scheduling, and it's been great...except for code review, weird dependency/virtualenv glitches, tests, and documentation.
At first glance, this seems like it would address all of my pain points? Will be interesting to try it out.
Coming to Factorio from a Scala/streaming/data background, I got the connection pretty immediately - so much of Factorio is about designing correctly for backpressure, such that your factory works stably at different levels of capacity and resource consumption. That said, I still never really got the knack of blueprints and large-scale planning, so I've got a long way to go still.
As small models continue to improve, and edge hardware becomes more capable, we would really like to run larger models that could incorporate full page content and screengrab data, which would be more likely to catch these kinds of attacks.
But we also find that sites that do one shady thing usually do others, which is a big reason why a tiny model like this can work - and why we are betting on low latency being a differentiating factor in real-world impacts.