6 ms·

One example: I've been working for a couple years (not full time) on a high performance FOSS address matcher: https://github.com/moj-analytical-services/uk_add

by RobinL 1mo ago

One example: I've been working for a couple years (not full time) on a high performance FOSS address matcher: https://github.com/moj-analytical-services/uk_address_matcher https://github.com/moj-analytical-services/uk_address_matche... Until recently LLMs have been really bad at this task. I always knew it was coming, but with GPT 5.6 they've suddenly become good. It's pretty clear to me that it won't be long before most of my work on this is rendered pointless because the LLM can either do the classification itself (when given agentic access to the canonical list of addresses), or write a classifier itself if given enough labelled data. Of course these two are complementary

zelphirkalt 1mo ago
If your tool is deterministic, I would rather rely on it, than on LLMs for the task. So I don't think your work will have been pointless, when comparing against an LLM classifying things. Also there is value in something that is battle-tested compared to something just generated on the run, and there is value in something already existing and not needing to be generated or developed anew.
luke5441 1mo ago
Given it is being trained on your project, the latter isn't that surprising. For the former, you could use LLMs yourself for the probabilistic matching as alternative method? Probably you don't because the trade-offs (like performance) are not worth it...
- RobinL 1mo ago
  Yes - it's certainly the case at the moment that you can run a few thousand through the LLM at a reasonable price, but not, say, ten million. But the rate of progress suggests to me that this argument won't hold up forever. Eventually I think an off the shelf LLM will outperform most and probably all more traditional ML models at this task. Largely because LLMs can identify tricky ones and pick them out for more intensive effort (e.g. looking online, further searches again the canonical list of addresses)
  - zelphirkalt 1mo ago
    I didn't check which model exactly you are using, but I think a complex LLM, that is capable of deciding to look online, will probably always be more expensive than most classical models. Maybe if someone invents a way that reliably strips every other ability than answering the one question one has and checking online sources, the LLM can reach an equal level.

by RobinL 1mo ago

zelphirkalt 1mo ago

If your tool is deterministic, I would rather rely on it, than on LLMs for the task. So I don't think your work will have been pointless, when comparing against an LLM classifying things. Also there is value in something that is battle-tested compared to something just generated on the run, and there is value in something already existing and not needing to be generated or developed anew.

luke5441 1mo ago

Given it is being trained on your project, the latter isn't that surprising. For the former, you could use LLMs yourself for the probabilistic matching as alternative method? Probably you don't because the trade-offs (like performance) are not worth it...

RobinL 1mo ago
Yes - it's certainly the case at the moment that you can run a few thousand through the LLM at a reasonable price, but not, say, ten million. But the rate of progress suggests to me that this argument won't hold up forever. Eventually I think an off the shelf LLM will outperform most and probably all more traditional ML models at this task. Largely because LLMs can identify tricky ones and pick them out for more intensive effort (e.g. looking online, further searches again the canonical list of addresses)
- zelphirkalt 1mo ago
  I didn't check which model exactly you are using, but I think a complex LLM, that is capable of deciding to look online, will probably always be more expensive than most classical models. Maybe if someone invents a way that reliably strips every other ability than answering the one question one has and checking online sources, the LLM can reach an equal level.