Methodology

Platform

Purna is a research workspace in which language-model agents carry out biological research tasks: answering questions from curated databases, running analyses in isolated compute environments, reviewing literature, drawing figures and drafting manuscripts. This document describes how those components work, what each one checks, and where its limits are. It is written for scientists who need to decide whether an output can be trusted and how to verify it.

Lifecycle of a request

Every message takes the same initial path. It is checked for scope, and the orchestrator then sends it down one of six routes. The figure traces each route; the sections that follow describe them in order.

One design principle recurs throughout: planning is separated from execution. Anything that consumes significant compute, runs code, calls a specialised model, generates a figure or changes a manuscript is first expressed as an object you can review (a plan, a review protocol, a figure brief or a proposed edit) and runs only after you approve it.

Application layer

The web application and its API run on Vercel. Responses are streamed with the Vercel AI SDK. Model calls pass through a gateway that fails over to another provider of the same model if a provider times out or returns a rate-limit or server error. It does not retry once output has started streaming, so a response is never spliced together from two attempts. Application state (conversations, plans, jobs, citations, document versions and audit events) is stored in PostgreSQL. Long-running and scheduled work, such as launching sandboxes, reconciling job state and recovering from failures, is coordinated by a durable workflow engine rather than by request handlers, so it survives deployments and restarts.

Storage

Files are stored in Google Cloud Storage. Uploads go directly from your browser to storage through signed, resumable sessions; file contents do not pass through the application servers. Before a file is registered, the platform verifies the stored object’s generation, size and CRC32C checksum, and storage quotas are enforced under a per-user lock. Downloads use short-lived signed links pinned to a specific object generation, so a link always returns exactly the bytes that were registered. The application authenticates to Google Cloud through workload identity federation, so no long-lived service-account keys are stored.

Objects are addressed under tenant- and project-scoped prefixes. Each background run receives its own prefix, which is mounted into its sandbox as an ordinary directory through FUSE. The mount is authorised by a short-lived credential downscoped to that run’s prefix (a credential access boundary). Isolation is therefore enforced by the storage service, not by trusting code running inside the sandbox.

Sandboxes

Background analyses run in dedicated cloud sandboxes (Firecracker microVMs provided by E2B), one per job. The analysis profile has 4 vCPUs and 8 GB of memory, a lifetime of up to 24 hours and a limit of one hour per shell command. Shell commands run as an unprivileged user with a cleared environment, so model-provider and storage credentials cannot be read from the agent’s shell. Network access is restricted to the public internet: private, loopback, link-local and carrier-grade NAT address ranges and the cloud metadata endpoint are blocked. Sandboxes have no GPU; GPU models are reached through the mediated path described under Biological models.

External services

Agents reach external knowledge through a typed tool layer rather than through unrestricted network access. About thirty integrated knowledge sources cover genes and sequences, variants, proteins and structures, pathways and interactions, chemistry and targets, clinical trials and literature; they are listed under Direct answers. Every tool input is validated against a schema, each tool is rate-limited within a conversation, and every call is written to an audit log. Support for connecting your own remote services over the Model Context Protocol, with per-call approval, encrypted credentials and egress restrictions, has been built but is not yet generally available.

Scope and routing

Before a generation model sees a message, a lightweight classifier answers two multiple-choice questions about it. Is the request within scope (biological and life-sciences research)? And is it a research question that can be answered directly, or a multi-step task that needs a plan? The classifier receives the current message, a bounded window of recent conversation, the selected mode and organism, and metadata (never contents) for attached files. It has a five-second timeout and does not retry.

The classifier acts on its own only when it is confident. A request labelled out of scope with confidence of at least 0.90 receives a fixed refusal. A request labelled in scope and needing a plan, both with confidence of at least 0.90, goes directly to the planner. Every other case, including mixed or unclear requests, lower-confidence labels and any classifier failure, goes to the main agent under a scope gate. On its first step the main agent can call only a single routing tool, and all research tools stay locked until it has accepted the request. When the fast path is uncertain or unavailable, the decision falls back to a slower, model-mediated check rather than being skipped.

Explicitly chosen modes override workflow classification. When you select Plan, Deep Research or Paper Writing, the workflow comes from your selection; scope is still checked. When a background job is already attached to the conversation, routing is deterministic and no model is asked to choose: messages to a running job are placed in an ordered inbox that the agent reads at safe points, and a message after a job has finished continues it.

