It maintains a vector store and a SQL database. While vector store supports usual RAG operations, the ones that require counting, summation, selection are routed to the SQL database.

There is an option to start with an initial schema, or let it discover the schema itself. Then on the day to day use, if a user query cannot be responded, a candidate schema entry is created to be populated on the next backfill run.

So in actual use, user asks the question such as "Give me the list of people who are scientists". If it is not in the schema, LLM suggest checking it later. Backfill runs at night. Next day it can answer the same question without issues.

- Sample files

- A video of end-to-end process of creating a basic model (perhaps something more complex than a cube) from 3d design to finished artefact.

- Support for STL

- Built-in option to adjust (reduce) face counts

The traditional RAG works fine until you ask questions like: - "Who was born before 1800?" - "How many are mathematicians?" - "List names and birthdays for mathematicians"

These result in an incomplete answer due to top-k, with no signs of incompleteness.

For an initial corpus, it is possible to improve this problem by extracting metadata for a predetermined set of fields. This approach has two problems:

- One has to predict all the questions that can be asked against the corpus upfront. - Constantly revising that prediction as the documents change, e.g. adding Nobel prizes later, or extending the document set to contain artists.

DuoRAG aims to solve both problems by:

- An initial metadata (schema) discovery before the first ingestion - Self-update schema with candidate fields when it fails to answer a question

Comments URL: https://news.ycombinator.com/item?id=47542131

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47298373

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=47288886

Points: 1

# Comments: 0

This might be the case for a hobby project or a start-up MVP being created in a rush, but in reality, there are a few points we may want to take into account:

1. Software teams I work with are maintaining the usual review practices. Even if a feature is completely created by AI. It goes through the usual PR review process. The dev may choose "Accept All", although I am not saying this is a good practice, the change still gets reviewed by a human.

2. From my experience, sub-agents intended for code and security review do a good job. It is even possible to use another model to review the code, which can provide a different perspective.

3. A year ago, code written by AI was failing to run the first time, requiring a painful joint troubleshooting effort. Now it works 95% of the time, but perhaps it is not optimal. Given the speed at which it is improving, it is safe to expect that in 6-9 months' time, it will not only work but will also be written to a good quality.

My biggest concern would be that adopting the CLI method would require LLM to have permission to execute binaries on the filesystem. This is a non-issue in an openclaw-type scenario where permission is there by design, but it would be more difficult to adopt in an enterprise setting. There are ways to limit LLMs to a directory tree where only allowed CLIs live, but there will still be hacks to break out of it. Not to mention, LLM would use an MCP or another local tool to execute CLI commands, making it a two-step process.

I am a supporter of human tools for humans and AI tools for AI. The best example is something like WebMCP vs the current method of screenshotting webpages and trying to find buttons inputboxes etc.

If we keep them separate, we can allow them to evolve to fully support each use case. Otherwise, the CLIs would soon start to include LLM-specific switches and arguments, e.g., to provide information in JSON.

Tools like awscli are good examples of there LLM can use a CLI. But then we need to remember that these are partly, if not mostly, intended for machine use, so CI/CD pipelines can do things.

Believe it or not, there are still a large amount of great tech professionals out there who are sceptical about AI. Many tried AI a year ago and has the impression that "It was alright but had limitations". AI came a long way since then, and it is going to improve even faster over the next 6 months. So this is Anthropics invite for you to join that journey.

In turn, of course this fuels the adoption by superstars (maintainers) endorsing the models.

Also, the end product is open source anyway, so there is no case of IP being leaked into training data. What remains is that they can use, with your permission, the overall coding practices of a great programmer to fine-tune Claude's code and models. As in, how one approaches planning or troubleshooting. Is this a bad thing? Perhaps every maintainer should decide for themselves whether they want to contribute back or not.

The first PR is unlikely to be merged the next day; however, it sparks lots of productive discussions with the rest of the community, allowing your kid to build a mental model of the project's best practices and sensitivities.

The more he contributes, the more integral he becomes to the community. After gaining enough experience through small issues, they can even consider working on a new feature.

As a byproduct, a great addition to the CV if they are also looking to go commercial.

Comments URL: https://news.ycombinator.com/item?id=47123065

Points: 2

# Comments: 0

A smaller number of PRs generated by OpenClaw-type bots are also doing so based on their owner's direct or implied instructions. I mean, someone is giving them GitHub credentials and letting them loose.

AI is also allowing the creation of many new open-source projects, led by responsible developers.

Given the exponential speed at which AI is progressing, surely the quality of such PRs is going to improve. But there are also opportunities for the open-source community to improve their response. It will sound controversial, but AI can be used to perform an initial review of PRs, suggest improvements, and, in extreme cases, reject them.

My personal opinion is that things will only accelerate from here.

Half of the people who get the notification click "join" without checking. This ends up with a half-populated meeting room. The issue becomes obvious, and somebody says, "Let's dial back in 5 mins", and drops off. Half of the people like the idea and drop off, while the rest decide to stay and chat.

Meanwhile, some of those who dropped off see this as a great opportunity to grab a brew. That inadvertently triggers some water-cooler, kettle-corner chats, and they end up running late for the 5-past. The rest usually get engaged in something else to make use of 5 minutes, and miss 5-past since no new notifications are issued due to the people already chatting in the meeting :)