You are comparing it to a hash, following some extra rules on what the data could be. You have exactly the length of hash before you can reliably count on duplicates (and collisions happen much sooner). In torrent v1, this is SHA-1, which has a 160-bit (or 20 byte) hash. Which means for every single additional random bit, you have doubled the number of possible matches.

If your torrent has an uncommonly small chunk size of 256KiB, that's 261,144 bytes. Minus the 20 from above, and you have a likely 256^261124 chunks that match your hash. That's a number so large that Google calls it infinity. It would take you forever just to generate these chunks by brute force, since each would need to be created, then hashed, then the results stored somewhere. Many years ago, I remember someone doing this on CRC32 (32 bits/4 bytes) and 6 byte files. It took all night, and produced dozens of hash-matching files. You're talking many orders of magnitude bigger.

But then what? You'd still need to apply the other rules on what the data could be. Rules that are probably more CPU-intensive than the hash algorithm.

The one trick that AI might be able to use to save the day is that it may contain in its corpus the original file. In effect, that would make the AI an unlikely seeder.

I mean, is it that different from "upscaling" or "interpolation"?