Policy is also enforced in the agents’ instructions. The assistant is limited to biological and life-sciences research. It declines unrelated tasks and requests for individual medical advice (diagnosis, treatment or dosing for a specific person), and it presents clinical information as decision support rather than diagnosis. Content retrieved from tools, files and web pages is treated as data, never as instructions, as a defence against indirect prompt injection.1 If a model provider’s own safety filter stops a response, the stream ends with a notice rather than a partial answer.

Direct answers

Questions that can be answered from existing knowledge are handled within the conversation by the orchestrator, an agent that interleaves reasoning with tool calls2 and grounds its answer in what those tools return.3 It runs at a low sampling temperature and is limited to a fixed number of steps per turn. No code is executed on this path; computation always goes through a background job. In conversation, the assistant reads a bounded portion of attached files (for example, the first 256 KB of a text file); background agents read files in full.

Specialist resources without a dedicated integration, such as ENCODE, JASPAR, CARD, DrugBank, Orphanet and the model-organism databases, are reached through web search restricted to their domains. Results obtained this way are less structured than results from a direct integration.

Because the answer is assembled from tool output, its reliability is bounded by those sources and by the model’s reading of them. Language models can misstate facts they have retrieved,6 so answers link claims to the records they came from, allowing identifiers, accession numbers and classifications to be checked at the source. Each tool is rate-limited within a turn and is disabled after repeated consecutive failures, so a failing external service visibly degrades an answer instead of sending the agent into a loop.

Planning

Requests that need several steps, code execution, specialised models or long-running compute are turned into a plan. The planner is a separate agent that cannot execute anything. It sees the conversation, earlier jobs, and metadata for your files (names, formats, sizes and validation status), but not file contents, storage paths or download links. It begins with one bundled inspection of that context and of the capabilities available to you, can make a few further lookups (for example, reading the documentation of a relevant skill), and must return a structured result within eight model steps.

That result is one of three things: a ready plan, a request for a missing required input such as a dataset, or clarifying questions. Questions are asked only when the answer would change safety, which data are authorised, scientific validity, constraints or success criteria; for example, which of several qualifying datasets to analyse, or the chain composition of a multi-molecule complex. There is at most one round of at most three questions, each with two or three mutually exclusive options and a free-text alternative. After you answer, the planner must produce a plan. Any remaining uncertainty becomes an explicit inspection or decision step inside the plan rather than another question.

What a plan contains

• Objective. A single statement of what the run should achieve.
• Milestones (1–20). Each has an expected outcome, an approach, deliverables, validation criteria, dependencies on earlier milestones, and the capabilities it needs, such as code execution, a named knowledge source or a specific model version.
• Assumptions and constraints. Stated explicitly so that they can be challenged before any compute is spent.
• Success criteria. The conditions under which the run counts as complete.
• Budget. Compute minutes and a cap on specialised-model attempts (by default, 30 BioCompute minutes and five attempts).

Before you see it, the plan is validated on the server. Milestone identifiers must be unique; dependencies must form an acyclic graph and refer to real milestones; every capability a milestone uses must be one you are entitled to; every model requirement must match the current model catalogue exactly; and only authorised datasets may be referenced. Malformed output is repaired automatically at most twice; otherwise planning fails visibly.

Approval

Approval binds to an exact plan version. The stored plan is hashed (SHA-256 over canonical JSON), and approval is accepted only if the hash and version match the plan you reviewed. Entitlements, dataset authorisation and concurrency limits are re-checked at that moment. Revising a plan cannot widen what it is permitted to do, and during the run the agent must raise an explicit change request to obtain more budget or scope. Milestones are commitments about outcomes rather than a to-do list: the agent decides how to reach them, and the plan’s validation criteria define what reaching them means.

Compute agents

After approval, a background compute agent executes the plan in a fresh sandbox. The environment is a pinned image: Python 3.12 with hash-locked dependencies, R with Bioconductor, and Node.js. It includes NumPy, SciPy, pandas, matplotlib, Biopython,7 Scanpy and AnnData,8 pysam, PyDESeq2 and the Bioconductor DESeq2 package,9 GSEApy and gemmi. Other packages can be installed during a run from public repositories.

The agent has three kinds of resource. Approved datasets are copied into the sandbox and verified by size and checksum (up to 5 GB per dataset and 10 GB per run). The knowledge-source tools available in conversation are reachable through a gateway that re-authorises every call against the grants in the approved plan. The public internet is available for reading documentation, fetching public datasets and installing software.

