gemma3:4b 在小眾任務虛構 29 個 npm/PyPI 套件，作者開發 ghostdeps 偵測工具

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

I asked a model running on my laptop how to parse SWIFT payment messages in Node.js. This is what it said:

The most popular and well-maintained option is swi██-█████.

Why it's good: This package is specifically designed for parsing and validating MT103 messages. It handles the complex structure and data elements of the standard accurately.

GitHub: https://github.com/j█████████/swi██-█████

npm install swi██-█████

The npm registry has never heard of that package. The GitHub repository returns a 404. So does the GitHub user. And this wasn't an isolated typo. The model had confidently recommended something that had no verifiable existence, complete with a repository and a convincing explanation of why developers should trust it. The model made up a library, a reputation, and the person who maintains it, and it did so in the same calm voice it uses to recommend Express.

Most of the entries I read this week look for ghosts in old code, deleted files or abandoned repos. I went looking in the weights. Those packages have no grave and no history. They exist in exactly one place, and I have a copy of it on my D: drive.

ghostdeps is a tool for detecting AI-hallucinated dependencies before they make it into your project. It runs a census of package recommendations from local open-weight models, extracts every suggested dependency, and checks each name against package registries. It asks a local open-weight model ordinary developer questions, pulls out every package it says to install, and checks each one against the registries. Each name gets a state, and the names turned out to need the whole vocabulary of a ghost story:

Then it gives you the part you can use tomorrow: ghostdeps check, which reads a package.json, a requirements file, or an answer you pasted from a chatbot, and tells you which of those states you're about to install. On a manifest, clean means every dependency was checked. On a pasted answer, it only means every name it found is real, and it says so, because English has no grammar a parser can finish.

Why bother? Because a package that doesn't exist is an empty room with a sign on the door. This is the attack known as slopsquatting: find a name that models keep inventing, register it, put something nasty inside, and wait for someone to paste the install command. You don't need to fool the developer. The model already did that for you.

Demo

Here is summon, which asks the model and then asks the registry. The model writes a full usage example, with a parser API that looks entirely reasonable, for something that isn't there:

$ ghostdeps summon "parse SWIFT MT103 payment messages" --eco npm --redact

**Installation:**

npm install swi██-█████

**Usage Example:**

const SwiftMT103 = require('swi██-█████');

// Parse the message
const parsedMessage = SwiftMT103.parse(message);

  GHOST      swi██-█████  npm: no such name on the registry, and deps.dev
                          has no memory of it; seen 7x in the census

And check, which never touches the model at all:

$ ghostdeps check answer.md

  alive      express               npm: real, and the registry agrees
  dead       left-pad              npm: use String.prototype.padStart()
  GHOST      zz-not-real-pkg-9931  npm: no such name on the registry, and deps.dev has no memory of it

3 checked: 1 alive, 1 dead, 1 ghost

Try ghostdeps Yourself

ghostdeps

Ask a local AI model which package to use and it will give you a confident answer install command included. For common tasks that answer is usually fine. For unusual ones, the package often doesn't exist.

I wanted to know how often that happens, so I asked Gemma 535 questions on my laptop and checked every package it named against npm and PyPI. This repo is the code behind that census. It also includes a small tool you can point at a package.json a requirements file or a pasted chatbot answer to check the names before you install anything.

What I found

Everything ran locally on a laptop with a 4 GB GPU, in about 70 minutes of model time. I call a name a "ghost" when the model told me to install it but neither the registry nor deps.dev has any record of it.

…

Node 20+, zero runtime dependencies, for reasons that should be obvious by now. check needs nothing else. summon and census need Ollama and gemma3:4b.

What the census found

535 questions, all local, on a laptop with a 4 GB GPU, about 70 minutes of model time. 120 tasks, half of them everyday things like "connect to PostgreSQL" and half of them the long tail: hospital messages, satellite tiles, mass spectrometry files. I wrote the list before the first census run, and left out the eight tasks from my first probe so nobody could say I'd tuned it.

