4 ms·
Graph DBs model relationship between entities. Is that a useful property of your retrieval task? They won't magically make your retrieval better without other a
by AJRF 1y ago
Graph DBs model relationship between entities. Is that a useful property of your retrieval task? They won't magically make your retrieval better without other additional work.
How are you evaluating your current retrieval? Can you get to the point where you can compare your current solution with a Graph based one?
A lot of the time i've seen people reach for a Graph DB they actually wanted/needed re-ranking of results.
An aside but the Director of ML at a company I worked for kept telling us "We need a Graph! We need a Graph!" and when questioned about _why_ said because we could find fastest routes between train stations (it was for a big train ticket retailer) - no matter how many times we told him we don't set the routes and timetables, it's set by National Rail.
I (and many others) left the company shortly after his arrival.
- osigurdson 1y ago>> An aside but the Director of ML at a company I worked for kept telling us "We need a Graph! We need a Graph!" It depends. Maybe they knew something that the team didn't but couldn't articulate it. Maybe it would have been great. Alternately (and this seems to be a common tactic unfortunately), is they don't really know what they are doing but use the strategy of introducing a large / time consuming change and promise incredible things once the change is complete. The longer the change takes, the better in this situation as they can just chill while the change is taking place and polish resume for the next gig if it doesn't work out. If they jump to a new job before failure is obvious they can claim that they affected some large change at previous company and repeat the process. The other strategy is to performtatively claim success in the face of failure and move on to the next big thing.