Procedural knowledge is packaged as skills: versioned, read-only instruction bundles for tasks such as differential expression, structure-prediction workflows, installing dependencies and delivering outputs. The agent sees a short description of each available skill and loads the full text only when it needs it, which keeps its working context small.

Decomposition and delegation

The main agent works through the milestones and keeps private working notes on what remains. It can delegate a genuinely independent workstream to a subagent, which starts with a clean, isolated context and returns a bounded synthesis and the paths of any files it produced, not its full transcript. The progress you see in the interface is published by the main agent as tasks and notes. Run-wide limits cap the total number of model calls, and a loop detector watches recent tool calls: three identical repeats produce a warning to the agent, and five end the run.

Working memory

Long analyses outgrow a model’s context window, so the agent’s working context has a fixed budget. When it is 60% full, older large tool results are written to files and replaced in context by short references, and only the most recent results are kept inline. At 85% the conversation is summarised and only its most recent part is kept verbatim. Nothing is lost from disk: offloaded results remain as files that the agent can re-read.

Validation

Validation in a background run happens at four layers, which differ in the strength of the guarantee they provide.

• Contract checks (deterministic). Every tool call is validated against its schema and against the grants in the approved plan. Calls outside the plan are rejected by the gateway, independently of the agent’s judgement.
• Scientific self-checks (model-performed). Each milestone carries validation criteria, and the agent is instructed to check units, identifiers and reference levels, to confirm identity on database lookups, to run a consolidated validation pass before finishing, and never to describe a structural result as validated if a geometry check failed. Because these checks are carried out by the model, they are not guaranteed.
• Output checks (deterministic). Model outputs are checked mechanically where possible. Structure-format conversions that would change molecular identity are rejected, and designed binders are checked for target identity, binder length, finite coordinates and sequence agreement.
• Completion gates (deterministic). A run cannot report success unless every model run the plan required has a trusted receipt and every required deliverable exists and passes structural validation. A manifest records whether each artifact was produced by the agent, by the runtime, or verified from a model provider. It makes no claims about scientific content.

Failure and recovery

The agent checkpoints its state locally after every step. At lifecycle boundaries (plan handover, a request for your input, an acknowledged message, a controlled pause, completion or failure) a recovery bundle is saved to durable storage. The intent and result of every tool call are recorded write-once, so on recovery, completed calls are replayed rather than executed again. If a sandbox is lost, the job returns to the last verified save and asks you before continuing in a replacement sandbox, stating when the save was made and that some work may be repeated. In-memory state, uncommitted files and packages installed during the run are not restored. You can also message a running job; messages are delivered to the agent at safe points.

Biological models

Some plan steps need specialised models for structure prediction, docking, backbone generation, sequence design or protein embeddings. These run on GPU infrastructure outside the sandbox through a mediated path: the agent prepares a request, the platform validates and budgets it, an isolated executor submits it, and results are written to storage before the agent reads them.

Model versions are pinned in a catalogue, and a plan must name the exact model and version it will use. Today, the structure, docking and design models are served from NVIDIA-hosted inference endpoints, and the language and binder-design models from BioLM’s hosted API. We have also built pre-configured containers for the latter on Modal’s GPU infrastructure (T4 GPUs for ESM-2, A100 40 GB for BoltzGen, CPU for AbLang-2), with schema-validated inputs, checksummed outputs and no automatic retries. That path has passed validation runs but does not yet serve production traffic.

Literature review

Deep Research produces a structured review of the published literature. It runs as a dedicated worker on Google Cloud Run, isolated from the chat application, with a fixed time budget and no database credentials: it writes its outputs to a private bucket and reports progress through signed callbacks. The design follows the logic of a systematic review (an explicit question, explicit criteria and recorded screening decisions), but it is not a substitute for one, and it does not claim PRISMA compliance.17

Protocol

The request is first turned into a review protocol by a single structured-output call. The question is decomposed into PICO or PECO elements (population, intervention or exposure, comparator and outcome),18 with synonyms and required concepts. The protocol proposes inclusion and exclusion criteria, study types, language, age and sex restrictions, a publication-year window, a grey-literature policy and a screening ceiling of 50, 100, 250 or 500 records. The planner is instructed not to exclude animal, in-vitro or non-English studies by default, and it does not write search queries; those are derived later from the approved protocol. You can edit any field before approving, and nothing is retrieved until you do.

Search and acquisition

