Absolutely one of the most impressive paint "filters" I've seen.
How long is the frame time on the GPU implementation? Is there any hope for something like this to run at 60fps as a post process for a game? Can the data from a 3D scene be used to skip some of the initial analysis steps?
I may be naive here but can the hidden text not be flagged or outright removed before being passed to copilot? Why would there not be consideration for what a human user can see, especially if the hidden text was added by copilot in the first place?
There are many ways to hide text. Low contrast, small font size, image covering part of the text, too-small box cutting off some parts, custom font making certain words look like other ones... Alerting the user about such formatting issues would be helpful (e.g. also when you try to redact something by drawing a black rectangle over it without removing the text underneath) but you probably shouldn't rely on it for security.
As long as Copilot can't be prevented from acting on instructions in its input, it would be safer to not make untrusted document content part of the input, similar to how macros in untrusted documents aren't executed by default.
> Why would there not be consideration for what a human user can see,
How would a machine actually know which part of a document a human can see unless they print it to PDF, scan the rasterised PDF and compare the result from the OCR with text in the document?
I mean, I dunno how Word would decide that the following can't be seen by a user: white-on-white text, rendering off-page, embedded font with no lines, text covered by an image, etc.
That's not an unsolvable problem. Checking visibility is easy, computer graphics have been doing this since forever. Fonts that are too small, ditto. Contrast is well understood.
If you do want to render, you don't have to do the convoluted PDF route. That's what the user would do, the software would just use its normal drawing code. OCR is neither needed nor desirable. OCR errors would erroneously flag perfectly normal text, and it can be fooled just like a human can. You can detect whether or not there's any rendering with the bounding box of whatever text section you are looking for (something Word already has to calculate if it wants to render correctly on screen).
I'm only talking about checking for visible text. This will not solve the larger problem of malicious AI instructions.
Embed text in an image, a human will read it just fine. Perfectly visible but opaque to AI. It'd be obnoxious to turn it into an attack, but you can replace letters with images in phrases so that humans read "she believed" while AI reads "he lied."
The premise of your project seems compelling. Is it novel or building on existing work? Anything one could read or watch to get introduced to that area of research?
You would already be able to see RSI and loops being a thing.
So there's going to be more and more research coming out telling you what size of models are really needed to solve a specific task. When you combine that with RSI, the next frontier would be to get this model as close to the real world with instant data and instant reasoning, no fine tuning at all. And see how this one could iterate itself.
I'll also be trying out more tiny models and seeing if they can call each other, and be as effective; You will also be seeing me trying this, in addition to what I'd already mentioned in the other reply.
I did some research about scaling laws and what's unsolved there.
This project was built on structural sparsity, do away with any requirements to train models on largely outdated corpus of data, and only train it on reasoning logic. Because if models can use tools well and retrieve everything else, it greatly would reduce the need for large language models.
Further, when generating traces, I ran a benchmark that showed that on grounded data, n-grams and simple retrieval outperformed transformers on efficiency (See https://github.com/guilt/Transformers) and wanted to try scaling this up to much larger traces.
It worked quite well. Next improvement would be to run this with a BERT model and add more do-not-know traces and the Claude style neurotic self-doubt/self-verify traces and test it out a bit more.
If the entropy required to route people to the relevant answers is very low, full dense attention is a waste of compute. That's the theory being pressure tested here. The more I do this exercise, the more I am getting convinced that smaller models are good enough.
I took a look at the codebase and found that this is just pattern matching. There is no any novelty here. It looks good for knowledge-base retrieval system, but other than that, this is just nothing more than a pattern-matcher.
Would love to be proven wrong with future updates.
Why don't you go and actually build something novel? People need to understand better how current models work, and if retrieval indeed solves 99% of the problems people care about, then those other models aren't doing anything super novel either.
I'm not arguing here: The code is out there, data is out there. Do better if you know something actually better. Thanks!
I was doing exactly this for a while with Claude Code. Very helpful when I'm away from home but can't stop thinking about my project. The remote agent has access to all the docs and instructions in my repo and most of the time gives me a decent draft I just need to polish later.
I unsubscribed from Claude after the performance regressions around the time of the Opus 4.7 update made it unusable. Been using Codex since then, and I've definitely missed being able to make these drafts. So I'm looking forward to trying this out.