That first row is what convinced me this was real. On the everyday tasks the bigger model produced no ghosts at all. It didn't get gradually less reliable on hard questions. It fell off a cliff, and it gave no sign of falling. Nearly half the time you ask about something rare, the name you get is one it made up, delivered in the same voice.

The worst part is that it answers at all. A person who didn't know would say so. Asked about an old database file format, the model recommended a confident, wrong, PDF-flavoured name as "the most commonly recommended and well-supported package".

They come back

For this to be an attack, a ghost has to repeat. A name that appears once is noise. A name that appears every time is an address.

So I asked each haunted question five more times, with new seeds and the temperature raised to 0.7.

All 29 ghosts came back at least once, 2.7 times each on average, and 6 came back every single time. One honest caveat: these were the model's first choice, so they had a head start. Spracklen et al. (below) saw a split result on other models, with 43% repeating in all ten of their reruns and 39% never repeating.

The number that bothered me more was this one. Of those 145 reruns, 129 contained a ghost. Often a different one: 63 distinct ghosts in total. The question itself was haunted. When the model has no real answer in memory, it doesn't stop. It just writes a name.

They can't tell they're dead

If the model could spot its own inventions, the fix would be easy: ask it to check its work. Spracklen et al. found three of the four models they tried could do exactly that, with more than 75% accuracy.

So I put the model's own niche answers back in front of it, 29 ghosts and 31 real packages, and asked if each one was real.

It got 35 of 60 right. Then I changed the wording to the paper's, and it got 35 of 60 right again, with different mistakes. One phrasing called 18 of its ghosts real, the other called 14, and 10 of the 60 names changed verdict. It's only 60 names, so I wouldn't call this a precise figure. But it's nowhere near good enough to rely on, and that's why check never asks the model. A verdict shouldn't depend on the thing that caused the problem.

Something moved in

Two names the model gave me are held by brand new packages with almost no use.

One is the bit I keep thinking about. I pulled these weights on October 4. A name the model gave me for an invoicing task had its first upload on PyPI on October 16. Those weights were sitting on my disk twelve days before that package existed.

I'm not naming either package, because I want to be careful here: the one I looked at reads like a vendor's perfectly ordinary alias for its own product. Occupied is not an accusation, and nothing suggests anyone did anything wrong. But that's the whole mechanism, right there, playing out innocently on my laptop. The name was empty. The model kept saying it. Then someone moved in.

How I Built It

The pipeline is deliberately boring: ask the model, parse install commands out of the answer, ask the registries. All of the interesting work was in not fooling myself, and I fooled myself five times.

A 404 doesn't mean "never existed." My first draft said it did. But a package pulled for policy reasons can also return a 404. So every ghost is now checked against deps.dev too, which keeps its own records. If it remembers the name, the verdict is tombstone, not GHOST. All 29 survived that check, and each one was reviewed individually. I still say "no trace found", never "proven never to exist".

My control was flattering the model. The self-awareness test originally compared ghosts against the first real packages in the list, which were things like express. That measures fame, not awareness. I caught it before the round ran and restricted the real packages to the same niche tasks.

"Comments aren't commands" was wrong. Models write # pip install redis above their examples, and my parser was throwing those away. A ghost in that position would never have been counted. Now a comment counts only if the command is the first thing in it, so # run npm install first can't produce a package called first.

And the best one: I wrote a claim the data then killed. My report template said that with pinned weights and a fixed seed, everyone gets the same ghost, byte for byte. Then the repeat test came back: 12 of 30 identical.

Temperature 0, same seed, same digest. Answers were diverging from the first word. So I replayed it properly, and the result surprised me:

It was me. To save time I was aborting each stream early, and hanging up on one answer changes the answers that come after it. That's worth knowing if you stream from a local model. I can't explain the remaining 4, so I won't try. And the census gave me a better finding than the one I'd written: of the 29 repeats that named a package, 26 named the same one, even though most of the sentences around it had changed. The ghosts held on a little less well, with 6 of the 8 in that set coming back, so I won't overclaim it. But the sentences drift far more than the names do, and for an attacker the name is the only part that matters.