Queries are generated from the approved concepts and run primarily against OpenAlex,19 supplemented by web search; PubMed is used to fill in missing abstracts and metadata. Retracted works are excluded at query time. Records are de-duplicated across sources using a hierarchy of identifiers. Full text is sought only through open-access routes (publisher open-access locations, PubMed Central and Unpaywall), and shadow libraries are explicitly blocked. A paper whose full text cannot be obtained is recorded as an access failure and listed among the report’s limitations; it is never counted as excluded on scientific grounds.

Screening

Screening has two stages before full-text reading. A deterministic metadata screen applies the year window, language, publication-type and grey-literature criteria, and records pass, fail or unclear for each criterion. A dedicated screening model, separate from the models that write the report, then judges each title and abstract against the protocol’s criteria, including organism or population, study design, intervention and outcome. Papers that cannot be decided from the abstract are carried forward for full-text assessment rather than discarded. Full-text eligibility is then assessed on the paper itself, and each inclusion decision must cite passages that are verified to occur verbatim in the text. Per-stage counts are appended to every report.

Indexing

Included papers are parsed into retrievable passages. The embedded text layer is used when its quality is sufficient; pages or whole documents that fail an automatic quality check are re-read with an OCR model, which also recovers tables as structured text. Text is split into overlapping, page-scoped passages that keep the paper’s identity, page number and inferred section. Each passage is indexed twice: as a dense embedding in an approximate nearest-neighbour index,20 and in a lexical full-text index. Retrieval combines the two rankings with reciprocal rank fusion:21

Here R is the set of rankings, rank_r(d) is the position of passage d in ranking r, and k is a smoothing constant. Dense retrieval captures paraphrase, while lexical retrieval captures exact identifiers such as gene symbols, variant names and compound codes, which embeddings can blur.

Synthesis and citation

Synthesis proceeds in stages. Each study is characterised (design, population, interventions and outcomes), with every extracted value tied to supporting passages and missing values left empty rather than inferred. Findings are then extracted, and each study’s methodological quality is assessed (randomisation, blinding, confounding, risk of bias, funding and statistical reporting). A cross-study evidence matrix feeds the final report.

Citations are constrained structurally. The writing agent can cite only passages that were retrieved for it, identified by internal passage IDs; an unknown ID is an error, so a reference that was never retrieved cannot appear in the report. Quoted evidence must match the cited passage exactly, with at least three words and with numbers and negations preserved, or it is dropped. Each claim in the report is then checked against the passages it cites and must carry a record of that support. Bibliographic details come from the acquisition records, not from the model.

Scientific figures

Figures are produced by a dedicated image agent running as a separate service. As elsewhere, its first output is not an image but a figure brief that you can edit. The brief contains the scientific content to be depicted (which is also the reference for the critique), the visual intent, exact labels to be rendered verbatim, constraints, the figure type (diagram, schematic, pathway, infographic or illustration), size and quality, and optional layouts such as two- or three-panel and methods figures. Rendering starts only when your latest message carries the approved brief, and the service uses the fields of that brief rather than any later rewording by the conversational model.

Reference-guided composition

To choose a composition, a reasoning model ranks a corpus of reference figures drawn from published academic papers and selects the ten most useful for layout, figure type and visual clarity. References inform composition and style only; the model is instructed not to take scientific content from them. A life-sciences style guide covers biological notation (for example, activation arrows versus inhibition bars, and cellular compartments), labels, legends and plots.

Critique loop

A planning step turns the brief and the selected references into a detailed description, which an image model renders. A critic model then compares the rendered image with the brief and its scientific content. It looks for missing or incorrect entities, mislabelled genes or proteins, reversed activation and inhibition, misplaced compartments, unsupported causal claims, invented numbers and illegible text, and, for charts, values, units, axes, legends and uncertainty that disagree with the supplied data. It returns specific corrections and a revised description, which is rendered again. The loop runs for at most three critique rounds and stops early when the critic finds nothing to change, a form of iterative self-refinement.22 One to four candidate figures can be generated per brief.

Charts are drawn by the image model from data you supply; its instructions require the supplied values to be used exactly and forbid invented data points, error bars or p-values. Where numerical accuracy matters, plotting code run in a background job is the more reliable route, because its output can be checked deterministically against the data.

Paper writing

Manuscripts live in a shared, structured editor. Documents are represented as conflict-free replicated data types (CRDTs),23 synchronised over WebSockets and persisted in PostgreSQL, so you, your collaborators and agents can edit the same document at the same time without overwriting one another. Agent edits are applied as fine-grained document operations, so they do not reset your cursor or selection.

