Open Deep Research
github.com
Open Deep Research
1–10 of 83 posts
Re: Open Deep Research
#2it's just an example, but it's great to see smolagents in practice. I wonder how well the import whitelist approach works for code interpreter security.
Re: Open Deep Research
#3I think I'm in love.
Re: Open Deep Research
#4it's just an example, but it's great to see smolagents in practice. I wonder how well the import whitelist approach works for code interpreter security.
I know some of the point of this is running things locally, but for agent workflows like this some of this seems like a solved problem: just run it on a throwaway VM. There's lots of ways to do that quickly.
Re: Open Deep Research
#5it's just an example, but it's great to see smolagents in practice. I wonder how well the import whitelist approach works for code interpreter security.
I know some of the point of this is running things locally, but for agent workflows like this some of this seems like a solved problem: just run it on a throwaway VM. There's lots of ways to do that quickly.
VM is not the right abstraction because of performance and resource requirements. VMs are used because nothing exists that provides same or better isolation. Using a throwaway VM for each AI agent would be highly inefficient (think wasted compute and other resources, which is the opposite of what DeepSeek exemplified).
Re: Open Deep Research
#6[deleted]
Re: Open Deep Research
#7[flagged]
Re: Open Deep Research
#8https://techcrunch.com/2025/02/04/hugging-face-researchers-a...
> On GAIA, a benchmark for general AI assistants, Open Deep Research achieves a score of 54%. That’s compared with OpenAI deep research’s score of 67.36%..Worth noting is that there are a number of OpenAI deep research “reproductions” on the web, some of which rely on open models and tooling. The crucial component they — and Open Deep Research — lack is o3, the model underpinning deep research.
Re: Open Deep Research
#9Earlier quoted context omitted.
I know some of the point of this is running things locally, but for agent workflows like this some of this seems like a solved problem: just run it on a throwaway VM. There's lots of ways to do that quickly.
VM is not the right abstraction because of performance and resource requirements. VMs are used because nothing exists that provides same or better isolation. Using a throwaway VM for each AI agent would be highly inefficient (think wasted compute and other resources, which is the opposite of what DeepSeek exemplified).
To which performance and resource requirements are you referring? A cloud VM runs as long as the agent runs, then stops running.
Re: Open Deep Research
#10Earlier quoted context omitted.
I know some of the point of this is running things locally, but for agent workflows like this some of this seems like a solved problem: just run it on a throwaway VM. There's lots of ways to do that quickly.
VM is not the right abstraction because of performance and resource requirements. VMs are used because nothing exists that provides same or better isolation. Using a throwaway VM for each AI agent would be highly inefficient (think wasted compute and other resources, which is the opposite of what DeepSeek exemplified).
Is “DeepSeek” going to be the new trendy way to say to not be wasteful? I don’t think DS is a good example here. Mostly because it’s a trendy thing, and the company still has $1B in capex spend to get there.
Firecracker has changed the nature of “VMs” into something cheap and easy to spin up and throw away while maintaining isolation. There’s no reason not to use it (besides complexity, I guess).
Besides, the entire rest of this is a python notebook. With headless browsers. Using LLMs. This is entirely setting silicon on fire. The overhead from a VM the least of the compute efficiency problems. Just hit a quick cloud API and run your python or browser automation in isolation and move on.