snyy

Good question!

As you read the rest of this answer, keep in mind that Critic attaches to your agent as a plugin. Plugins can have hooks (https://code.claude.com/docs/en/hooks and https://learn.chatgpt.com/docs/hooks) that pass instruction to an agent at predefined boundaries.

Now, Critic doesn't interfere with the actual process of code-writing. Your agent is free to write code as it wants. Critic's plugin simply observes the agent during its turn and at certain boundaries, nudges it to write a narrative. The plugin also comes with skills on how to write a concise narrative and how to identify "complex code" that needs annotation. Critic also prevents an agent from ending its turn until it publishes a quality narrative (we use heuristics like word count and format parsing to measure this).

All together, this results in a narrative that is short, direct, and easy to skim through.

Happy to hear it!

Demo runs on an AWS VM with L4 GPUs. We don't record any logs/data, so feel free to use the demo on whatever images you want.

MultiMatte is open source, so you can also run the model locally or in your VM too

Our blog covers this: https://usefeyn.com/blog/feynobg/#strength-in-diverse-data

Recapping here: Our first train was on 4,000 images from the MaskFactory dataset alone. This improved some benchmarks but regressed on others. We took this as a sign of narrow datasets causing unintended specialization.

In our next run, we assembled 26.1K images from 10 different datasets. We capped the amount of images that could come from one source, to prevent a single type of example from dominating. This composite set covered several cases like crowded scenes, camouflage, high-res subjects, fine objects like hair, blurred backgrounds, etc. We then shuffled everything together and trained FeyNoBg.

Your question touches on excellent points.

> what is the subject?

FeyNoBg is an "automatic" model. It automatically detects foreground elements and segments the image. Most of the time, this includes all foreground elements. As you can see in the freekick example (https://drive.google.com/file/d/1MZkAGLwbhNVOZ0Oi7XvpCfSEu9Q...), the model output includes the ball, Messi, and the Liverpool defenders. In your example, FeyNoBg will segment around the person plus the couch.

> I only want the person [including props]

The alternative to automatic models are prompt models and those serve the exact use case you're describing. These allow you to specify the foreground element to include. Everything else is removed. That's the next step for FeyNoBg, converting it from an automatic to a prompt model. Now, answering your question:

> How does it stack up against Adobe's model?

We're better on automatic background removal. Support for selecting a subset of foreground elements is coming soon

This pertains to the larger open source licensing discussions that have been happening (as I'm sure you've seen too).

We've released projects under the MIT license before, most notably https://github.com/feyninc/chonkie. While we're not trying to directly monetize on this work, credit goes a long way and helps in other operations.

Recently, attributed usage is shrinking. To be clear, this is not a shrinkage in actual use of our software, just how many people acknowledge that they rely on it.

cc-by-nc is a protection against that. We've been very honest about our work being on top of BiRefNet as we want to extend the original creators the same courtesy. I have no issues if individuals fork/finetune/or otherwise build on top of any open source projects we release, irrespective of license. At minimum, we want acknowledgment if a company chooses to use our software in production.

Please do try, I would love nothing more!

All I ask is you make a PR to https://github.com/feyninc/nobg with your results. We'd love to see what you make, contribute in any way we can, and share onwards.

We resize the opacity mask. That tends to scale better

Thanks! Feel free to open an issue if you run into any issues with the outputs

https://github.com/feyninc/nobg/issues

The 4K cap was a judgement call, we didn't want one source to dominate. The license is cc-by-nc, just added it to the hugging face

Exactly this. Thank you for answering!

Ah yes, I meant accuracy.

Yes. I tried it with https://www.allbirds.com/products/womens-cruiser-canvas on our HF space and Pulpie worked great.

HF Space: https://huggingface.co/spaces/feyninc/pulpie

Images pass through as they are considered main content. Same with tables.

Pulpie will return all main content on a page as HTML/Markdown. I’m not sure I fully understand “which one this is good at?”. perhaps you can try the model on hugging face and let me know if the results look good?

https://huggingface.co/spaces/feyninc/pulpie

We see far better performance with models. Heuristics break on richer content like codeblocks, formulae, quotes, etc. In our testing, our model was 25 F1 points better than Trafilatura.

Fixed. Try again. Let me know if any other issues

Thanks! Good questions:

We haven't run a targeted eval against SEO spam yet. However, with Pulpie, each block gets labeled by what the text actually says rather than what the tags look like. Wrapping boilerplate in semantic tags fools rule based extractors precisely because they judge structure. Pulpie doesn't. The closest benchmark we have for this is the WebMainBench difficulty split, where pulpie-orange-small holds 0.813 on the hard subset. For comparison, trafilatura scores a 0.526.

For quantization, we haven't benchmarked INT8 or FP8. Everything in the post ran on L4 and A100. That said, I expect it to go well for a few reasons. It's a single forward pass over the page, so the workload is compute bound rather than bandwidth bound, which is why the L4 held up so well against the A100 and why cheaper cards should degrade gracefully. At 210M params the small model is roughly 420MB in FP16 and half that in INT8. So it fits on any consumer GPU with room to spare. Also, one pass classification tends to survive 8 bit quantization better than autoregressive generation since there is no error accumulation across decode steps.

Funnily enough, that wasn't my first choice either. I A/B tested it with a small group and people understood "up and to the right is better" faster.

You have the right understanding.

We've found that maximizing chunk size gives the best retrieval performance and is easier to maintain since you don't have to customize chunking strategy per document type.

The upper limit for chunk size is set by your embedding model. After a certain size, encoding becomes too lossy and performance degrades.

There is a downside: blindly splitting into large chunks may cut a sentence or word off mid-way. We handle this by splitting at delimiters and adding overlap to cover abbreviations and other edge cases.

As the other comment said, its a practice in good enough chunks quality. We focus on big chunks (largest we can make without hurting embedding quality) as fast as possible. In our experience, retrieval accuracy is mostly driven by embedding quality, so perfect splits don't move the needle much.

But as the number of files to ingest grows, chunking speed does become a bottleneck. We want faster everything (chunking, embedding, retrieval) but chunking was the first piece we tackled. Memchunk is the fastest we could build.

No, delimiters can be multiple bytes. They have to be passed as a pattern.

// With multi-byte pattern

let metaspace = "<japanese_full_stop>".as_bytes();

let chunks: Vec<&[u8]> = chunk(text).pattern(metaspace).prefix().collect();

A big chunk size with overlap solves this. Chunks don't have to be be "perfectly" split in order to work well.

Which language are you thinking of? Ideally, how would you identify split points in this language?

I suppose we've only tested this with languages that do have delimiters - Hindi, English, Spanish, and French

There are two ways to control the splitting point. First is through delimiters, and the second is by setting chunk size. If you're parsing a language where chunks can't be described by either of those params, then I suppose memchunk wouldn't work. I'd be curious to see what does work though!

> Chunking is generally a one-time process where users aren't latency sensitive.

This is not necessarily true. For example, in our use case we are constantly monitoring websites, blogs, and other sources for changes. When a new page is added, we need to chunk and embed it fast so it's searchable immediately. Chunking speed matters for us.

When you're processing changes constantly, chunking is in the hot path. I think as LLMs get used more in real time workflows, every part of the stack will start facing latency pressure.

Memchunk is already in Chonkie as the `FastChunker`

To install: pip install chonkie[fast]

``` from chonkie import FastChunker

chunker = FastChunker(chunk_size=4096) chunks = chunker(huge_document) ```

We're the maintainers of Chonkie, a chunking library for RAG pipelines.

Recently, we've been using Chonkie to build deep research agents that watch topics for new developments and automatically update their reports. This requires chunking a large amount of data constantly.

While building this, we noticed Chonkie felt slow. We started wondering: what's the theoretical limit here? How fast can text chunking actually get if we throw out all the abstractions and go straight to the metal?

This post is about that rabbit hole and how it led us to build memchunk - the fastest chunking library, capable of chunking text at 1TB/s.

Blog: https://minha.sh/posts/so,-you-want-to-chunk-really-fast

GitHub: https://github.com/chonkie-inc/memchunk

Happy to answer any questions!

How did the OTP case work? Where was the OTP received and how did the browser know?

Or did it bypass it entirely with corporation from the website?

We're working on Mongo integrations!

We want to be the platform that connects documents to AI for all applications. Consequently, we want to cover all use cases, including the ones you mentioned :)

Yes :) Code chunker is fantastic for SQL