Agents in the document

Agents work on a document through a small set of tools: inspect it (an outline with stable block identifiers), insert a section, replace a specific block or selection, insert an image, and add citations. Inspection is required before any change. Every change goes through you: the agent proposes the complete new content, you review it, and it is applied only if you approve. Each version records whether a person or an agent made it, and any version can be restored.

The writing agents are general-purpose language models; they have not been fine-tuned. Their behaviour is constrained by an evidence policy in their instructions and by validation on the server:

• Claims about the work itself (searches, analyses, ethics approvals, data deposits, funding) require your confirmation, project records or successful tool results. Planned work stays worded as planned.
• Unsupported statements are omitted or explicitly flagged as needing author confirmation. Repositories, accession numbers and licences are never invented.
• Edits must preserve existing citations, terminology and specificity (organism, gene, cohort), must not introduce references, data, p-values, findings or mechanisms, and should hedge where the evidence is uncertain.
• Citations an agent adds must resolve against bibliographic databases (OpenAlex, PubMed or Crossref), or the edit fails. Each citation records how it was verified.
• Requests that depend heavily on the literature are routed to the research-capable document assistant rather than answered from the model’s memory.

Writing co-pilot

The co-pilot proposes the next sentence as you write. When you pause, it builds a query from the paper’s title and scope, the current section and the text around your cursor, and searches the scholarly literature using your filters (publication years, minimum citation count, and whether to include preprints). Only retrieved papers judged high-confidence are kept, each with an exact supporting passage, with Results, Methods and Discussion preferred over abstracts. Sources already cited in the paragraph are excluded.

A suggestion is shown only if it passes validation on the server. Each quoted evidence span must occur in the retrieved passage, meet a minimum length and not simply repeat the title; every cited source must resolve; and the sentence must not restate one already in the paper. In the Abstract, the co-pilot draws only on your manuscript, and it declines if the manuscript does not yet contain the objective, methods, results or conclusions to summarise. Refinements, such as asking it to use one strong source, are tied to the original suggestion’s evidence by a signed token and must return a claim-by-claim audit; any retained claim that is not fully supported by its sources is rejected.

Accepting a suggestion inserts the text and adds the source to the manuscript’s citation list. Each citation occurrence stores the exact evidence quote, the text around it, the source section and a content hash, so a sentence can be traced back to the passage that supports it. Opening the citation shows that passage highlighted in the source PDF when the PDF can be retrieved. Papers attached from your Library are pinned to a specific stored file by its SHA-256 hash. Citations can be formatted in ten styles, including Vancouver, Nature, APA, AMA and ACS, and documents can be exported to DOCX, LaTeX and Markdown.

Limitations

We have tried to state the guarantees of each component precisely. In summary:

• Language models make errors. Every output, whether an answer, analysis, review, figure or manuscript text, should be reviewed by a qualified scientist before it informs a decision. Purna does not provide medical advice.
• Many checks are performed by models. Deterministic checks cover structure, provenance, molecular identity and quotation. They do not establish that an interpretation is scientifically correct.
• Routing thresholds are conservative but not calibrated against production traffic.
• Literature coverage is limited to indexed metadata and open-access full text. Reviews are PRISMA-style, not PRISMA-compliant systematic reviews.
• Model predictions (structures, poses, designs and embeddings) are hypotheses, not measurements.
• Generated figures are drafts, and the critique loop has not been formally evaluated.
• Recovery after an infrastructure failure restores the last verified save; some work may be repeated, and packages installed during the run must be reinstalled.
• Sandboxes are an isolation boundary for computation, not a certified environment for protected health information.
• Components described as not yet generally available, such as remote connectors and self-hosted model containers, may change before release.

References

