Iris-mini and Iris-pro actually beat the benchmarks for open-weight search agents

AllSpark released Iris-mini and Iris-pro, two open-weight search agents built on Qwen architectures and tuned for search and tool-use, which the team says lead their respective size classes in search-specific benchmarks. According to the technical paper, the models also improved on general office tasks and tool-use without the catastrophic forgetting typical of task-specific tuning. Iris-mini is positioned for simple fact-retrieval and routing in smaller deployments, while Iris-pro is aimed at research agents that must synthesize conflicting search results.

Iris-mini and Iris-pro actually beat the benchmarks for open-weight search agents The AllSpark team just released Iris-mini and Iris-pro, and if you're looking for an open-weight search agent that doesn't hallucinate as much as base Qwen models, these are worth a look. They are built on Qwen architectures but specifically tuned for search and tool-use. What's interesting here isn't just the search performance, but the "leakage" of capabilities into general office work and tool-use tasks they weren't explicitly trained for. How do they actually perform? Most open-weight models struggle when you ask them to synthesize information from five different search results without drifting into generic filler. Based on the technical paper, these two models are currently leading their respective size classes in search-specific benchmarks. Since these are based on Qwen, you get the strong linguistic foundation, but the search-tuning makes them far more reliable for RAG /en/tags/rag/ Retrieval-Augmented Generation pipelines. I've noticed that when using standard open-weight models for search, they often ignore the provided context if it contradicts their internal weights. Iris seems to prioritize the retrieved snippets more effectively. Where they fit in your stack If you are choosing between these two, the decision comes down to your VRAM budget and the complexity of the search queries. - Iris-mini: Use this for simple fact-retrieval or as a router to decide if a search is even necessary. It's fast and fits in smaller deployments, but it can occasionally struggle with multi-step reasoning over very long documents. - Iris-pro: This is the one to use if you're building a research agent. It handles the synthesis of conflicting search results much better than the mini version. The surprise on general tool use The most unexpected takeaway from the release is that these models improved in areas outside of search. Usually, when you over-tune a model for a specific task like "web searching," you see a dip in general reasoning or "catastrophic forgetting." AllSpark claims these models actually got better at general office tasks and tool-use. In my experience, this usually happens when the search training involves a high volume of API interaction and structured data processing, which inadvertently teaches the model how to handle other tools. If you're running a local agent and need it to interact with a calendar or a database, Iris-pro might actually be a more stable choice than a generic 7B or 14B model. Potential failure points Don't expect these to be a "drop-in" replacement for a fully managed search engine. You still have to handle the retrieval layer yourself. If your search queries are garbage, the model will still struggle. Also, because they are open-weight, you're responsible for the quantization. If you use a 4-bit GGUF version to save memory, you might see a slight degradation in the precise synthesis of the search results compared to the full FP16 weights. Next DeepSeek v4 and Gemini 1.5 both failed to fix my ESP-IDF component paths → /en/threads/9266/ All Replies （4） I want to try this tonight. I'm curious if they actually fixed the 404 parsing error that plagues the original AllSpark pipeline. I'm curious if these weights actually solve the latency spikes I hit with vLLM. Does it scale linearly at 128 tokens?