Moonseye

A relic that doesn’t cost you your mind.

Moonseye is a retrieval system built over the Deepwoken wiki, using vector search so answers stay grounded in source material rather than invention.

Star on GitHubPortfolio
v0.1.0
ArchitectureMoonseye architectureTwo flows over one corpus. A question goes from the browser to the API, through vector search, to a cited answer from Gemini. Separately, wiki edits are picked up by a Go watcher, published to Kafka, and applied by a Python consumer.AskingQuestionbrowserAPIFastAPIRetrievalvector searchAnswerGemini, citedreadsCorpusPostgres + pgvector · chunks keyed by page idreplacesWiki editsrecentchangesWatcherGoQueueKafkaConsumerPythonStaying current

Two flows over one corpus. A question moves through retrieval and comes back cited. An edit on the wiki is picked up, queued, and applied, replacing only the pages that changed.

Pipeline
  • Chunking

    Pages split along their own structure: sections, infoboxes, tables. Long sections keep a full-section parent beside smaller children, so a match on one detail still answers with its context.

  • Embedding

    Each chunk becomes a 384-dimension MiniLM vector, stored in Postgres with pgvector and searched by cosine distance over an HNSW index.

  • Answering

    Retrieved chunks go to Gemini with their sources. When the text doesn’t support an answer, it says so instead of filling the gap.

Staying current
  • Watch

    A Go service polls the wiki’s recentchanges feed and sorts each entry into changed, deleted, or moved. It keys on the log action, not the log type, since an undeletion is also filed under “delete”.

  • Queue

    Events go onto one Kafka topic keyed by page id, so a page’s events stay ordered. An edit followed by a deletion cannot arrive backwards.

  • Apply

    A Python consumer refetches the page by id, rechunks it, and replaces that page’s rows in one transaction. Fetching by id follows renames. Offsets commit after the write lands, so a crash repeats one event.