1. 1Greshake K, Abdelnabi S, Mishra S, Endres C, Holz T, Fritz M. Not what you’ve signed up for: compromising real-world LLM-integrated applications with indirect prompt injection. Proc. 16th ACM Workshop on Artificial Intelligence and Security. 2023:79–90. doi.org/10.1145/3605764.3623985
2. 2Yao S, Zhao J, Yu D, Du N, Shafran I, Narasimhan K, Cao Y. ReAct: synergizing reasoning and acting in language models. International Conference on Learning Representations. 2023. arxiv.org/abs/2210.03629
3. 3Lewis P, Perez E, Piktus A, et al. Retrieval-augmented generation for knowledge-intensive NLP tasks. Advances in Neural Information Processing Systems. 2020;33:9459–9474. arxiv.org/abs/2005.11401
4. 4The UniProt Consortium. UniProt: the Universal Protein Knowledgebase in 2023. Nucleic Acids Research. 2023;51(D1):D523–D531. doi.org/10.1093/nar/gkac1052
5. 5Varadi M, Anyango S, Deshpande M, et al. AlphaFold Protein Structure Database: massively expanding the structural coverage of protein-sequence space with high-accuracy models. Nucleic Acids Research. 2022;50(D1):D439–D444. doi.org/10.1093/nar/gkab1061
6. 6Ji Z, Lee N, Frieske R, et al. Survey of hallucination in natural language generation. ACM Computing Surveys. 2023;55(12):1–38. doi.org/10.1145/3571730
7. 7Cock PJA, Antao T, Chang JT, et al. Biopython: freely available Python tools for computational molecular biology and bioinformatics. Bioinformatics. 2009;25(11):1422–1423. doi.org/10.1093/bioinformatics/btp163
8. 8Wolf FA, Angerer P, Theis FJ. SCANPY: large-scale single-cell gene expression data analysis. Genome Biology. 2018;19:15. doi.org/10.1186/s13059-017-1382-0
9. 9Love MI, Huber W, Anders S. Moderated estimation of fold change and dispersion for RNA-seq data with DESeq2. Genome Biology. 2014;15:550. doi.org/10.1186/s13059-014-0550-8
10. 10Passaro S, Corso G, Wohlwend J, et al. Boltz-2: towards accurate and efficient binding affinity prediction. bioRxiv. 2025. doi.org/10.1101/2025.06.14.659707
11. 11Corso G, Stärk H, Jing B, Barzilay R, Jaakkola T. DiffDock: diffusion steps, twists, and turns for molecular docking. International Conference on Learning Representations. 2023. arxiv.org/abs/2210.01776
12. 12Watson JL, Juergens D, Bennett NR, et al. De novo design of protein structure and function with RFdiffusion. Nature. 2023;620:1089–1100. doi.org/10.1038/s41586-023-06415-8
13. 13Dauparas J, Anishchenko I, Bennett N, et al. Robust deep learning–based protein sequence design using ProteinMPNN. Science. 2022;378(6615):49–56. doi.org/10.1126/science.add2187
14. 14Lin Z, Akin H, Rao R, et al. Evolutionary-scale prediction of atomic-level protein structure with a language model. Science. 2023;379(6637):1123–1130. doi.org/10.1126/science.ade2574
15. 15Olsen TH, Moal IH, Deane CM. Addressing the antibody germline bias and its effect on language models for improved antibody design. Bioinformatics. 2024;40(11):btae618. doi.org/10.1093/bioinformatics/btae618
16. 16Stark H, Faltings F, Choi M, et al. BoltzGen: toward universal binder design. bioRxiv. 2025.
17. 17Page MJ, McKenzie JE, Bossuyt PM, et al. The PRISMA 2020 statement: an updated guideline for reporting systematic reviews. BMJ. 2021;372:n71. doi.org/10.1136/bmj.n71
18. 18Richardson WS, Wilson MC, Nishikawa J, Hayward RS. The well-built clinical question: a key to evidence-based decisions. ACP Journal Club. 1995;123(3):A12–A13.
19. 19Priem J, Piwowar H, Orr R. OpenAlex: a fully-open index of scholarly works, authors, venues, institutions, and concepts. arXiv:2205.01833. 2022. arxiv.org/abs/2205.01833
20. 20Malkov YA, Yashunin DA. Efficient and robust approximate nearest neighbor search using hierarchical navigable small world graphs. IEEE Transactions on Pattern Analysis and Machine Intelligence. 2020;42(4):824–836. doi.org/10.1109/TPAMI.2018.2889473
21. 21Cormack GV, Clarke CLA, Büttcher S. Reciprocal rank fusion outperforms Condorcet and individual rank learning methods. Proc. 32nd ACM SIGIR Conference. 2009:758–759. doi.org/10.1145/1571941.1572114
22. 22Madaan A, Tandon N, Gupta P, et al. Self-Refine: iterative refinement with self-feedback. Advances in Neural Information Processing Systems. 2023;36. arxiv.org/abs/2303.17651
23. 23Shapiro M, Preguiça N, Baquero C, Zawirski M. Conflict-free replicated data types. Stabilization, Safety, and Security of Distributed Systems (SSS). LNCS 6976. 2011:386–400. doi.org/10.1007/978-3-642-24550-3_29