mireklzicar

I trained SynthonGPT, a transformer which is trained in the "language" of chemical building blocks and reactions. Those are chosen based on an existing chemical space, so that any valid sequence of reaction and synthon tokens produces a real drug-like molecule you can actually order (or synthesize yourself in one or two steps of synthesis). Thanks to this trick, it has zero hallucinations: in contrast to GPT-5 which often produces invalid or nonexisting structures, as well as previous models (Chemberta, MolGPT etc.).

Well, if you don't mean deepfakes which are obviously wrong, then that's kind of a point of all the existing AI tech, isn't it? AI image generators, AI written text as in GPT, AI written code, Text to Speech technology... The goal is to get as closely to human level performance as possible and maybe even exceed it.

Thanks — I read Ash’s post (great blog!) and even spun up USEARCH when I first explored this space.

Main differences:

* *Cost-efficiency:* USEARCH / FAISS / HNSW keep most of the index in RAM; at the billion scale that often means hundreds of GB. In CHEESE both build and search stream from disk. For the 5.5 B-compound Enamine set the footprint is ~1.7 TB NVMe plus ~4 GB RAM (only the centroids), so it can run on a laptop and still scale to tens of billions of vectors. This is also huge difference over commercial vector DB providers (pinecone, milvus...) who would bill you many thousands USD per month for it, because of the RAM heavy instances.

* *Vector type:* USEARCH demo uses binary fingerprints with Tanimoto distance. I use 256-D float embeddings trained to approximate 3-D shape and electrostatic overlap, searched with Euclidean distance.

* *Latency vs. accuracy:* BigANN-style work optimises for QPS and milisecond latency. Chemists usually submit queries one-by-one, so they don’t mind 1–6 s if the top hits are chemically meaningful. I pull entire clusters from disk and scan them exactly to keep recall high.

So the trade-off is a few seconds slower, but far cheaper hardware and results optimized for accuracy.

Well, it has some caveats: a) the papers need to be in crossref, which is ~ 70% of DOIs b) it works bad with preprints for instance. The advantage is its fast and doesn't need to download/extract anything from the pdf. But for 100% reliability it would be probably necessary.

Its actually open-source. Here is the repo: https://github.com/mireklzicar/doi-reference-extractor

APIs Used OpenCitations API (v2)

Endpoint: https://opencitations.net/index/api/v2/references/ Purpose: Retrieves a list of all references from a paper by its DOI Data format: JSON containing cited DOIs and metadata DOI Content Negotiation

Endpoint: https://doi.org/{DOI} Purpose: Fetches metadata and formatted citations for DOIs Formats: BibTeX, RIS, CSL JSON, RDF XML, etc. Implements CSL (Citation Style Language) for text-based citations Local Citation Style Files

Purpose: Provides access to thousands of citation styles Storage: Pre-generated JSON files with style information

Keep Zotero/Mendeley for collection management; use this simple tool when you just need the formatted references list in five seconds.

Where it helps

- Deep-dive reading – fetch bulk RIS file and dump a seminal paper’s entire bibliography into Zotero/Mendeley and follow the threads.

- Bulk citing – grab BibTeX's for a cluster of related papers without hunting them down one-by-one.

- LLM grounding – feed language models a clean reference list so they stop hallucinating citations.