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.
Hey HN, I'm Shreyash from Feyn. We help companies build custom models from their data. Today we're releasing Critic, a change review platform that lets you engage directly with the AI that wrote the code.Agents write most of our code. While that has made us more productive, understanding a change and its consequences has become incredibly difficult. As our company adopted more agentic tools, we...
MultiMatte is open source, so you can also run the model locally or in your VM too
> 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
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.
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.
https://usefeyn.com/blog/feynobg/
Hey HN, I’m Shreyash from Feyn. We help companies build custom models from their data.Today, we’re releasing FeyNoBg, an automatic background removal model. Alongside it, we're open-sourcing NoBg, the Python library we built to train and run it.Try the model here: https://huggingface.co/spaces/feyninc/feynobg. Check out the library here: https://github.com/feyninc/nobgSome sample outputs:(1)...
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?
We match SOTA extraction quality while being 20x cheaper. Cleaning 1 billion webpages costs $7,900 with Pulpie versus $159,000 with Dripper, the current leading extractor.
The gains come from architecture. Today's leading extractors are decoders that generate output one token at a time. Each step reads the full model from memory to produce a single token. Conversely, Pulpie models are encoders. They run one forward pass over the full input HTML and label each block as boilerplate or content. As a result, Pulpie is compute-bound while decoders are memory-bound. Cheaper GPUs have relatively more compute than memory bandwidth. This makes Pulpie easy to run optimally.
Here's Pulpie and Dripper cleaning the same pages side by side: https://www.youtube.com/watch?v=ibd-tIiQECo. You can try a side-by-side comparison yourself: https://huggingface.co/spaces/feyninc/pulpie
Our motivation for Pulpie came from building a deep research harness. Every search API returns noisy content that contains ads, nav elements, and sidebars. In one instance, an ad for "Gemini on Pixel" slipped into our search results, got passed into LLM context, and ended up in the final answer served to the user. Pretty embarrassing moment for us but it helped us realize how bad data kills model intelligence. We built Pulpie to get clean data for cheap.
All models are open source on Hugging Face. You can read about our training process and how to use Pulpie here: https://usefeyn.com/blog/pulpie-pareto-optimal-models-for-cl...
Happy to answer any questions!
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.
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.
// With multi-byte pattern
let metaspace = "<japanese_full_stop>".as_bytes();
let chunks: Vec<&[u8]> = chunk(text).pattern(metaspace).prefix().collect();
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!
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.
To install: pip install chonkie[fast]
``` from chonkie import FastChunker
chunker = FastChunker(chunk_size=4096) chunks = chunker(huge_document) ```
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!