And the last one was my own tool. I had an independent review run over the finished code, and it found that check could say "clean" in about twenty ordinary ways. A dev-requirements.txt with a ghost in it exited 0, because it fell through to the wrong parser, found nothing, and called that a pass. A pip freeze saved from PowerShell did the same, because UTF-16 read as nothing. A ghost that wasn't the first install on its line was never seen. So I rebuilt the parser and made "I read nothing" its own exit code, because in a safety tool, no answer has to look different from a good answer. Then review found bugs in the rebuild too, including one that deleted an install whenever the comment above it ended in a backtick. It took four rounds, and the lesson of round three was to stop: manifests have a grammar and English doesn't, so on a pasted answer check now tells you it read prose and can't rule out what it didn't recognise. The same review caught that my "same package" count had been treating two answers with no package as a match, which is why that figure above is 26 of 29 and not the 27 of 30 I first wrote. Rerunning the analysis on the raw answers afterwards, it was the only number in the census that moved.

I also broke my own code on purpose. npm run mutants disables 148 guards one at a time and checks that a test notices. The first run caught six mistakes: two guards that did nothing and four tests that passed for the wrong reason. There are 179 tests now, and every one of those 148 breaks gets caught.

Why Does Open Innovation Matter?

Open didn't win on accuracy. Let me start there, because it would be easy to skip. Spracklen et al. found open-source models hallucinated more than commercial ones, 21.7% against 5.2%. I didn't test any closed models, so I can't tell you how they'd do on my list. If you want the fewest ghosts, open weights may not be the answer.

Open won on something else: I could do this at all.

I could afford to be thorough. 535 questions cost me nothing but electricity. When a result looked wrong I reran 30 questions or 60 names without thinking about it. The second wording and the determinism replay are both runs I might have skipped if each one had a price.

The thing I was studying held still. The weights sit on my disk under a fixed digest. When the repeat test failed, I knew the model hadn't changed between runs, so the bug had to be somewhere I could reach. That's how a mystery about "AI being random" turned into a bug of my own. With a hosted model I could never have ruled that out, because it can change underneath you without notice.

And it runs with the lights off. The generating half of the census only ever talks to 127.0.0.1. The host is a constant in the code, not a setting. The registries only get consulted afterwards.

There's an uncomfortable flip side, and I'd rather say it than have you think I missed it: everything that makes this easy for me makes it easy for an attacker. Anyone can do what I did. That's why the repo doesn't ship the list. Raw names stay on my machine, the report masks at least two thirds of every name, and check matches against SHA-256 hashes, with a test that fails if a full name reaches a published file. Spracklen et al. withheld their list too.

That's a speed bump, not a vault. It would take someone an afternoon to regenerate most of it, and I just won't save them the afternoon. But open weights mean defenders get the same afternoon. A census of a closed model only lasts until the next silent update. This one can be rerun by anyone, on any pinned version, forever. And since the weights keep saying these names long after the question was asked, it matters that somebody can keep watching: ghostdeps watch re-checks your local ghosts and tells you if one has stopped being empty.

I haven't registered any of these names. Please don't either, not even as a joke. That is the attack.

What it is not

It's one model family and one task list that I wrote myself. Half of those tasks are obscure on purpose, so the 24.6% only means something next to that mix. The 0 of 57 is a result on my everyday list, not a promise that everyday questions are safe, and the smaller model did slip three times. Some ghosts may be real projects distributed outside the registry, and at least one looks that way, though the install still fails and the name is still free. Some npm names may be impossible to register because they're too close to existing ones. I didn't test that, because the test is registering them.

Prize Categories

Best Use of Gemma. Gemma is the subject of the census as well as the engine. Both gemma3:4b and gemma3:1b run locally through Ollama, and the findings above are about how these models behave at the edge of what they know.