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

What we've learned from a year of building with LLMs

eugeneyan.com

Post reply on HN
Print view View original

91–100 of 148 posts

Re: What we've learned from a year of building with LLMs

#91

Post by mattyyeung »

threeseed wrote: post #34

RAGs do not prevent hallucinations nor does it guarantee that the quality of your output is contingent solely on the quality of your input. Using LLMs for legal use cases for example has shown it to be poor for anything other than initial research as it is accurate at best 65%: https://dho.stanford.edu/wp-content/uploads/Legal_RAG_Halluc... So would strongly disagree that LLMs have become “good enough” for real-world…

You may be interested "Deterministic Quoting"[1]. This doesn't completely "solve" hallucinations, but I would argue that we do get "good enough" in several applications

Disclosure: author on [1]

[1] https://mattyyeung.github.io/deterministic-quoting

Re: What we've learned from a year of building with LLMs

#92

Post by hamelsmu »

mattmanser wrote: post #81
hamelsmu wrote: post #64

Earlier quoted context omitted.

Hi, Hamel here. I'm one of the co-authors. I'm an independent consultant and not all clients allow me to talk about their work. However, I have two that do, which I've discussed in the article. These are two production use cases that I have supported (which again, are explicitly mentioned in the article): 1. https://www.honeycomb.io/blog/introducing-query-assistant 2. https://www.youtube.com/watch?v=B_DMMlDuJB0 Other…

You've linked to a query generator for a custom programming language and a 1 hour video about LLM tools. The cynic in me feels like the former could probably be done by chatgpt off the shelf. But those do not seem to be real world business cases. Can you expand a bit more why you think they are? We don't have hours to spend reading, and you say you've been allowed to talk about them. So can you summarise the business…

> do not seem to be real world business cases

The first one is a real world product that lives in production that is user facing for a paid product.

The second video goes in depth about how a AI assistant was built for a real estate CRM company, also a paid product.

I don’t understand the assertion that it’s not “real world” or not “business”

Here are additional articles about these

https://help.rechat.com/guides/lucy

https://www.prnewswire.com/news-releases/honeycomb-launches-...

Re: What we've learned from a year of building with LLMs

#93

Post by jncfhnb »

janpieterz wrote: post #58
jncfhnb wrote: post #40

Earlier quoted context omitted.

… why would you have the LLM spit out a json rather than define the json yourself and have the LLM supply values?

How would I do this reliably? Eg give me 10 different values, all in one prompt for performance reasons? Might not need JSON but whatever format it outputs, it needs to be reliable.

Don’t do it all in one prompt.

Re: What we've learned from a year of building with LLMs

#95

Post by joatmon-snoo »

fancy_pantser wrote: post #70
joatmon-snoo wrote: post #69

Earlier quoted context omitted.

Constraining output means you don’t get to use ChatGPT or Claude though, and now you have to run your own stuff. Maybe for some folks that’s OK, but really annoying for others.

You're totally right, I'm in my own HPC bubble. The organizations I work with create their own models and it's easy for me to forget that's the exception more than the rule. I apologize for making too many assumptions in my previous comment.

Not at all!

Out of curiosity- do those orgs not find the loss of generality that comes from custom models to be an issue? e.g. vs using Llama or Mistral or some other open model?

Re: What we've learned from a year of building with LLMs

#96

Post by yoelhacks »

solidasparagus wrote: post #10
gandalfgeek wrote: post #7

Earlier quoted context omitted.

This was kind of conventional wisdom ("fine tune only when absolutely necessary for your domain", "fine-tuning hurts factuality"), but some recent research (some of which they cite) has actually quantitatively shown that RAG is much preferable to FT for adding domain-specific knowledge to an LLM: - "Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations?" https://arxiv.org/abs//2405.05904 - "Fine-Tuning or R…

Thanks, I'll read those more fully. But "knowledge injection" is still pretty narrow to me. Here's an example of a very simple but extremely valuable usecase - taking a model that was trained on language+code and finetuning it on a text-to-DSL task, where the DSL is a custom one you created (and thus isn't in the training data). I would consider that close to infeasible if your only tool is a RAG hammer, but it's a v…

This is exactly (one of) our use cases at Eraser - taking code or natural language and producing diagram-as-code DSL.

As with other situations that want a custom DSL, our syntax has its own quirks and details, but is similar enough to e.g. Mermaid that we are able to produce valid syntax pretty easily.

What we've found harder is controlling for edge cases about how to build proper diagrams.

For more context: https://www.eraser.io/decision-node/on-building-with-ai

Re: What we've learned from a year of building with LLMs

#97

Post by JKCalhoun »

> Note that in recent times, some doubt has been cast on if this technique is as powerful as believed. Additionally, there’s significant debate as to exactly what is going on during inference when Chain-of-Thought is being used...

I love this new era of computing we're in where rumors, second-guessing and something akin to voodoo have entered into working with LLMs.

Re: What we've learned from a year of building with LLMs

#98

Post by ezst »

JKCalhoun wrote: post #97

> Note that in recent times, some doubt has been cast on if this technique is as powerful as believed. Additionally, there’s significant debate as to exactly what is going on during inference when Chain-of-Thought is being used... I love this new era of computing we're in where rumors, second-guessing and something akin to voodoo have entered into working with LLMs.

That's the thing, it's a novel form of computing that's increasingly moving away from computer science. It deserves to be treated as a discipline of its own, with lots of words of caution and danger stickers slapped over it.

Re: What we've learned from a year of building with LLMs

#99

Post by phillipcarter »

threeseed wrote: post #34

RAGs do not prevent hallucinations nor does it guarantee that the quality of your output is contingent solely on the quality of your input. Using LLMs for legal use cases for example has shown it to be poor for anything other than initial research as it is accurate at best 65%: https://dho.stanford.edu/wp-content/uploads/Legal_RAG_Halluc... So would strongly disagree that LLMs have become “good enough” for real-world…

> So would strongly disagree that LLMs have become “good enough” for real-world applications" based on what was promised.

I can't speak for "what was promised" by anyone, but LLMs have been good enough to live in production as a core feature in my product since early last year, and have only gotten better.

Re: What we've learned from a year of building with LLMs

#100

Post by phillipcarter »

CuriouslyC wrote: post #11
solidasparagus wrote: post #2

No offense, but I'd love to see what they've successfully built using LLMs before taking their advice too seriously. The idea that fine-tuning isn't even a consideration (perhaps even something they think is absolutely incorrect if the section titles of the unfinished section is anything to go by) is very strange to me and suggests a pretty narrow perspective IMO

Fine tuning has been on the way out for a while. It's hard to do right and costly. LoRAs are better for influencing output style as they don't dumb down the model, and they're easier to create. This is on top of RAG just being better for new facts like the other reply mentioned.

I don't see why this is seen as an either-or by people? Fine-tuning doesn't eliminate the need for RAG, and RAG doesn't obviate the need for fine-tuning either.

Note that their guidance here is quite practical:

> If prompting gets you 90% of the way there, then fine-tuning may not be worth the investment.

Post reply on HN