Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Greptile (YC W24) - RAG on codebases that actually works

news.ycombinator.com

Post reply on HN
Print view View original

141–150 of 173 posts

Re: Launch HN: Greptile (YC W24) - RAG on codebases that actually works

#141

Post by levelforge »

smokel wrote: post #99
eikenberry wrote: post #98

Earlier quoted context omitted.

> The latter is typically the realm of requirements, design documentation, and possibly test plans. You forgot one of the biggest spots for "why" documentation... git commit messages, where the point is to say why you made this change. Maybe taking into account the commit messages around the code in question would help.

"Initial commit" is my goto commit message. Still a great idea, though. Ingesting all data from JIRA may be beneficial as well.

We already do that and more at Maru.ai - reach out if you're interested.

Re: Launch HN: Greptile (YC W24) - RAG on codebases that actually works

#143

Post by dakshgupta »

jgraettinger1 wrote: post #139
dakshgupta wrote: post #90

Earlier quoted context omitted.

That's funny, we actually do ignore those files but realizing now we don't account for that in our calculation of codebase size since we just get that via the GH API.

This comes from a place of love and empathy -- I've been here, am here, and will be here again -- but this realization reads like the first step in the long, long road from prototype to product.

You are right

Re: Launch HN: Greptile (YC W24) - RAG on codebases that actually works

#144

Post by dakshgupta »

derwiki wrote: post #137
cdtwigg wrote: post #136

Apparently I’m the only one here who doesn’t know this but: What is RAG?

Retrieval Augmented Generation; basically, find relevant bits from a lot of data, and load the relevant bits into context.

Great answer

Re: Launch HN: Greptile (YC W24) - RAG on codebases that actually works

#145

Post by Sn0wCoder »

dvt wrote: post #81

Ran it on a "real" OSS project of mine ( https://github.com/dvx/lofi/ ), and it was stuck at 99% loading for about 30 minutes. Then, when it finally parsed the codebase, when asked anything it always returns "Error: Internal error while locating sources." Specifically, I wanted to see if it can context switch between TypeScript (used for the front-end), ObjectiveC (used for a few Mac features), C++ (used for Windows…

Got the same error....

Re: Launch HN: Greptile (YC W24) - RAG on codebases that actually works

#147

Post by jasonkester »

You’re going to want to define the acronym RAG before you use it a dozen times in your marketing copy.

Presumably it’s great news that I can RAG on my codebase. But I’m not sure whether I’ve ever ragged anything in my career or whether I’ll want to now.

If you told us what it meant, we could probably understand what your thing does.

Re: Launch HN: Greptile (YC W24) - RAG on codebases that actually works

#148

Post by MikePlacid »

soohoonchoi wrote: post #89
dvt wrote: post #81

Ran it on a "real" OSS project of mine ( https://github.com/dvx/lofi/ ), and it was stuck at 99% loading for about 30 minutes. Then, when it finally parsed the codebase, when asked anything it always returns "Error: Internal error while locating sources." Specifically, I wanted to see if it can context switch between TypeScript (used for the front-end), ObjectiveC (used for a few Mac features), C++ (used for Windows…

Hey sorry to hear that, a couple of things: - processing is usually stuck at 99% because when we order the components of the repository by file-directory dependency and ast dependency, there are a lot, LOT more leaves than the internal nodes + the root. Since we have to have the results of the dependency before we move on, moving up the dependency chain with llm calls take a while. This is even more pronounced when n…

> processing is usually stuck at 99%

Why call it 99% then, call it 49%.

Re: Launch HN: Greptile (YC W24) - RAG on codebases that actually works

#149

Post by dakshgupta »

jasonkester wrote: post #147

You’re going to want to define the acronym RAG before you use it a dozen times in your marketing copy. Presumably it’s great news that I can RAG on my codebase. But I’m not sure whether I’ve ever ragged anything in my career or whether I’ll want to now. If you told us what it meant, we could probably understand what your thing does.

Thanks Jason, you're right. We spend so much time around RAG that we forget this is niche term.

RAG -> retrieval augmented generation. Given a query, finding the parts of the codebase most relevant to the query, and supplying it to the LLM so it can answer the query. The typical way to do this is semantic similarity, or chunking + embedding the corpus being searched, embedding the query and finding the k most cosine-similar chunks.

Re: Launch HN: Greptile (YC W24) - RAG on codebases that actually works

#150

Post by dakshgupta »

MikePlacid wrote: post #148
soohoonchoi wrote: post #89

Earlier quoted context omitted.

Hey sorry to hear that, a couple of things: - processing is usually stuck at 99% because when we order the components of the repository by file-directory dependency and ast dependency, there are a lot, LOT more leaves than the internal nodes + the root. Since we have to have the results of the dependency before we move on, moving up the dependency chain with llm calls take a while. This is even more pronounced when n…

> processing is usually stuck at 99% Why call it 99% then, call it 49%.

Noted - I think Soohoon meant to use the word "often" and not usually. That said, you're right, counting completed nodes would be a more accurate way of measuring progress.
Post reply on HN