保留正文与补采附件。源页面当前未重新核验;具体限制见交付清单。

Transformer Circuits Thread

Towards Monosemanticity: Decomposing Language Models With Dictionary Learning

Towards Monosemanticity: Decomposing Language Models With Dictionary Learning

Using a sparse autoencoder, we extract a large number of interpretable features from a one-layer transformer.
Browse A/1 Features →
Browse All Features →

Authors

Trenton Bricken*, Adly Templeton*, Joshua Batson*, Brian Chen*, Adam Jermyn*, Tom Conerly, Nicholas L Turner, Cem Anil, Carson Denison, Amanda Askell, Robert Lasenby, Yifan Wu, Shauna Kravec, Nicholas Schiefer, Tim Maxwell, Nicholas Joseph, Alex Tamkin, Karina Nguyen, Brayden McLean, Josiah E Burke, Tristan Hume, Shan Carter, Tom Henighan, Chris Olah

Affiliations

Anthropic

Published

Oct 4, 2023

Authors

Affiliations

Published

Not published yet.

DOI

No DOI yet.

Contents

Problem Setup

Detailed Investigations of Individual Features

Global Analysis

Phenomenology

Related Work Discussion Comments & Replications

Author Contributions Statement Acknowledgments Citation Information Feature Proxies Feature Interpretability Rubric Feature Density Histograms Transformer Training and Preprocessing Advice for Training Sparse Autoencoders Automated Interpretability Mechanistic interpretability seeks to understand neural networks by breaking them into components that are more easily understood than the whole. By understanding the function of each component, and how they interact, we hope to be able to reason about the behavior of the entire network. The first step in that program is to identify the correct components to analyze. Unfortunately, the most natural computational unit of the neural network – the neuron itself – turns out not to be a natural unit for human understanding. This is because many neurons are polysemantic: they respond to mixtures of seemingly unrelated inputs. In the vision model Inception v1, a single neuron responds to faces of cats and fronts of cars . In a small language model we discuss in this paper, a single neuron responds to a mixture of academic citations, English dialogue, HTTP requests, and Korean text. Polysemanticity makes it difficult to reason about the behavior of the network in terms of the activity of individual neurons. One potential cause of polysemanticity is superposition , a hypothesized phenomenon where a neural network represents more independent "features" of the data than it has neurons by assigning each feature its own linear combination of neurons. If we view each feature as a vector over the neurons, then the set of features form an overcomplete linear basis for the activations of the network neurons. In our previous paper on Toy Models of Superposition , we showed that superposition can arise naturally during the course of neural network training if the set of features useful to a model are sparse in the training data. As in compressed sensing, sparsity allows a model to disambiguate which combination of features produced any given activation vector.For more discussion of this point, see Distributed Representations: Composition and Superposition. In Toy Models of Superposition, we described three strategies to finding a sparse and interpretable set of features if they are indeed hidden by superposition: (1) creating models without superposition, perhaps by encouraging activation sparsity; (2) using dictionary learning to find an overcomplete feature basis in a model exhibiting superposition; and (3) hybrid approaches relying on a combination of the two. Since the publication of that work, we've explored all three approaches. We eventually developed counterexamples which persuaded us that the sparse architectural approach (approach 1) was insufficient to prevent polysemanticity, and that standard dictionary learning methods (approach 2) had significant issues with overfitting. In this paper, we use a weak dictionary learning algorithm called a sparse autoencoder to generate learned features from a trained model that offer a more monosemantic unit of analysis than the model's neurons themselves. Our approach here builds on a significant amount of prior work, especially in using dictionary learning and related methods on neural network activations (e.g. ), and a more general allied literature on disentanglement. We also note interim reports which independently investigated the sparse autoencoder approach in response to Toy Models, culminating in the recent manuscript of Cunningham et al. . The goal of this paper is to provide a detailed demonstration of a sparse autoencoder compellingly succeeding at the goals of extracting interpretable features from superposition and enabling basic circuit analysis. Concretely, we take a one-layer transformer with a 512-neuron MLP layer, and decompose the MLP activations into relatively interpretable features by training sparse autoencoders on MLP activations from 8 billion data points, with expansion factors ranging from 1× (512 features) to 256× (131,072 features). We focus our detailed interpretability analyses on the 4,096 features learned in one run we call A/1. This report has four major sections. In Problem Setup, we provide motivation for our approach and describe the transformers and sparse autoencoders we train. In Detailed Investigations of Individual Features, we offer an existence proof – we make the case that several features we find are functionally specific causal units which don't correspond to neurons. In Global Analysis, we argue that the typical feature is interpretable and that they explain a non-trivial portion of the MLP layer. Finally, in Phenomenology we describe several properties of our features, including feature-splitting, universality, and how they can form "finite state automata"-like systems implementing interesting behaviors. We also provide three comprehensive visualizations of features. First, for all features from 90 learned dictionaries we present activating dataset examples and downstream logit effects. We recommend the reader begin with the visualization of A/1. Second, we provide a data-oriented view, showing all features active on each token of 25 texts. Finally, we coembed all 4,096 features from A/1 and all 512 features from A/0 into the plane using UMAP to allow for interactive exploration of the space of features: Cluster Feature Cluster #49 A/0/307 This feature fires for references to citations in scientific papers. It attends to the formatting of citations such as brackets, @ symbols, names of authors, dates and labels. Zoom to ↗ View details A/0/311 This feature fires for reference citations in academic papers, specifically when it sees the [@ symbol that is commonly used. Zoom to ↗ View details A/1/776 Years in some citation notation Zoom to ↗ View details A/1/1538 Citations in a [@author] or [@authoryear] format Zoom to ↗ View details A/1/1875 Markdown Citation (Predict year) Zoom to ↗ View details A/1/2252 " [@" Zoom to ↗ View details A/1/2237 [Ultralow density cluster] Zoom to ↗ View details Cluster #42 A/0/126 This feature seems to fire on section headings, specifically the word "sec" within Markdown section tags like {#sec:foo}. Zoom to ↗ View details A/1/357 "ref" in [context] Zoom to ↗ View details A/1/1469 "s"/"sec" after "{#", section reference in some markup Zoom to ↗ View details A/1/3841 "Sec" Zoom to ↗ View details A/1/3898 Section number in {#SecX} Zoom to ↗ View details A/1/4083 " {#" Zoom to ↗ View details A/1/2129 "." in [context] Zoom to ↗ View details A/1/553 "](#" in [context] Zoom to ↗ View details Cluster #43 A/0/8 This feature attends to text formatting markups such as references, figure captions, and table captions. It looks specifically for the "ref-type" attribute in markup tags. Zoom to ↗ View details A/0/398 This feature attends to references to figures and tables. Zoom to ↗ View details A/0/454 This feature fires on reference/bibliographic citations in LaTeX documents. It attends to the braces, "ref" tag, and "type" attribute that are commonly used to define citations. Zoom to ↗ View details A/1/35 "){" Zoom to ↗ View details A/1/366 "type" Zoom to ↗ View details A/1/945 "ref" in [context] Zoom to ↗ View details A/1/1895 "-" in [context] Zoom to ↗ View details A/1/2176 "fig" Zoom to ↗ View details Cluster #46 A/0/425 This feature attends to highlighting bibliography and reference markers in the text such as [1], (Table 1), [@B23], etc. Zoom to ↗ View details A/1/703 This feature attends to bibliographic citations with brackets and @CIT numbers. Zoom to ↗ View details A/1/864 " \\[[@" Zoom to ↗ View details A/1/868 "[@" in bibliography citations Zoom to ↗ View details A/1/2217 ".](" Zoom to ↗ View details A/1/2777 " ([@" in [context] Zoom to ↗ View details A/1/3120 This feature attends to bibliographic citations or references, firing most strongly for formatted citations with brackets, citation keys like [b23] and full references citing authors, titles and dates. Zoom to ↗ View details A/1/3184 Introducing an acaemic reference format Zoom to ↗ View details A/1/3698 "](#" in [context] Zoom to ↗ View details A/1/51 [Ultralow density cluster] Zoom to ↗ View details Cluster #48 A/0/363 The feature attends to in-text citations with URL and DOI links. Zoom to ↗ View details A/0/366 This feature fires on citations and reference markers such as [ ], ( ), etc. Zoom to ↗ View details A/0/396 This feature fires for in-text references, citation links, and reference brackets/notations in scholarly articles, research papers, and academic journals. Zoom to ↗ View details A/1/90 "1" Zoom to ↗ View details A/1/204 "CR" Zoom to ↗ View details A/1/220 This feature attends to formats of references and citations. Zoom to ↗ View details A/1/729 Digits in bibliographies? Zoom to ↗ View details A/1/1015 Reference IDs in parentheses in {} citation format Zoom to ↗ View details A/1/1264 Mostly letter fragments of IDs in parentheses in {} citation format Zoom to ↗ View details A/1/1316 A specific form of medical journal document reference, syntax '{...', specifically the journalid12345-1234 part Zoom to ↗ View details A/1/1440 "g" in [context] Zoom to ↗ View details A/1/1445 "ijms" Zoom to ↗ View details A/1/2200 The feature fires on citation indices in scientific papers, such as [B13-ijms-20-04353-f001]. Zoom to ↗ View details A/1/2280 "bib" in [context] Zoom to ↗ View details A/1/2385 "bib" in some bibliography format ending in "bib-XXXX" where X are digits Zoom to ↗ View details A/1/2496 "B" in [context] Zoom to ↗ View details A/1/2559 [Ultralow density cluster] Zoom to ↗ View details A/1/2696 Numbers/digits in hyphenated IDs in square brackets, likely [@ ... ] citation format Zoom to ↗ View details A/1/2881 "B" in [context] Zoom to ↗ View details A/1/2988 Digits after upper case letters Zoom to ↗ View details A/1/2996 This feature attends to inline citations like [R9] or [@ref9] in scientific papers. Zoom to ↗ View details A/1/3143 This feature seems to fire on citations and references in brackets and parentheses with numbers, IDs and abbreviations. Zoom to ↗ View details A/1/3163 [Ultralow density cluster] Zoom to ↗ View details A/1/3164 Numbers after "pone.", for citation IDs Zoom to ↗ View details A/1/3547 Beginnings of hash locations in Markdown URL targets? Zoom to ↗ View details A/1/3949 "pone" Zoom to ↗ View details A/1/4062 Post-"#" numeric ID fragments in parentheses in {} citation format Zoom to ↗ View details A/0/270 This feature fires on reference links to articles, papers, and datasets in academic writing. These references links are typically in a specific format like text or with abbreviated journal titles and citation numbers like [B14-sensors-19-00441]. Zoom to ↗ View details Cluster #36 A/0/277 The feature fires when it sees short HTML/XML tags such as <ref-type="fig"> Zoom to ↗ View details A/0/427 This feature appears to fire on hyphens between numbers, especially years. Zoom to ↗ View details A/1/367 "="" in [context] Zoom to ↗ View details A/1/747 "-" in [context] Zoom to ↗ View details A/1/1220 "-" in [context] Zoom to ↗ View details A/1/1782 "-" in [context] Zoom to ↗ View details A/1/2324 "="" in [context] Zoom to ↗ View details A/1/2876 "-" in [context] Zoom to ↗ View details A/1/3122 "-" for dashes within journal citations? Zoom to ↗ View details A/1/774 [Ultralow density cluster] Zoom to ↗ View details A/1/3838 " @" in [context] Zoom to ↗ View details A/1/1415 "),", sometimes with more leading punctuation, in scientific contexts Zoom to ↗ View details A/1/3877 "," in [context] Zoom to ↗ View details Cluster #124 A/1/1147 "," in [context] Zoom to ↗ View details A/1/2930 "," in [context] Zoom to ↗ View details A/1/3857 "," in [context] Zoom to ↗ View details Cluster #127 A/0/359 This feature fires when it sees the punctuation mark comma "," Zoom to ↗ View details A/1/178 "," in mechanical engineering? Zoom to ↗ View details A/1/713 "," after "However" or "by contrast" type phrases Zoom to ↗ View details A/1/1204 This feature attends to commas used as enumerators in scientific texts. Zoom to ↗ View details A/1/1374 "," in lists of chemicals Zoom to ↗ View details A/1/1565 "]," Zoom to ↗ View details A/1/1801 "," between demographic factors Zoom to ↗ View details A/1/2284 "," in [context] Zoom to ↗ View details A/1/2835 "," in [context] Zoom to ↗ View details A/1/3482 ";" in [context] Zoom to ↗ View details A/1/3921 ";" in [context] Zoom to ↗ View details Cluster #37 A/0/289 This feature attends to parentheses and other bracket notations. Zoom to ↗ View details A/1/1785 This feature attends to closing parentheses. Zoom to ↗ View details A/1/1885 ")" in biomedical studies Zoom to ↗ View details A/1/3672 . The "]" at the end of each reference code Zoom to ↗ View details A/1/715 "," after an adverb indicating a conclusion from something previous, e.g. "Finally" Zoom to ↗ View details A/0/231 The feature attends to the word "in" followed by a comma and appearing at the beginning of a sentence. Zoom to ↗ View details Cluster #142 A/0/430 This feature fires when a comma is present. Zoom to ↗ View details A/1/1284 "," in [context] Zoom to ↗ View details A/1/1479 "," in [context] Zoom to ↗ View details A/1/2409 "," in [context] Zoom to ↗ View details A/1/3342 "," in lists, mostly of short nouns/phrases Zoom to ↗ View details A/1/3411 "," in [context] Zoom to ↗ View details Cluster #10 A/0/128 This feature appears to attend to proper nouns and named entities in text, especially names of people, organizations, locations, and creative works. Zoom to ↗ View details A/1/626 [Ultralow density cluster] Zoom to ↗ View details A/1/1366 Sports, esp. Title Case names of competitions Zoom to ↗ View details A/1/1860 [Ultralow density cluster] Zoom to ↗ View details A/1/2731 " the" in sports (football?) Zoom to ↗ View details A/1/2784 American sports concepts: offensive/defensive lines and defensive/tackle, right-handed bat, three-pointer, starter, drills Zoom to ↗ View details A/1/3316 Professional sports Zoom to ↗ View details A/1/3336 1- to 2-digit numbers in sports contexts, esp. scores Zoom to ↗ View details A/1/3856 " with" in sports contexts Zoom to ↗ View details A/1/993 "," in [context] Zoom to ↗ View details A/1/1814 "," in [context] Zoom to ↗ View details A/1/757 Commas after conjunctions at starts of sentences or connecting clauses Zoom to ↗ View details Cluster #143 A/1/586 Commas in discussions of military battles Zoom to ↗ View details A/1/658 This feature fires when there is a comma used in the middle or end of a sentence. Zoom to ↗ View details A/1/1327 This feature appears to fire when there is a comma followed by a word starting with a vowel. Zoom to ↗ View details A/1/1389 Comma after an "if" clause Zoom to ↗ View details A/1/3754 "," in [context] Zoom to ↗ View details A/1/3160 "," in [context] Zoom to ↗ View details Cluster #6 A/0/75 This feature fires when it encounters the word "and" or the word "or" being used as conjunctions. Zoom to ↗ View details A/0/214 The feature fires when it sees the word 'and'. Zoom to ↗ View details A/0/403 The feature fires for sentences that have a comma separating two phrases, clauses or lists, or the words "or", "and", "but". Zoom to ↗ View details A/1/33 " and" in [context] Zoom to ↗ View details A/1/56 Code: " and"/" or" in comments about data Zoom to ↗ View details A/1/87 " and" after country names and other geographical locations Zoom to ↗ View details A/1/92 " and" in [context] Zoom to ↗ View details A/1/310 "and" conjoining family members Zoom to ↗ View details A/1/324 " and" after a full (first+last) name Zoom to ↗ View details A/1/337 This feature attends to coordinating conjunctions such as "and" and "or". Zoom to ↗ View details A/1/391 " and" in U.S. history or geography Zoom to ↗ View details A/1/406 " and" in [context] Zoom to ↗ View details A/1/524 " or" joining number words or similar, e.g. "one or two" or "one or more" Zoom to ↗ View details A/1/603 "and" in chemistry text Zoom to ↗ View details A/1/783 [Ultralow density cluster] Zoom to ↗ View details A/1/802 " or" in [context] Zoom to ↗ View details A/1/822 [Ultralow density cluster] Zoom to ↗ View details A/1/843 " and" in recipes Zoom to ↗ View details A/1/1000 " and" and other conjunctions in computing text Zoom to ↗ View details A/1/1074 " and" in [context] Zoom to ↗ View details A/1/1137 " and" shortly after EOT Zoom to ↗ View details A/1/1211 " and" in [context] Zoom to ↗ View details A/1/1249 " and" scientific Zoom to ↗ View details A/1/1274 " and" in [context] Zoom to ↗ View details A/1/1349 " and" in [context] Zoom to ↗ View details A/1/1386 " and" in [context] Zoom to ↗ View details A/1/1431 " or" in [context] Zoom to ↗ View details A/1/1495 " and" in [context] Zoom to ↗ View details A/1/1851 " and" in [context] Zoom to ↗ View details A/1/1882 " and" in [context] Zoom to ↗ View details A/1/1934 " and" after an emotion, predicting another emotion Zoom to ↗ View details A/1/1949 " and" in [context] Zoom to ↗ View details A/1/2058 " &" in [context] Zoom to ↗ View details A/1/2117 "and" Zoom to ↗ View details A/1/2208 " and"/" or", after a number and time interval (e.g. "six months") and predicting another time interval Zoom to ↗ View details A/1/2251 " and" in [context] Zoom to ↗ View details A/1/2272 " and" and conjunctions in demography or population surveys Zoom to ↗ View details A/1/2356 " and" in [context] Zoom to ↗ View details A/1/2419 " and" after groups of people, predicting other groups of people Zoom to ↗ View details A/1/2428 " and" in [context] Zoom to ↗ View details A/1/2431 " and" in [context] Zoom to ↗ View details A/1/2520 " and" in [context] Zoom to ↗ View details A/1/2585 " and" in [context] Zoom to ↗ View details A/1/2597 " and" in [context] Zoom to ↗ View details A/1/2612 " and" in [context] Zoom to ↗ View details A/1/2623 " and" in [context] Zoom to ↗ View details A/1/2679 " and" in [context] Zoom to ↗ View details A/1/2747 "and" in context of color descriptions of objects Zoom to ↗ View details A/1/2849 " or" in [context] Zoom to ↗ View details A/1/2860 The feature fires when words like "or", "and", "to", or punctuation like "," appear. Zoom to ↗ View details A/1/2884 " and" in [context] Zoom to ↗ View details A/1/3042 " and" in [context] Zoom to ↗ View details A/1/3106 " and" in [context] Zoom to ↗ View details A/1/3142 'or' in 'and/or' Zoom to ↗ View details A/1/3196 " and" in [context] Zoom to ↗ View details A/1/3217 " and" in [context] Zoom to ↗ View details A/1/3220 " and"/" or" after an abbreviation, predicting another abbreviation Zoom to ↗ View details A/1/3232 " and"/" or" largely in all-lowercase contexts like chat logs Zoom to ↗ View details A/1/3244 " and" in [context] Zoom to ↗ View details A/1/3454 " and" in [context] Zoom to ↗ View details A/1/3486 " and"/" or" after and predicting adjectives like "economic" or "medical" Zoom to ↗ View details A/1/3618 " and" in [context] Zoom to ↗ View details A/1/3671 [Ultralow density cluster] Zoom to ↗ View details A/1/3757 " and" in [context] Zoom to ↗ View details A/1/3790 This feature fires for sentences that contain the word "and". Zoom to ↗ View details A/1/3875 "and" conjunction predicting a past-tense verb Zoom to ↗ View details A/1/3906 " and" in [context] Zoom to ↗ View details A/1/3983 " and" and sometimes " or" in medical/anatomical contexts Zoom to ↗ View details A/1/2611 "," in [context] Zoom to ↗ View details Cluster #147 A/0/310 This feature fires when there is a comma followed by a space. Zoom to ↗ View details A/1/2367 "," in [context] Zoom to ↗ View details A/1/3376 "," in [context] Zoom to ↗ View details A/1/3595 This feature seems to attend to punctuation, specifically commas. It fires highest for commas and has a secondary activation for other types of punctuation like exclamation points and semicolons. Zoom to ↗ View details A/1/3634 "," in [context] Zoom to ↗ View details A/1/3995 "," in [context] Zoom to ↗ View details A/1/3506 Commas near beginning of quoted English text Zoom to ↗ View details A/1/3966 Adjective describing a famous person (occupation or nationality) Zoom to ↗ View details Cluster #146 A/0/504 This feature seems to fire when there is a comma followed by the word "and". Zoom to ↗ View details A/1/814 "," in [context] Zoom to ↗ View details A/1/1059 "," in [context] Zoom to ↗ View details A/1/1116 ',' comma in archaic english Zoom to ↗ View details A/1/1988 "," in [context] Zoom to ↗ View details A/1/2925 Female - she / her / herself ... ? Zoom to ↗ View details A/1/2390 ";" in [context] Zoom to ↗ View details A/1/1928 "," in [context] Zoom to ↗ View details A/1/382 "," in sports reporting, particularly after "season" / units of time Zoom to ↗ View details A/1/3897 "," in [context] Zoom to ↗ View details Cluster #105 A/0/123 This feature fires when a name is followed by a comma. Zoom to ↗ View details A/1/739 Comma after a work of art (performance, album, book) Zoom to ↗ View details A/1/1081 "," separating full names in lists Zoom to ↗ View details A/1/1238 Commas in lists of countries Zoom to ↗ View details A/1/1631 "," in [context] Zoom to ↗ View details A/1/1828 "," after scientific institutions Zoom to ↗ View details A/1/2007 [Ultralow density cluster] Zoom to ↗ View details A/1/2397 "," in [context] Zoom to ↗ View details A/1/2964 Commas in European history Zoom to ↗ View details A/1/3459 [Ultralow density cluster] Zoom to ↗ View details A/1/1365 The feature fires when it sees quotation marks with text followed by punctuation such as a comma or period. Zoom to ↗ View details A/1/657 "," in [context] Zoom to ↗ View details Cluster #84 A/1/331 "," in legal contexts? Zoom to ↗ View details A/1/673 "," after/between years Zoom to ↗ View details A/1/1864 "," in [context] Zoom to ↗ View details Cluster #80 A/0/6 The feature fires when it sees punctuation like commas, semicolons and periods, especially when they follow a word that ends with a lowercase letter. Zoom to ↗ View details A/1/1066 "," in [context] Zoom to ↗ View details A/1/1152 "," in [context] Zoom to ↗ View details A/1/3394 This feature fires when it sees a semicolon (;) followed by a parenthetical citation with a 4 digit date. Zoom to ↗ View details A/1/3697 "," in [context] Zoom to ↗ View details A/1/1692 "," in [context] Zoom to ↗ View details A/1/2893 Commas in thousands-place separators (patent numbers?) Zoom to ↗ View details Cluster #57 A/1/1406 ".," in [context] Zoom to ↗ View details A/1/2622 "," after physicist last names, predicting " Phys" Zoom to ↗ View details A/1/2767 Commas in citations Zoom to ↗ View details Cluster #73 A/0/240 This feature attends to numbers from 1 to 99,999 preceded or followed by commas. Zoom to ↗ View details A/1/32 "," after small numbers in sequences Zoom to ↗ View details A/1/2014 Commas separating numbers (with spaces) Zoom to ↗ View details A/1/2209 "," in numbers Zoom to ↗ View details Cluster #83 A/1/546 Commas, often in book titles or preceding them to delimit the author Zoom to ↗ View details A/1/2690 "]" in [context] Zoom to ↗ View details A/1/3653 ")" in legal documents Zoom to ↗ View details A/1/4051 Korean: ? Zoom to ↗ View details Cluster #7 A/0/48 This feature fires when it sees Greek text, specifically Ancient Greek. Zoom to ↗ View details A/1/572 Greek: ? Zoom to ↗ View details A/1/634 Greek: "ι"? Zoom to ↗ View details A/1/1586 Khmer, Amharic, (Greek?): ? Zoom to ↗ View details A/1/2599 Greek: Capital letters? Zoom to ↗ View details A/1/3453 Greek: nu, chi Zoom to ↗ View details A/1/3831 Greek: Vowel, especially omicron and upsilon Zoom to ↗ View details Cluster #13 A/0/66 This feature fires when it sees foreign characters such as accented characters, Cyrillic and Greek characters. Zoom to ↗ View details A/0/79 This feature seems to fire on mathematical fractions, degrees symbols, and other symbols commonly used in math and science writing. Zoom to ↗ View details A/0/80 This feature fires on Greek text. Zoom to ↗ View details A/0/101 This feature seems to fire for characters and scripts that are not Latin-based. Some examples where it has high activation include Georgian, Japanese, Chinese, Korean, Greek, Cyrillic, and Thai characters. Zoom to ↗ View details A/0/290 This feature attends to non-Latin alphabet languages such as Thai, Tamil, Georgian, Hindi, Japanese, Arabic, etc. Zoom to ↗ View details A/1/0 Japanese, Chinese, other Asian scripts: Interwoven in English Zoom to ↗ View details A/1/78 Japanese: "\xe9"? Zoom to ↗ View details A/1/281 Greek?: "\\xe1" Zoom to ↗ View details A/1/422 Thai: Unicode prefix "\xe0\xb8", after vowel Zoom to ↗ View details A/1/426 Start of Unicode character esp. predicting \x95 in U+2215 HORIZONTAL BAR Zoom to ↗ View details A/1/432 "\xc3" in UTF-8 as latin1 mojibake, esp. of Russian Zoom to ↗ View details A/1/558 "\\xce" in [context] Zoom to ↗ View details A/1/589 "\\xe0\\xa4" Zoom to ↗ View details A/1/619 "\\xe1\\xbb" Zoom to ↗ View details A/1/641 Japanese: beginnings of characters? Zoom to ↗ View details A/1/795 Arabic: Unicode start "\xd9" Zoom to ↗ View details A/1/870 Japanese: ? Zoom to ↗ View details A/1/903 "\\xce" in [context] Zoom to ↗ View details A/1/934 Japanese: "\xe8\xa6"? Zoom to ↗ View details A/1/1009 " \\xce" Zoom to ↗ View details A/1/1016 Hebrew, Arabic, Farsi: Unicode block "\xd7"? Zoom to ↗ View details A/1/1096 [Ultralow density cluster] Zoom to ↗ View details A/1/1163 Telugu?: ? Zoom to ↗ View details A/1/1193 Japanese: "\\xe3\\x82"? Zoom to ↗ View details A/1/1232 Math (Incomplete Unicode) Zoom to ↗ View details A/1/1235 \xc2 in UTF-8 as latin1 mojibake of Korean? Zoom to ↗ View details A/1/1345 "\xc3" in UTF-8 as latin1 mojibake of Arabic? Zoom to ↗ View details A/1/1369 Bengali: Unicode sequence start Zoom to ↗ View details A/1/1499 "\\xc4" in [context] Zoom to ↗ View details A/1/1724 Georgian and Korean?: "\xe1\x83" Zoom to ↗ View details A/1/1820 South Asian scripts: Unicode start Zoom to ↗ View details A/1/1904 Japanese: Katakana "extend the previous vowel sound for longer" partial-uniocde character Zoom to ↗ View details A/1/1940 Japanese: beginnings of kanji Zoom to ↗ View details A/1/2012 "\\xcf" in [context] Zoom to ↗ View details A/1/2152 Japanese: Beginnings of kanji Zoom to ↗ View details A/1/2399 Japanese, Chinese: "\xe6\xa5"? Zoom to ↗ View details A/1/2453 Japanese: "\xe9\x9a"? Zoom to ↗ View details A/1/2465 Armenian: "\xd5" Zoom to ↗ View details A/1/2466 \xc2 as UTF-8 as latin1 mojibake of Chinese? Zoom to ↗ View details A/1/2472 Vietnamese (Thai?): "\xe1\xba" Zoom to ↗ View details A/1/2556 Japanese, Chinese, other Asian scripts: Unicode Start \xe6\xb0? Zoom to ↗ View details A/1/2563 Thai: Unicode prefix "\xe0\xb9" Zoom to ↗ View details A/1/2608 "\\xce" in [context] Zoom to ↗ View details A/1/2617 Chinese and Japanese: beginnings of characters Zoom to ↗ View details A/1/2618 Japanese: Hiragana unicode character byte-prefix (predicting the postfix) Zoom to ↗ View details A/1/2636 \xc2 in UTF-8 as latin1 mojibake of Korean? Zoom to ↗ View details A/1/2725 \xc2 in UTF-8 as latin1 mojibake of Chinese? Zoom to ↗ View details A/1/2736 Japanese and Chinese: "\xe5\x88" Zoom to ↗ View details A/1/2745 \xc2 in UTF-8 as latin1 mojibake of Chinese? Zoom to ↗ View details A/1/2782 Japanese: "\\xe3\\x83" Zoom to ↗ View details A/1/2798 \xc2 (Unicode starter of Unicode continuation) in UTF-8 as latin1 mojibake of Russian? Zoom to ↗ View details A/1/2852 " \\xcf" Zoom to ↗ View details A/1/2919 " \\xe0\\xa4" Zoom to ↗ View details A/1/2957 Unicode start codes for combining accents Zoom to ↗ View details A/1/3006 Emoji? / mid-Unicode bytes Zoom to ↗ View details A/1/3133 Hebrew: "\xd6"? Zoom to ↗ View details A/1/3150 "\\xc5" Zoom to ↗ View details A/1/3345 Gujarati: ? Zoom to ↗ View details A/1/3368 Japanese and other Asian languages: "\xe9\x80"? Zoom to ↗ View details A/1/3399 Arabic: Unicode start "\xd8"? Zoom to ↗ View details A/1/3468 Japanese, Chinese, and Korean: "\\xe7"? Zoom to ↗ View details A/1/3561 Thai: unicode prefix "\xe0\xb8" Zoom to ↗ View details A/1/3687 Georgian (Unicode Start) Zoom to ↗ View details A/1/3692 Hebrew: Unicode Block " \xd7"? Zoom to ↗ View details A/1/3726 "\xc2" in UTF-8 as latin1 mojibake of Chinese? Zoom to ↗ View details A/1/3748 " \xcc" in mojibake? Zoom to ↗ View details A/1/3785 Japanese: "\xe6\x8a"? Zoom to ↗ View details A/1/3815 Chinese and Japanese: Beginnings of characters, vaguely poetic? Zoom to ↗ View details A/1/3907 Arabic: Unicode start " \xd8"? Zoom to ↗ View details A/1/3908 " \xc3" in UTF-8 as latin1 mojibake of Korean? (beginnings of chat logs?) Zoom to ↗ View details A/1/3967 Japanese: "\xe7\x9b"? Zoom to ↗ View details A/1/4004 Japanese: "\xe8\xaa"? Zoom to ↗ View details A/1/4050 Greek: ? Zoom to ↗ View details A/1/522 Tamil: Unicode start Zoom to ↗ View details A/1/1280 Greek: ? Zoom to ↗ View details A/1/3119 Czech, Lithuanian, Tamil: Unicode code point start Zoom to ↗ View details Cluster #17 A/0/435 The feature fires when it sees text written in South Indian languages such as Tamil, Telugu, Malayalam, and Kannada. Zoom to ↗ View details A/1/416 Hebrew: Unicode end Zoom to ↗ View details A/1/466 Sinhala: ? Zoom to ↗ View details A/1/480 Armenian: Unicode end Zoom to ↗ View details A/1/580 Georgian: ? Zoom to ↗ View details A/1/994 Georgian: ? Zoom to ↗ View details A/1/1287 Bengali: Unicode end Zoom to ↗ View details A/1/1900 Punjabi: ? Zoom to ↗ View details A/1/2499 Tamil: Unicode end Zoom to ↗ View details A/1/2586 Hindi: ? Zoom to ↗ View details A/1/2629 Bengali, Thai, Tamil, Lao?: ? Zoom to ↗ View details A/1/2790 Devanagari (Hindi?): ? Zoom to ↗ View details A/1/2796 Devanagari, Tamil, Telugu, Malayalam, and Thai: Unicode end Zoom to ↗ View details Cluster #4 A/0/17 The feature fires on non-ascii and special characters. Zoom to ↗ View details A/1/873 UTF-8 as latin1 mojibake of Chinese? Zoom to ↗ View details A/1/980 Euro sign etc. in mojibake: UTF-8 as latin1 of quotes, U+201x Zoom to ↗ View details A/1/1049 UTF-8 as latin1 mojibake of Chinese? Zoom to ↗ View details A/1/1411 "ä" U+00E4 in UTF-8 as latin1 mojibake, esp. of Chinese Zoom to ↗ View details A/1/1517 "\x91" in UTF-8 as latin1 mojibake, esp. of Russian Zoom to ↗ View details A/1/1635 "\\x90" UTF-8 as latin1 mojibake of Russian? Zoom to ↗ View details A/1/2387 UTF-8 as latin1 mojibake of Korean? Zoom to ↗ View details A/1/3041 Particularly nasty mojibake (latin1, Windows-1252, Mac Roman; possibly iterated multiple times) Zoom to ↗ View details A/1/3440 "Ã" U+00C3 in two-character mojibake, broadly accented characters in European languages Zoom to ↗ View details A/1/3914 UTF-8 as latin1 mojibake of Chinese? Zoom to ↗ View details A/1/3961 Some Cyrillic script? Unicode starters in UTF-8 as latin1 mojibake, extra cursed by normalization Zoom to ↗ View details A/1/1691 Korean: " \\xed"/"\\xed" Zoom to ↗ View details Cluster #15 A/0/319 The feature attends to Korean text. Zoom to ↗ View details A/1/1184 Korean: ? Zoom to ↗ View details A/1/2323 Arabic, Korean, Chinese, Japanese, Russian, Norwegian, et al.: ? Zoom to ↗ View details A/1/2955 Korean: ? Zoom to ↗ View details Cluster #18 A/0/459 The feature appears to activate for text written in right-to-left languages such as Arabic, Persian, and Hebrew. Zoom to ↗ View details A/1/1271 Arabic script: Whitespace Zoom to ↗ View details A/1/1466 Arabic script (Urdu?): ? Zoom to ↗ View details A/1/1706 Thai: (Unicode Sequence Complete) Zoom to ↗ View details A/1/3134 Arabic script: ? Zoom to ↗ View details A/1/3450 Arabic script: ? Zoom to ↗ View details Cluster #20 A/1/207 Turkic family?: languages in Cyrillic script Zoom to ↗ View details A/1/1197 Russian: " \u0441" Zoom to ↗ View details A/1/1858 Russian: ? Zoom to ↗ View details A/1/2363 Russian: in (conjunction and verbal prefix) Zoom to ↗ View details A/1/2459 Russian: word-ends? Zoom to ↗ View details A/1/766 Russian: ? Zoom to ↗ View details Cluster #14 A/0/98 This feature attends to Russian words related to action verbs, especially those ending in -ть. Zoom to ↗ View details A/0/413 This feature attends to Russian grammatical features like verb conjugations and declensions. Zoom to ↗ View details A/1/3181 Russian: Prefix in verbs / nouns Zoom to ↗ View details A/1/3061 Russian: Beginnings of quotes Zoom to ↗ View details A/1/2664 Russian: " \u0443" Zoom to ↗ View details Cluster #19 A/1/24 Russian: "и" ? Zoom to ↗ View details A/1/1473 Russian: " Т" / " т" Zoom to ↗ View details A/1/1964 Russian: " \u0437" Zoom to ↗ View details A/1/2557 Russian?: The common "-ция" suffix indicates that the word is a noun Zoom to ↗ View details A/1/3073 Russian: л and к characters? Zoom to ↗ View details A/1/3415 Russian: Mostly letter "е" Zoom to ↗ View details A/1/3553 Russian: " \u0434" Zoom to ↗ View details A/1/4095 Russian: " п" Zoom to ↗ View details A/0/130 This feature fires when it sees contractions with "I'm" or "I am", especially at the beginning of sentences or quotes. Zoom to ↗ View details A/1/225 [Ultralow density cluster] Zoom to ↗ View details A/1/1002 " am" after "I", in context of subjective experience Zoom to ↗ View details A/1/983 " im" Zoom to ↗ View details Cluster #31 A/0/55 This feature fires when the words "was" or "were" have a high activation value. Zoom to ↗ View details A/0/164 This feature fires when the token "is" is present. Zoom to ↗ View details A/0/272 This feature fires when the phrase "be _" (with some variation) is present. Zoom to ↗ View details A/1/4 " was", esp. after "he"/"she"/a name, predicting an adjective Zoom to ↗ View details A/1/111 " is" in [context] Zoom to ↗ View details A/1/253 " be" after auxiliary verbs like "must"/"may", sometimes also with "not" Zoom to ↗ View details A/1/517 " is" in [context] Zoom to ↗ View details A/1/797 " be" in [context] Zoom to ↗ View details A/1/885 " is" in [context] Zoom to ↗ View details A/1/1095 " is" in [context] Zoom to ↗ View details A/1/1378 The feature fires when the third-person singular present-tense "is" follows a noun phrase with an embedded clause, often signaling that a fact or argument is being stated. Zoom to ↗ View details A/1/1521 " been" in [context] Zoom to ↗ View details A/1/1750 " become"/" becoming" Zoom to ↗ View details A/1/2049 " is" in [context] Zoom to ↗ View details A/1/2076 This feature fires when a verb in the past tense follows "was" or "were". Zoom to ↗ View details A/1/2131 " was" in [context] Zoom to ↗ View details A/1/2188 " is" in [context] Zoom to ↗ View details A/1/2325 " is" in [context] Zoom to ↗ View details A/1/2481 "al" - logit nonsense Zoom to ↗ View details A/1/2755 " is" in [context] Zoom to ↗ View details A/1/3015 " is" in [context] Zoom to ↗ View details A/1/3063 " be" in [context] Zoom to ↗ View details A/1/3161 " are" in [context] Zoom to ↗ View details A/1/3535 " is" / other copulae, esp after <EOT> Zoom to ↗ View details A/1/3558 " be" in [context] Zoom to ↗ View details A/1/3910 " was" in [context] Zoom to ↗ View details A/1/3982 " being" Zoom to ↗ View details A/1/2560 " remain" Zoom to ↗ View details Cluster #32 A/0/295 This feature fires when the token "was" appears in the text. Zoom to ↗ View details A/1/1001 Copulas (mostly " is") in technical text Zoom to ↗ View details A/1/1146 " is" in [context] Zoom to ↗ View details A/1/1426 " is" in [context] Zoom to ↗ View details A/1/1463 " be" in [context] Zoom to ↗ View details A/1/1648 " is" in [context] Zoom to ↗ View details A/1/1787 " are" in [context] Zoom to ↗ View details A/1/2307 [Ultralow density cluster] Zoom to ↗ View details A/1/2341 " been" in scientific manuscripts (shown, demonstrated, proposed) Zoom to ↗ View details A/1/2539 " was"/" were" in biomedical studies Zoom to ↗ View details A/1/2542 " was"/" were" in medical contexts? Zoom to ↗ View details A/1/2844 " be" in [context] Zoom to ↗ View details A/1/3339 " is" in [context] Zoom to ↗ View details A/1/1223 "'m" Zoom to ↗ View details A/1/138 ',"' or ",'" concluding what somebody said Zoom to ↗ View details A/1/2561 "."" in [context] Zoom to ↗ View details A/1/2591 [Ultralow density cluster] Zoom to ↗ View details A/0/334 The feature fires for the period (.) character followed by quotation marks ("). Zoom to ↗ View details Cluster #115 A/0/47 The feature detects the use of quotation marks as it activates whenever it encounters paired single or double quotation marks. Zoom to ↗ View details A/1/1203 "."" in [context] Zoom to ↗ View details A/1/2346 "."" in [context] Zoom to ↗ View details A/1/2816 Closing punctuation+quote esp in series of quotes with no unquoted text Zoom to ↗ View details A/1/3421 "."" in [context] Zoom to ↗ View details A/1/2001 This feature fires when sentences end in question marks or exclamation points. Zoom to ↗ View details A/1/311 ".”" (period + smart close quote) Zoom to ↗ View details Cluster #114 A/0/200 The feature seems to fire the most when a sentence ends with a period. Zoom to ↗ View details A/1/170 "." in sports discussion Zoom to ↗ View details A/1/1497 "." in [context] Zoom to ↗ View details A/1/2230 ".'" Zoom to ↗ View details A/1/3932 "." in [context] Zoom to ↗ View details A/1/3968 "." in [context] Zoom to ↗ View details Cluster #0 A/0/25 Zoom to ↗ View details A/0/89 Zoom to ↗ View details A/0/120 Zoom to ↗ View details A/0/124 Zoom to ↗ View details A/0/208 Zoom to ↗ View details A/0/299 Zoom to ↗ View details A/0/309 Zoom to ↗ View details A/0/336 Zoom to ↗ View details A/0/467 Zoom to ↗ View details A/1/31 [Ultralow density cluster] Zoom to ↗ View details A/1/37 [Ultralow density cluster] Zoom to ↗ View details A/1/57 [Ultralow density cluster] Zoom to ↗ View details A/1/79 [Ultralow density cluster] Zoom to ↗ View details A/1/82 [Ultralow density cluster] Zoom to ↗ View details A/1/95 [Ultralow density cluster] Zoom to ↗ View details A/1/122 [Ultralow density cluster] Zoom to ↗ View details A/1/131 [Ultralow density cluster] Zoom to ↗ View details A/1/135 [Ultralow density cluster] Zoom to ↗ View details A/1/168 [Ultralow density cluster] Zoom to ↗ View details A/1/188 [Ultralow density cluster] Zoom to ↗ View details A/1/190 [Ultralow density cluster] Zoom to ↗ View details A/1/191 [Ultralow density cluster] Zoom to ↗ View details A/1/214 [Ultralow density cluster] Zoom to ↗ View details A/1/217 [Ultralow density cluster] Zoom to ↗ View details A/1/223 [Ultralow density cluster] Zoom to ↗ View details A/1/227 [Ultralow density cluster] Zoom to ↗ View details A/1/238 [Ultralow density cluster] Zoom to ↗ View details A/1/240 [Ultralow density cluster] Zoom to ↗ View details A/1/242 [Ultralow density cluster] Zoom to ↗ View details A/1/250 [Ultralow density cluster] Zoom to ↗ View details A/1/260 [Ultralow density cluster] Zoom to ↗ View details A/1/266 [Ultralow density cluster] Zoom to ↗ View details A/1/286 [Ultralow density cluster] Zoom to ↗ View details A/1/288 [Ultralow density cluster] Zoom to ↗ View details A/1/298 [Ultralow density cluster] Zoom to ↗ View details A/1/299 [Ultralow density cluster] Zoom to ↗ View details A/1/309 [Ultralow density cluster] Zoom to ↗ View details A/1/312 [Ultralow density cluster] Zoom to ↗ View details A/1/318 [Ultralow density cluster] Zoom to ↗ View details A/1/325 [Ultralow density cluster] Zoom to ↗ View details A/1/354 [Ultralow density cluster] Zoom to ↗ View details A/1/361 [Ultralow density cluster] Zoom to ↗ View details A/1/368 [Ultralow density cluster] Zoom to ↗ View details A/1/383 [Ultralow density cluster] Zoom to ↗ View details A/1/387 [Ultralow density cluster] Zoom to ↗ View details A/1/401 [Ultralow density cluster] Zoom to ↗ View details A/1/414 [Ultralow density cluster] Zoom to ↗ View details A/1/428 [Ultralow density cluster] Zoom to ↗ View details A/1/433 [Ultralow density cluster] Zoom to ↗ View details A/1/440 [Ultralow density cluster] Zoom to ↗ View details A/1/446 [Ultralow density cluster] Zoom to ↗ View details A/1/448 [Ultralow density cluster] Zoom to ↗ View details A/1/459 [Ultralow density cluster] Zoom to ↗ View details A/1/468 [Ultralow density cluster] Zoom to ↗ View details A/1/490 [Ultralow density cluster] Zoom to ↗ View details A/1/504 [Ultralow density cluster] Zoom to ↗ View details A/1/518 [Ultralow density cluster] Zoom to ↗ View details A/1/562 [Ultralow density cluster] Zoom to ↗ View details A/1/568 [Ultralow density cluster] Zoom to ↗ View details A/1/574 [Ultralow density cluster] Zoom to ↗ View details A/1/581 [Ultralow density cluster] Zoom to ↗ View details A/1/602 [Ultralow density cluster] Zoom to ↗ View details A/1/637 [Ultralow density cluster] Zoom to ↗ View details A/1/659 [Ultralow density cluster] Zoom to ↗ View details A/1/670 [Ultralow density cluster] Zoom to ↗ View details A/1/695 [Ultralow density cluster] Zoom to ↗ View details A/1/710 [Ultralow density cluster] Zoom to ↗ View details A/1/719 [Ultralow density cluster] Zoom to ↗ View details A/1/742 [Ultralow density cluster] Zoom to ↗ View details A/1/779 [Ultralow density cluster] Zoom to ↗ View details A/1/793 [Ultralow density cluster] Zoom to ↗ View details A/1/801 [Ultralow density cluster] Zoom to ↗ View details A/1/886 [Ultralow density cluster] Zoom to ↗ View details A/1/892 [Ultralow density cluster] Zoom to ↗ View details A/1/926 [Ultralow density cluster] Zoom to ↗ View details A/1/950 [Ultralow density cluster] Zoom to ↗ View details A/1/966 [Ultralow density cluster] Zoom to ↗ View details A/1/977 [Ultralow density cluster] Zoom to ↗ View details A/1/987 [Ultralow density cluster] Zoom to ↗ View details A/1/992 [Ultralow density cluster] Zoom to ↗ View details A/1/1006 [Ultralow density cluster] Zoom to ↗ View details A/1/1011 [Ultralow density cluster] Zoom to ↗ View details A/1/1018 [Ultralow density cluster] Zoom to ↗ View details A/1/1048 [Ultralow density cluster] Zoom to ↗ View details A/1/1058 [Ultralow density cluster] Zoom to ↗ View details A/1/1071 [Ultralow density cluster] Zoom to ↗ View details A/1/1072 [Ultralow density cluster] Zoom to ↗ View details A/1/1097 [Ultralow density cluster] Zoom to ↗ View details A/1/1109 [Ultralow density cluster] Zoom to ↗ View details A/1/1118 [Ultralow density cluster] Zoom to ↗ View details A/1/1121 [Ultralow density cluster] Zoom to ↗ View details A/1/1151 [Ultralow density cluster] Zoom to ↗ View details A/1/1158 [Ultralow density cluster] Zoom to ↗ View details A/1/1161 [Ultralow density cluster] Zoom to ↗ View details A/1/1170 [Ultralow density cluster] Zoom to ↗ View details A/1/1217 [Ultralow density cluster] Zoom to ↗ View details A/1/1221 [Ultralow density cluster] Zoom to ↗ View details A/1/1228 [Ultralow density cluster] Zoom to ↗ View details A/1/1247 [Ultralow density cluster] Zoom to ↗ View details A/1/1252 [Ultralow density cluster] Zoom to ↗ View details A/1/1257 [Ultralow density cluster] Zoom to ↗ View details A/1/1265 [Ultralow density cluster] Zoom to ↗ View details A/1/1267 [Ultralow density cluster] Zoom to ↗ View details A/1/1289 [Ultralow density cluster] Zoom to ↗ View details A/1/1290 [Ultralow density cluster] Zoom to ↗ View details A/1/1294 [Ultralow density cluster] Zoom to ↗ View details A/1/1324 [Ultralow density cluster] Zoom to ↗ View details A/1/1331 [Ultralow density cluster] Zoom to ↗ View details A/1/1336 [Ultralow density cluster] Zoom to ↗ View details A/1/1341 [Ultralow density cluster] Zoom to ↗ View details A/1/1356 [Ultralow density cluster] Zoom to ↗ View details A/1/1370 [Ultralow density cluster] Zoom to ↗ View details A/1/1393 [Ultralow density cluster] Zoom to ↗ View details A/1/1402 [Ultralow density cluster] Zoom to ↗ View details A/1/1407 [Ultralow density cluster] Zoom to ↗ View details A/1/1421 [Ultralow density cluster] Zoom to ↗ View details A/1/1427 [Ultralow density cluster] Zoom to ↗ View details A/1/1468 [Ultralow density cluster] Zoom to ↗ View details A/1/1486 [Ultralow density cluster] Zoom to ↗ View details A/1/1492 [Ultralow density cluster] Zoom to ↗ View details A/1/1504 [Ultralow density cluster] Zoom to ↗ View details A/1/1516 [Ultralow density cluster] Zoom to ↗ View details A/1/1523 [Ultralow density cluster] Zoom to ↗ View details A/1/1525 [Ultralow density cluster] Zoom to ↗ View details A/1/1528 [Ultralow density cluster] Zoom to ↗ View details A/1/1530 [Ultralow density cluster] Zoom to ↗ View details A/1/1540 [Ultralow density cluster] Zoom to ↗ View details A/1/1569 [Ultralow density cluster] Zoom to ↗ View details A/1/1574 [Ultralow density cluster] Zoom to ↗ View details A/1/1585 [Ultralow density cluster] Zoom to ↗ View details A/1/1590 [Ultralow density cluster] Zoom to ↗ View details A/1/1594 [Ultralow density cluster] Zoom to ↗ View details A/1/1617 [Ultralow density cluster] Zoom to ↗ View details A/1/1646 [Ultralow density cluster] Zoom to ↗ View details A/1/1684 [Ultralow density cluster] Zoom to ↗ View details A/1/1702 [Ultralow density cluster] Zoom to ↗ View details A/1/1705 [Ultralow density cluster] Zoom to ↗ View details A/1/1710 [Ultralow density cluster] Zoom to ↗ View details A/1/1711 [Ultralow density cluster] Zoom to ↗ View details A/1/1715 [Ultralow density cluster] Zoom to ↗ View details A/1/1734 [Ultralow density cluster] Zoom to ↗ View details A/1/1744 [Ultralow density cluster] Zoom to ↗ View details A/1/1748 [Ultralow density cluster] Zoom to ↗ View details A/1/1756 [Ultralow density cluster] Zoom to ↗ View details A/1/1765 [Ultralow density cluster] Zoom to ↗ View details A/1/1767 [Ultralow density cluster] Zoom to ↗ View details A/1/1769 [Ultralow density cluster] Zoom to ↗ View details A/1/1792 [Ultralow density cluster] Zoom to ↗ View details A/1/1816 [Ultralow density cluster] Zoom to ↗ View details A/1/1817 [Ultralow density cluster] Zoom to ↗ View details A/1/1819 [Ultralow density cluster] Zoom to ↗ View details A/1/1831 [Ultralow density cluster] Zoom to ↗ View details A/1/1839 [Ultralow density cluster] Zoom to ↗ View details A/1/1854 [Ultralow density cluster] Zoom to ↗ View details A/1/1861 [Ultralow density cluster] Zoom to ↗ View details A/1/1869 [Ultralow density cluster] Zoom to ↗ View details A/1/1873 [Ultralow density cluster] Zoom to ↗ View details A/1/1884 [Ultralow density cluster] Zoom to ↗ View details A/1/1888 [Ultralow density cluster] Zoom to ↗ View details A/1/1897 [Ultralow density cluster] Zoom to ↗ View details A/1/1899 [Ultralow density cluster] Zoom to ↗ View details A/1/1946 [Ultralow density cluster] Zoom to ↗ View details A/1/1963 [Ultralow density cluster] Zoom to ↗ View details A/1/1966 [Ultralow density cluster] Zoom to ↗ View details A/1/1971 [Ultralow density cluster] Zoom to ↗ View details A/1/1976 [Ultralow density cluster] Zoom to ↗ View details A/1/1989 [Ultralow density cluster] Zoom to ↗ View details A/1/1994 [Ultralow density cluster] Zoom to ↗ View details A/1/2004 [Ultralow density cluster] Zoom to ↗ View details A/1/2010 [Ultralow density cluster] Zoom to ↗ View details A/1/2029 [Ultralow density cluster] Zoom to ↗ View details A/1/2043 [Ultralow density cluster] Zoom to ↗ View details A/1/2050 [Ultralow density cluster] Zoom to ↗ View details A/1/2080 [Ultralow density cluster] Zoom to ↗ View details A/1/2086 [Ultralow density cluster] Zoom to ↗ View details A/1/2093 [Ultralow density cluster] Zoom to ↗ View details A/1/2097 [Ultralow density cluster] Zoom to ↗ View details A/1/2110 [Ultralow density cluster] Zoom to ↗ View details A/1/2120 [Ultralow density cluster] Zoom to ↗ View details A/1/2128 [Ultralow density cluster] Zoom to ↗ View details A/1/2138 [Ultralow density cluster] Zoom to ↗ View details A/1/2218 [Ultralow density cluster] Zoom to ↗ View details A/1/2220 [Ultralow density cluster] Zoom to ↗ View details A/1/2223 [Ultralow density cluster] Zoom to ↗ View details A/1/2238 [Ultralow density cluster] Zoom to ↗ View details A/1/2246 [Ultralow density cluster] Zoom to ↗ View details A/1/2247 [Ultralow density cluster] Zoom to ↗ View details A/1/2257 [Ultralow density cluster] Zoom to ↗ View details A/1/2297 [Ultralow density cluster] Zoom to ↗ View details A/1/2305 [Ultralow density cluster] Zoom to ↗ View details A/1/2333 [Ultralow density cluster] Zoom to ↗ View details A/1/2355 [Ultralow density cluster] Zoom to ↗ View details A/1/2365 [Ultralow density cluster] Zoom to ↗ View details A/1/2388 [Ultralow density cluster] Zoom to ↗ View details A/1/2392 [Ultralow density cluster] Zoom to ↗ View details A/1/2408 [Ultralow density cluster] Zoom to ↗ View details A/1/2437 [Ultralow density cluster] Zoom to ↗ View details A/1/2441 [Ultralow density cluster] Zoom to ↗ View details A/1/2447 [Ultralow density cluster] Zoom to ↗ View details A/1/2470 [Ultralow density cluster] Zoom to ↗ View details A/1/2475 [Ultralow density cluster] Zoom to ↗ View details A/1/2480 [Ultralow density cluster] Zoom to ↗ View details A/1/2490 [Ultralow density cluster] Zoom to ↗ View details A/1/2511 [Ultralow density cluster] Zoom to ↗ View details A/1/2521 [Ultralow density cluster] Zoom to ↗ View details A/1/2537 [Ultralow density cluster] Zoom to ↗ View details A/1/2541 [Ultralow density cluster] Zoom to ↗ View details A/1/2544 [Ultralow density cluster] Zoom to ↗ View details A/1/2551 [Ultralow density cluster] Zoom to ↗ View details A/1/2564 [Ultralow density cluster] Zoom to ↗ View details A/1/2575 [Ultralow density cluster] Zoom to ↗ View details A/1/2581 [Ultralow density cluster] Zoom to ↗ View details A/1/2583 [Ultralow density cluster] Zoom to ↗ View details A/1/2619 [Ultralow density cluster] Zoom to ↗ View details A/1/2643 [Ultralow density cluster] Zoom to ↗ View details A/1/2648 [Ultralow density cluster] Zoom to ↗ View details A/1/2682 [Ultralow density cluster] Zoom to ↗ View details A/1/2685 [Ultralow density cluster] Zoom to ↗ View details A/1/2692 [Ultralow density cluster] Zoom to ↗ View details A/1/2714 [Ultralow density cluster] Zoom to ↗ View details A/1/2716 [Ultralow density cluster] Zoom to ↗ View details A/1/2717 [Ultralow density cluster] Zoom to ↗ View details A/1/2726 [Ultralow density cluster] Zoom to ↗ View details A/1/2733 [Ultralow density cluster] Zoom to ↗ View details A/1/2749 [Ultralow density cluster] Zoom to ↗ View details A/1/2771 [Ultralow density cluster] Zoom to ↗ View details A/1/2775 [Ultralow density cluster] Zoom to ↗ View details A/1/2833 [Ultralow density cluster] Zoom to ↗ View details A/1/2858 [Ultralow density cluster] Zoom to ↗ View details A/1/2869 [Ultralow density cluster] Zoom to ↗ View details A/1/2870 [Ultralow density cluster] Zoom to ↗ View details A/1/2891 [Ultralow density cluster] Zoom to ↗ View details A/1/2895 [Ultralow density cluster] Zoom to ↗ View details A/1/2896 [Ultralow density cluster] Zoom to ↗ View details A/1/2912 [Ultralow density cluster] Zoom to ↗ View details A/1/2923 [Ultralow density cluster] Zoom to ↗ View details A/1/2924 [Ultralow density cluster] Zoom to ↗ View details A/1/2935 [Ultralow density cluster] Zoom to ↗ View details A/1/2936 [Ultralow density cluster] Zoom to ↗ View details A/1/2938 [Ultralow density cluster] Zoom to ↗ View details A/1/2961 [Ultralow density cluster] Zoom to ↗ View details A/1/2962 [Ultralow density cluster] Zoom to ↗ View details A/1/2966 [Ultralow density cluster] Zoom to ↗ View details A/1/2980 [Ultralow density cluster] Zoom to ↗ View details A/1/2987 [Ultralow density cluster] Zoom to ↗ View details A/1/2991 [Ultralow density cluster] Zoom to ↗ View details A/1/3025 [Ultralow density cluster] Zoom to ↗ View details A/1/3051 [Ultralow density cluster] Zoom to ↗ View details A/1/3069 [Ultralow density cluster] Zoom to ↗ View details A/1/3079 [Ultralow density cluster] Zoom to ↗ View details A/1/3086 [Ultralow density cluster] Zoom to ↗ View details A/1/3092 [Ultralow density cluster] Zoom to ↗ View details A/1/3101 [Ultralow density cluster] Zoom to ↗ View details A/1/3103 [Ultralow density cluster] Zoom to ↗ View details A/1/3113 [Ultralow density cluster] Zoom to ↗ View details A/1/3117 [Ultralow density cluster] Zoom to ↗ View details A/1/3127 [Ultralow density cluster] Zoom to ↗ View details A/1/3148 [Ultralow density cluster] Zoom to ↗ View details A/1/3153 [Ultralow density cluster] Zoom to ↗ View details A/1/3168 [Ultralow density cluster] Zoom to ↗ View details A/1/3170 [Ultralow density cluster] Zoom to ↗ View details A/1/3171 [Ultralow density cluster] Zoom to ↗ View details A/1/3172 [Ultralow density cluster] Zoom to ↗ View details A/1/3187 [Ultralow density cluster] Zoom to ↗ View details A/1/3202 [Ultralow density cluster] Zoom to ↗ View details A/1/3221 [Ultralow density cluster] Zoom to ↗ View details A/1/3239 [Ultralow density cluster] Zoom to ↗ View details A/1/3251 [Ultralow density cluster] Zoom to ↗ View details A/1/3257 [Ultralow density cluster] Zoom to ↗ View details A/1/3266 [Ultralow density cluster] Zoom to ↗ View details A/1/3268 [Ultralow density cluster] Zoom to ↗ View details A/1/3273 This feature fires for words related to light, specifically luminescence. Zoom to ↗ View details A/1/3277 [Ultralow density cluster] Zoom to ↗ View details A/1/3285 [Ultralow density cluster] Zoom to ↗ View details A/1/3296 [Ultralow density cluster] Zoom to ↗ View details A/1/3300 [Ultralow density cluster] Zoom to ↗ View details A/1/3302 [Ultralow density cluster] Zoom to ↗ View details A/1/3312 [Ultralow density cluster] Zoom to ↗ View details A/1/3330 [Ultralow density cluster] Zoom to ↗ View details A/1/3360 [Ultralow density cluster] Zoom to ↗ View details A/1/3372 [Ultralow density cluster] Zoom to ↗ View details A/1/3377 [Ultralow density cluster] Zoom to ↗ View details A/1/3390 [Ultralow density cluster] Zoom to ↗ View details A/1/3391 [Ultralow density cluster] Zoom to ↗ View details A/1/3395 [Ultralow density cluster] Zoom to ↗ View details A/1/3398 [Ultralow density cluster] Zoom to ↗ View details A/1/3409 [Ultralow density cluster] Zoom to ↗ View details A/1/3431 [Ultralow density cluster] Zoom to ↗ View details A/1/3436 [Ultralow density cluster] Zoom to ↗ View details A/1/3473 [Ultralow density cluster] Zoom to ↗ View details A/1/3478 [Ultralow density cluster] Zoom to ↗ View details A/1/3480 [Ultralow density cluster] Zoom to ↗ View details A/1/3497 [Ultralow density cluster] Zoom to ↗ View details A/1/3531 [Ultralow density cluster] Zoom to ↗ View details A/1/3538 [Ultralow density cluster] Zoom to ↗ View details A/1/3541 [Ultralow density cluster] Zoom to ↗ View details A/1/3544 [Ultralow density cluster] Zoom to ↗ View details A/1/3566 [Ultralow density cluster] Zoom to ↗ View details A/1/3571 [Ultralow density cluster] Zoom to ↗ View details A/1/3575 [Ultralow density cluster] Zoom to ↗ View details A/1/3586 [Ultralow density cluster] Zoom to ↗ View details A/1/3597 [Ultralow density cluster] Zoom to ↗ View details A/1/3633 [Ultralow density cluster] Zoom to ↗ View details A/1/3640 [Ultralow density cluster] Zoom to ↗ View details A/1/3645 [Ultralow density cluster] Zoom to ↗ View details A/1/3654 [Ultralow density cluster] Zoom to ↗ View details A/1/3661 [Ultralow density cluster] Zoom to ↗ View details A/1/3662 [Ultralow density cluster] Zoom to ↗ View details A/1/3686 [Ultralow density cluster] Zoom to ↗ View details A/1/3695 [Ultralow density cluster] Zoom to ↗ View details A/1/3707 [Ultralow density cluster] Zoom to ↗ View details A/1/3714 [Ultralow density cluster] Zoom to ↗ View details A/1/3719 [Ultralow density cluster] Zoom to ↗ View details A/1/3722 [Ultralow density cluster] Zoom to ↗ View details A/1/3724 [Ultralow density cluster] Zoom to ↗ View details A/1/3727 [Ultralow density cluster] Zoom to ↗ View details A/1/3731 [Ultralow density cluster] Zoom to ↗ View details A/1/3735 [Ultralow density cluster] Zoom to ↗ View details A/1/3744 [Ultralow density cluster] Zoom to ↗ View details A/1/3764 [Ultralow density cluster] Zoom to ↗ View details A/1/3770 [Ultralow density cluster] Zoom to ↗ View details A/1/3773 [Ultralow density cluster] Zoom to ↗ View details A/1/3775 [Ultralow density cluster] Zoom to ↗ View details A/1/3781 [Ultralow density cluster] Zoom to ↗ View details A/1/3786 [Ultralow density cluster] Zoom to ↗ View details A/1/3795 [Ultralow density cluster] Zoom to ↗ View details A/1/3824 [Ultralow density cluster] Zoom to ↗ View details A/1/3834 [Ultralow density cluster] Zoom to ↗ View details A/1/3862 [Ultralow density cluster] Zoom to ↗ View details A/1/3867 [Ultralow density cluster] Zoom to ↗ View details A/1/3896 [Ultralow density cluster] Zoom to ↗ View details A/1/3930 [Ultralow density cluster] Zoom to ↗ View details A/1/3935 [Ultralow density cluster] Zoom to ↗ View details A/1/3938 [Ultralow density cluster] Zoom to ↗ View details A/1/3943 [Ultralow density cluster] Zoom to ↗ View details A/1/3946 [Ultralow density cluster] Zoom to ↗ View details A/1/3951 [Ultralow density cluster] Zoom to ↗ View details A/1/3959 [Ultralow density cluster] Zoom to ↗ View details A/1/3971 [Ultralow density cluster] Zoom to ↗ View details A/1/3996 [Ultralow density cluster] Zoom to ↗ View details A/1/4002 [Ultralow density cluster] Zoom to ↗ View details A/1/4009 [Ultralow density cluster] Zoom to ↗ View details A/1/4015 [Ultralow density cluster] Zoom to ↗ View details A/1/4017 [Ultralow density cluster] Zoom to ↗ View details A/1/4021 [Ultralow density cluster] Zoom to ↗ View details A/1/4029 [Ultralow density cluster] Zoom to ↗ View details A/1/4039 [Ultralow density cluster] Zoom to ↗ View details A/1/4057 [Ultralow density cluster] Zoom to ↗ View details Cluster #104 A/0/15 This feature fires when the current token is followed by a period. Zoom to ↗ View details A/1/248 "." in [context] Zoom to ↗ View details A/1/264 "." ending sentences in historical/chronological contexts Zoom to ↗ View details A/1/415 Period (in media review?) Zoom to ↗ View details A/1/537 "." ending a sentence in a news report about politics Zoom to ↗ View details A/1/614 "." in [context] Zoom to ↗ View details A/1/913 "." in [context] Zoom to ↗ View details A/1/1514 Periods and other sentence-concluding punctuation, esp. in video games? Zoom to ↗ View details A/1/1722 "." in [context] Zoom to ↗ View details A/1/1755 "." in [context] Zoom to ↗ View details A/1/1809 "." in [context] Zoom to ↗ View details A/1/2013 Periods, esp. shortly after EOT Zoom to ↗ View details A/1/2294 "." in [context] Zoom to ↗ View details A/1/2411 "." ending sentences in business/finance news contexts? Zoom to ↗ View details A/1/2495 ")." as end of English language parenthetical Zoom to ↗ View details A/1/3294 "." in [context] Zoom to ↗ View details A/1/3515 "." in [context] Zoom to ↗ View details A/1/3636 "." in [context] Zoom to ↗ View details A/1/3958 "." in [context] Zoom to ↗ View details Cluster #103 A/0/135 The feature fires when it sees punctuation marks and symbols like periods, parentheses, brackets, dollar signs and mathematical symbols at the end of tokens. Zoom to ↗ View details A/0/498 This feature fires when it sees punctuation at the end of a sentence or phrase, particularly periods "." Zoom to ↗ View details A/1/513 "." ending a sentence about medical care or formal medical reports Zoom to ↗ View details A/1/531 "." ending a sentence in a scientific paper, mostly materials science Zoom to ↗ View details A/1/532 "." ending a sentence in a journal paper or formal publication about disease or immunology or similar Zoom to ↗ View details A/1/831 Periods at the end of sentences in papers on radio astronomy Zoom to ↗ View details A/1/1357 "]\\]." Zoom to ↗ View details A/1/2368 End parenthetical + new sentence in academic param Zoom to ↗ View details A/1/3924 "." in [context] Zoom to ↗ View details A/1/4024 This feature fires when a sentence ends with a period. Zoom to ↗ View details A/1/796 " ." used in repeated " . . ." style contexts Zoom to ↗ View details A/1/3810 "." in [context] Zoom to ↗ View details Cluster #76 A/0/424 This feature fires when it sees a sentence ending in a question mark. Zoom to ↗ View details A/1/587 "!" Zoom to ↗ View details A/1/2770 "?" in news? Zoom to ↗ View details A/0/285 This feature attends to sentences that end with a period followed by whitespace. Zoom to ↗ View details A/1/621 "?" in dialogue? Zoom to ↗ View details A/1/3668 "." in [context] Zoom to ↗ View details Cluster #67 A/1/979 " ;)" Zoom to ↗ View details A/1/2062 " :)" Zoom to ↗ View details A/1/2855 "." in [context] Zoom to ↗ View details Cluster #72 A/0/46 This feature seems to fire when it sees words in chat logs or transcripts that users would type when asking for technical help or troubleshooting issues. Zoom to ↗ View details A/1/277 [Ultralow density cluster] Zoom to ↗ View details A/1/1282 Ubuntu/linux conversations (irc chat?) Zoom to ↗ View details A/1/1902 " the" in installations, operating systems? Zoom to ↗ View details A/1/4079 Ubuntu/Linux/GNOME terms, esp. lowercase in chat Zoom to ↗ View details A/1/2641 (IRC?) usernames being mentioned/replied to chat logs, after > and before : Zoom to ↗ View details A/1/2035 Punctuation in paths or package names near "ubuntu"/"linux"/etc. Zoom to ↗ View details Cluster #71 A/0/151 This feature fires when it sees <> and : style chat messages, IRC style messages, and other messaging styles like that. Zoom to ↗ View details A/1/149 ":" in ">"-based chat logs? Zoom to ↗ View details A/1/2616 ">" in [context] Zoom to ↗ View details Cluster #82 A/0/474 This feature fires for instances of a single space in the token sequence. Zoom to ↗ View details A/1/1117 The first space in a double-space between sentences, in a legal context Zoom to ↗ View details A/1/3053 Newline+spaces near Old/poetic English? Zoom to ↗ View details A/1/3720 " " in [context] Zoom to ↗ View details A/1/3899 Line breaks followed by many spaces in legal contexts Zoom to ↗ View details A/1/4023 " " in [context] Zoom to ↗ View details A/1/50 "..." and some other long English punctuation Zoom to ↗ View details Cluster #101 A/0/437 This feature fires when it sees line breaks (like em-dashes, hyphens, vertical bars) used as separators, especially between sentences or clauses. Zoom to ↗ View details A/1/185 Closing parenthesis on years Zoom to ↗ View details A/1/598 "\u201d" Zoom to ↗ View details A/1/2548 """ in [context] Zoom to ↗ View details A/1/3559 "space em-dash" (em dashes typeset open) in English prose Zoom to ↗ View details A/1/3592 ")" in [context] Zoom to ↗ View details A/1/2759 The feature attends to punctuation around proper nouns. Zoom to ↗ View details Cluster #66 A/0/367 This feature fires when it sees structured references (e.g., titles, sections, footnotes, page numbers) that are commonly seen in academic writing and publications. Zoom to ↗ View details A/1/960 Punctuation near ""-surrounded numbers/variables Zoom to ↗ View details A/1/1916 Continue chains of commas (and maybe related punctuation)? Zoom to ↗ View details Cluster #62 A/0/11 This feature seems to fire on numerical decimal points, especially those with 2-3 digits before and after the decimal point. Zoom to ↗ View details A/1/116 Legal text "." and ")." ? Zoom to ↗ View details A/1/498 [Ultralow density cluster] Zoom to ↗ View details A/1/569 Decimal point in a number Zoom to ↗ View details A/1/1114 "." as a decimal separator Zoom to ↗ View details A/1/1236 " ." in [context] Zoom to ↗ View details A/1/1286 "." in [context] Zoom to ↗ View details A/1/1821 "+" Zoom to ↗ View details A/1/2106 "." in [context] Zoom to ↗ View details A/1/2684 "." in [context] Zoom to ↗ View details A/1/2768 "." among long strings of digits, often ones with multiple "."s Zoom to ↗ View details A/1/2889 "." between numbers near lots of spaces Zoom to ↗ View details A/1/3082 "." in [context] Zoom to ↗ View details A/1/3609 "." interspersed between more than two numbers (version numbers, IP addresses; but not decimal numbers) Zoom to ↗ View details A/1/2130 " ?" Zoom to ↗ View details Cluster #100 A/0/507 The feature fires on the colon (:) symbol. Zoom to ↗ View details A/1/694 ":" in [context] Zoom to ↗ View details A/1/959 " -" in [context] Zoom to ↗ View details A/1/1004 : separator in times Zoom to ↗ View details A/1/1914 ":" in [context] Zoom to ↗ View details A/1/2229 ":" in [context] Zoom to ↗ View details A/1/2347 ":" in [context] Zoom to ↗ View details A/1/2713 : to indicate someone is speaking in a script Zoom to ↗ View details A/1/4091 ":" in citations of sources Zoom to ↗ View details Cluster #97 A/1/408 ":" after "\n\nA" (in Q: and A: pairs?) Zoom to ↗ View details A/1/2144 ":" in [context] Zoom to ↗ View details A/1/2186 ":" in [context] Zoom to ↗ View details A/1/2908 " !" Zoom to ↗ View details A/0/402 The feature seems to fire when it encounters punctuation such as colons, parentheses, brackets, slashes, pipes, etc. Especially when they are at the end of words or lines. Zoom to ↗ View details A/1/96 ":" esp. after "abstract" (in some paper metadata?) Zoom to ↗ View details A/1/2846 ":" in [context] Zoom to ↗ View details A/1/3751 [Ultralow density cluster] Zoom to ↗ View details A/1/3669 Punctuation or non-content links in forum posts? Zoom to ↗ View details A/1/2817 Time specification Zoom to ↗ View details A/1/1013 " "/" " in [context] Zoom to ↗ View details A/1/1537 Long spans of whitespace in poorly-formatted documents, often near decimal points Zoom to ↗ View details Cluster #86 A/0/426 This feature attends to formatted tabular data such as titles, tables, lists, tables of contents, etc. Zoom to ↗ View details A/1/1299 Spaces near vertical bars (Markdown/ASCII tables?) Zoom to ↗ View details A/1/3826 Runs of periods Zoom to ↗ View details A/1/4090 " |" in Markdown tables? Zoom to ↗ View details A/1/2885 Emoji ? Zoom to ↗ View details Cluster #85 A/1/91 ASCII/Unicode box drawings Zoom to ↗ View details A/1/972 Long runs of spaces (in technical writing / math?) Zoom to ↗ View details A/1/1717 Math Zoom to ↗ View details A/1/2139 "-->" indicating the span of time between two listed timestamps (and occasionally captures hexadecimal base pairs separated by spaces?) Zoom to ↗ View details A/1/682 Pipe-separated text (esp. words) Zoom to ↗ View details A/1/1852 LaTeX "bf" and other macros after "" Zoom to ↗ View details Cluster #45 A/0/95 The feature attends to hexadecimal numbers. Zoom to ↗ View details A/1/818 Comma-separated numbers Zoom to ↗ View details A/1/884 Digits after "0x" in "0x" hex literals Zoom to ↗ View details A/1/1399 " "/" "/" "/" "/" "/" " in [context] Zoom to ↗ View details A/1/2213 "," separating hexadecimal literals like "0xf1" Zoom to ↗ View details A/1/2430 " 0" beginning "0x" hexadecimal literals Zoom to ↗ View details A/1/3203 Hex numbers after "0x", usually in code defining ALLCAPS constants Zoom to ↗ View details A/1/2605 This feature fires on words that contain a dash "-", particularly scientific and biochemistry related terms. Zoom to ↗ View details A/1/3942 "-" in [context] Zoom to ↗ View details A/1/1272 "-" in [context] Zoom to ↗ View details Cluster #41 A/0/114 The feature fires when it encounters a hyphen followed by lowercase letters like in chemical compound names and hyphenated phrases. Zoom to ↗ View details A/1/99 Hyphen in Title-Case compounds Zoom to ↗ View details A/1/145 Hyphen after ALLCAPS abbreviation (SCPs, etc...) Zoom to ↗ View details A/1/2113 "-" connecting last names Zoom to ↗ View details A/1/2327 "-" in [context] Zoom to ↗ View details A/1/2569 "/" in [context] Zoom to ↗ View details Cluster #30 A/0/112 This feature fires on hyphens between numbers, especially when denoting age. Zoom to ↗ View details A/1/12 Hyphen, esp. after "Code § " and a number, denoting a legal code section Zoom to ↗ View details A/1/906 "/" for number/number in normal language text, often used for things like dates or simple fractions, but not in a math formula Zoom to ↗ View details A/1/1326 "-" in [context] Zoom to ↗ View details A/1/1678 "\u2013" Zoom to ↗ View details A/1/2115 "-" in identifiers/numbers/phone-numbers Zoom to ↗ View details A/1/2967 Seperator in dates Zoom to ↗ View details A/1/3712 ^/^- in scientific notation Zoom to ↗ View details Cluster #40 A/0/243 This feature seems to be attending to hyphens followed by another word or number. Zoom to ↗ View details A/0/286 This feature fires on hyphenated words often indicating prefixes and suffixes. Zoom to ↗ View details A/1/246 "-" in hyphenated constructs esp. after "anti" Zoom to ↗ View details A/1/333 "-" after common compound-word-forming preposition: "in"/"on"/"over"/... Zoom to ↗ View details A/1/489 "-" in [context] Zoom to ↗ View details A/1/556 "-" in [context] Zoom to ↗ View details A/1/902 "-" in [context] Zoom to ↗ View details A/1/986 "-" in [context] Zoom to ↗ View details A/1/1435 "-" in [context] Zoom to ↗ View details A/1/1524 "-" in [context] Zoom to ↗ View details A/1/1887 "-" in [context] Zoom to ↗ View details A/1/3007 "-" after "well" Zoom to ↗ View details A/1/3110 "-" in [context] Zoom to ↗ View details A/1/3245 "-" in [context] Zoom to ↗ View details A/1/3271 "-" in [context] Zoom to ↗ View details A/1/3423 "-" in [context] Zoom to ↗ View details A/1/3474 "-" in "non-" Zoom to ↗ View details A/1/3643 "-" in [context] Zoom to ↗ View details A/1/3931 "-" in [context] Zoom to ↗ View details A/1/1043 "/" separating language concepts like "and/or" or "noun/othernoun" Zoom to ↗ View details A/1/2438 "-" in [context] Zoom to ↗ View details A/0/276 This feature attends to punctuation like hyphens, dashes, slashes, parentheses, quotes, apostrophes, etc. Zoom to ↗ View details A/1/1115 Hyphen used to join words Zoom to ↗ View details A/0/385 This feature seems to fire after underscore characters when they are being used to emphasize or highlight the words/phrases before and after them. Zoom to ↗ View details A/1/3679 "" typically concluding italics for a title, e.g. in Markdown Zoom to ↗ View details Cluster #29 A/0/157 The feature fires when there are quotation marks or other types of quotes around words or phrases. Zoom to ↗ View details A/1/19 Various European languages: Opening quotes? Zoom to ↗ View details A/1/639 " "" quoting some legal text Zoom to ↗ View details A/1/805 " \u201c" in [context] Zoom to ↗ View details A/1/927 " "" for opening an airquote or small-phrased-quote Zoom to ↗ View details A/1/1129 Opening quotes, mostly non-ascii and stronger on double-quotes Zoom to ↗ View details A/1/2819 "\u2014", emdash Zoom to ↗ View details A/1/3649 Opening quotes, esp. " '" and esp. after a comma Zoom to ↗ View details A/1/4084 " _" Zoom to ↗ View details Cluster #28 A/0/401 The feature fires when the token directly after a period is a quotation mark. Zoom to ↗ View details A/1/1763 "\u201c" Zoom to ↗ View details A/1/2701 " "" for someone speaking to follow a sentence of their behavior or previous speaking, as in a story Zoom to ↗ View details A/1/3123 " "" to as part of rapid-fire back-and-forth conversation Zoom to ↗ View details A/1/3728 " ""as part of longer back-and-forth conversation Zoom to ↗ View details A/0/53 This feature fires strongly on quotation marks, especially double quotation marks “ “. Zoom to ↗ View details A/1/194 '"' after two newlines Zoom to ↗ View details Cluster #132 A/0/4 This feature fires on line breaks and paragraphs especially in legal or technical documents. Zoom to ↗ View details A/1/2235 Code?: Double newlines in legal text or code? Zoom to ↗ View details A/1/3350 Quadruple newlines in legal text Zoom to ↗ View details A/1/3767 Triple newlines, often after EOT Zoom to ↗ View details A/1/3463 Newlines in recipies Zoom to ↗ View details Cluster #163 A/0/354 This feature attends to line breaks (new lines) in text, particularly double line breaks. Zoom to ↗ View details A/1/1693 Newline before numbers in legal text? Zoom to ↗ View details A/1/2853 Newline in legal text Zoom to ↗ View details A/1/3462 Newline in legal judgment? Zoom to ↗ View details Cluster #130 A/1/804 Court filings Zoom to ↗ View details A/1/1198 Newline+Form Feed in legal text? Zoom to ↗ View details A/1/1582 "\u23ce\n "/"\u23ce\n "/"\u23ce\n "/"\u23ce\n "/"\u23ce\n "/"\u23ce\n "/"\u23ce\n "/"\u23ce\n "/"\u23ce\n "/"\u23ce\n "/"\u23ce\n "/"\u23ce\n " in [context] Zoom to ↗ View details Cluster #133 A/0/429 This feature fires for line breaks such as carriage returns and newlines. Zoom to ↗ View details A/1/184 Code: "\r\n\r" (carriage-return, newline, carriage-return) Zoom to ↗ View details A/1/257 Carriage returns, usu. before newlines, in legal contexts Zoom to ↗ View details A/1/625 Code: Carriage returns, usu. before newlines, esp. in C or similar languages Zoom to ↗ View details A/1/2443 Carriage returns, usu. followed by newlines, close to EOT and/or in HTML Zoom to ↗ View details A/1/2934 Carriage return Zoom to ↗ View details A/1/3947 [Ultralow density cluster] Zoom to ↗ View details A/1/4068 Code: Carriage returns, usu. before newlines, in CSS Zoom to ↗ View details Cluster #167 A/0/100 This feature fires when there is a newline character "\n". Zoom to ↗ View details A/0/192 The feature fires when a new paragraph starts. Zoom to ↗ View details A/0/372 This feature fires for line breaks / new lines. Zoom to ↗ View details A/1/171 Newlines after proper nouns? Zoom to ↗ View details A/1/1598 Newline mid-sentence in art/fiction/nature? Zoom to ↗ View details A/1/1619 Newline shortly after EOT Zoom to ↗ View details A/1/2092 Newline in discussion of accounts/authentication Zoom to ↗ View details A/1/2259 Newline in economics? Zoom to ↗ View details A/1/2354 Newline after/between quotes/dialogue Zoom to ↗ View details A/1/2555 Newline in English prose (fiction? religion/philosophy?) Zoom to ↗ View details A/1/2615 Newlines in website updates, payment/subscription management Zoom to ↗ View details A/1/2727 Newlines in patents? (mechanical engineering?) Zoom to ↗ View details A/1/2734 Newline mid-sentence esp. in religious text Zoom to ↗ View details A/1/2760 Newlines before level-3 Markdown/ATX headers Zoom to ↗ View details A/1/2822 Newlines after punctuation that's not just a period Zoom to ↗ View details A/1/3141 Newline in news reports? Zoom to ↗ View details A/1/3155 Various European languages: Newline? Zoom to ↗ View details A/1/3236 Newline after sentence-ending period Zoom to ↗ View details A/1/3499 Newline in bibliography list? Zoom to ↗ View details A/1/3779 Newline after "was"/"were" mid-sentence Zoom to ↗ View details Cluster #181 A/0/106 This feature fires when there's a new line that follows an end punctuation mark (., !, ?, ", etc.). Zoom to ↗ View details A/1/148 Newline after another newline, predicting new sentence/item Zoom to ↗ View details A/1/2454 Newlines after "References" Zoom to ↗ View details A/1/948 Newline in chat logs? (IRC?) Zoom to ↗ View details Cluster #183 A/0/475 This feature fires on new line characters ("\n"). Zoom to ↗ View details A/1/400 Newlines near numbers or number-heavy IDs Zoom to ↗ View details A/1/545 Newline in biology contexts and/or near repeated "-"/"=" as horizontal dividers Zoom to ↗ View details A/1/652 Newline after some curly-brace-based header and before "-"-based horizontal rules Zoom to ↗ View details A/1/824 Newlines after math expressions in LaTeX Zoom to ↗ View details A/1/863 " \n" after ###### Zoom to ↗ View details A/1/2182 Newline in biology near section markers? Zoom to ↗ View details A/1/2738 Newline separating Wikipedia categories Zoom to ↗ View details Cluster #184 A/0/375 This feature fires for text containing numbers ending in question marks on new lines. Zoom to ↗ View details A/1/74 Newlines in wikitext tables? Zoom to ↗ View details A/1/591 Newline near "="-based horizontal rules Zoom to ↗ View details A/1/1261 "\n\n" after "add your own caption" Zoom to ↗ View details A/1/3222 Newline in LaTeX esp. after beginning a math environment Zoom to ↗ View details A/1/2813 BibTeX Zoom to ↗ View details A/1/651 Synthetic math: Newline before/after one-line numbers in synthetic math problems Zoom to ↗ View details A/1/3352 Short sequences of asterisks? Zoom to ↗ View details A/1/845 [Ultralow density cluster] Zoom to ↗ View details A/0/132 The feature attends to Wikipedia articles, firing most for category headings. Zoom to ↗ View details A/1/2861 Wikipedia categories Zoom to ↗ View details A/1/919 Quotes/newlines in .po/.pot files (https://www.drupal.org/community/contributor-guide/reference-information/localize-drupal-org/working-with-offline/po-and-pot-files) Zoom to ↗ View details A/1/2124 Category + : Zoom to ↗ View details A/1/1494 [Ultralow density cluster] Zoom to ↗ View details A/1/275 Code: "-" esp. in "UTF-8" and other Unicode encoding names Zoom to ↗ View details Cluster #172 A/0/364 This feature fires on blocks of legal or license text. Zoom to ↗ View details A/1/72 "," in several memorized license strings Zoom to ↗ View details A/1/643 " FITNESS" in code licenses (GPL?) Zoom to ↗ View details A/1/743 WHETHER in a contract Zoom to ↗ View details A/1/803 "Competing interests" phrases Zoom to ↗ View details A/1/832 " under" in software licenses Zoom to ↗ View details A/1/1437 Copyright dates (and sometimes copyright organizations) Zoom to ↗ View details A/1/1647 All rights reserved. (and some other source code licensing texts) Zoom to ↗ View details A/1/1834 " *" (and sometimes "//") for use in copyright license multiline c/c++ comments Zoom to ↗ View details A/1/2105 " the" in the GPL license? Zoom to ↗ View details A/1/2135 Lists of 'Category' in movie metadata? Zoom to ↗ View details A/1/2711 " COURT" Zoom to ↗ View details A/1/2720 BSD License Zoom to ↗ View details A/1/2985 " picked" Zoom to ↗ View details A/1/3005 " respect" Zoom to ↗ View details A/1/3037 [Ultralow density cluster] Zoom to ↗ View details A/1/3219 " License" in the GPL Zoom to ↗ View details A/1/3349 Funding acknowledgements Zoom to ↗ View details A/1/3691 Activates on "Copyright", predicts the copyright symbol and dates Zoom to ↗ View details A/1/3845 "Click here for additional data file" and supplemental data more generally Zoom to ↗ View details A/1/3029 [Ultralow density cluster] Zoom to ↗ View details A/1/1662 Code: XML namespace references Zoom to ↗ View details A/1/3263 Code: Error variables/handling in Go? Zoom to ↗ View details A/1/1800 DOIs Zoom to ↗ View details A/1/2189 [Ultralow density cluster] Zoom to ↗ View details A/1/2514 [Ultralow density cluster] Zoom to ↗ View details A/1/2840 Newline mid-sentence or near colons? Zoom to ↗ View details Cluster #54 A/0/360 The feature fires on parentheses, especially at the end of lines and sentences. Zoom to ↗ View details A/1/853

  1. Lists 2) by 3) number? Zoom to ↗ View details A/1/1795 Newline after closing parentheses in English prose Zoom to ↗ View details Cluster #154 A/0/172 This feature fires for code snippets and other text with programming language syntax, as well as indented outlines and other structured/formatted text. Zoom to ↗ View details A/1/403 Code: Newline in HTML Zoom to ↗ View details A/1/716 Code: Newline in CSS Zoom to ↗ View details A/1/973 Code: Newline in shell commands / documentation Zoom to ↗ View details A/1/2824 Tokens near/predicting "Q" in various contexts, esp. "" Zoom to ↗ View details A/1/2917 Newlines after "Q:" and maybe more generally technical troubleshooting Zoom to ↗ View details A/1/3121 Second newline after "A:" Zoom to ↗ View details A/1/4063 Newline in code-adjacent English prose Zoom to ↗ View details Cluster #153 A/0/18 This feature fires for source code, specifically highlighting programming language syntax such as curly braces, indentation, comments, include statements, function definitions, etc. Zoom to ↗ View details A/1/559 Code: Newlines in code comments? Zoom to ↗ View details A/1/578 Code: Newlines after/between lines beginning with "#" (comments or C/C++ preprocessor?) Zoom to ↗ View details A/1/1542 Code: Newlines between/after imports, esp. Python Zoom to ↗ View details A/1/3044 Code: Newline after closing delimiters Zoom to ↗ View details A/1/3715 Code: Newline in C/C++ especially after comment closing Zoom to ↗ View details A/1/23 Code: Newlines in or near C-style /* comments */ Zoom to ↗ View details A/1/1375 Code: Newline in C/C++/Go? Zoom to ↗ View details A/1/2421 Code: "#" in C/C++ preprocessor Zoom to ↗ View details Cluster #52 A/1/1303 Code: '.' and '#' in C include statements Zoom to ↗ View details A/1/1490 Web file extensions in URLs or links Zoom to ↗ View details A/1/1741 "h" Zoom to ↗ View details A/1/3812 "\u23ce\n\t"/"\u23ce\n\t\t"/"\u23ce\n\t\t\t"/"\u23ce\n\t\t\t\t" in [context] Zoom to ↗ View details A/1/1302 [Ultralow density cluster] Zoom to ↗ View details A/1/2741 " {" in [context] Zoom to ↗ View details Cluster #160 A/0/170 This feature fires on opening and closing punctuation such as brackets, braces, quotation marks, tags, etc. Zoom to ↗ View details A/0/390 This feature seems to fire on semicolons and curly braces, which are common in programming languages. So it is likely detecting source code. Zoom to ↗ View details A/0/491 This feature attends to code blocks and style elements found in programming languages like indentation, brackets, semicolons, keywords, variables, and function names. Zoom to ↗ View details A/1/1008 Code: Semicolons concluding statements, sometimes with preceding punctuation Zoom to ↗ View details A/1/1677 Code: " }" concluding code blocks/functions Zoom to ↗ View details A/1/1938 This feature is picking up on parentheses and curly braces that contain code or math expressions. Zoom to ↗ View details A/1/2037 "}" in [context] Zoom to ↗ View details A/1/2077 Code: Closing delimiters and semicolons, predicting newlines and tab-based indentation Zoom to ↗ View details A/1/2336 Code: ends of HTML/XML tags Zoom to ↗ View details A/1/2414 Code: Semicolons, esp. ending "return" statements Zoom to ↗ View details A/1/2562 ">" in [context] Zoom to ↗ View details A/1/3135 " {" in [context] Zoom to ↗ View details A/1/4030 Code: ";"-based statement enders in code with and predicting "\r\n" (+ spaces) Zoom to ↗ View details A/1/4088 " /" Zoom to ↗ View details A/1/1020 " []" Zoom to ↗ View details A/1/1611 This feature attends to the use of semicolons at the ends of lines of code. Zoom to ↗ View details Cluster #161 A/0/30 This feature fires on opening and closing HTML tags. Zoom to ↗ View details A/1/609 The feature attends to double quotes that signify the beginning or end of strings/keys in code. Zoom to ↗ View details A/1/995 ">" in [context] Zoom to ↗ View details A/1/2995 This feature fires when it sees semicolons, especially at the end of lines. Zoom to ↗ View details A/1/3016 [Ultralow density cluster] Zoom to ↗ View details A/1/1909 Code: Newline followed by spaces in XML Zoom to ↗ View details Cluster #162 A/0/202 This feature seems to activate when it sees parentheses used to enclose parameters in function and method declarations and calls in programming languages. Zoom to ↗ View details A/1/2823 Code: "()" in function calls or definitions Zoom to ↗ View details A/1/3461 This feature attends to brackets, parentheses and curly braces. Zoom to ↗ View details A/1/1311 Code: HTML closing tag before any start of text Zoom to ↗ View details A/1/2477 "">" Zoom to ↗ View details Cluster #158 A/0/494 This feature seems to fire on HTML/XML tags and related code elements. It pays particular attention to opening and closing tags, as well as elements like paths, classes, properties, fields, methods, etc. Zoom to ↗ View details A/1/1910 Code: HTML Template Format Zoom to ↗ View details A/1/2909 Code: end double quote (in HTML attributes) Zoom to ↗ View details A/1/2965 " \u23ce\n "/"\u23ce\n "/"\u23ce\n "/"\u23ce\n "/"\u23ce\n "/"\u23ce\n "/"\u23ce\n "/"\u23ce\n "/"\u23ce\n "/"\u23ce\n " in [context] Zoom to ↗ View details Cluster #145 A/1/872 Code: uint when it's likely uint8/uint16/uint32/uint64 Zoom to ↗ View details A/1/951 Code: Go? Zoom to ↗ View details A/1/1087 Code: Function receiver types in Go Zoom to ↗ View details A/1/1529 Code: punctuation, esp. ending in ",", and spaces, esp. in Go Zoom to ↗ View details A/1/2303 Code: Whitespace, esp. in Go structs Zoom to ↗ View details A/1/2534 Code: 8/16/32/64 in uintX_t types in C Zoom to ↗ View details A/1/463 Code: Newline+spaces in doc-comments? Zoom to ↗ View details A/1/1654 "{" in [context] Zoom to ↗ View details A/1/2969 "static" Zoom to ↗ View details A/1/3235 ":" in [context] Zoom to ↗ View details Cluster #178 A/0/19 This feature fires when it sees punctuation like commas, semicolons, parentheses and brackets. Zoom to ↗ View details A/1/229 Code: "," in argument lists? Zoom to ↗ View details A/1/472 The feature attends to punctuation such as commas and parenthesis. Zoom to ↗ View details A/1/663 This feature fires when it encounters paired quotes (single or double) with comma-separated values inside. Zoom to ↗ View details A/1/928 "":" Zoom to ↗ View details A/1/1877 "," in [context] Zoom to ↗ View details Cluster #187 A/0/268 This feature attends to code structures like variable and function declarations, as well as code syntax like braces, semicolons, parentheses, arrows, and comparison operators. Zoom to ↗ View details A/0/322 This feature detects code, as it fires on code syntax such as curly braces, semicolons, indentation, function definitions, comments, etc. Zoom to ↗ View details A/1/89 Code: Newline and then spaces, esp after "{" Zoom to ↗ View details A/1/158 Code: Comments: Runs of spaces? Zoom to ↗ View details A/1/249 Code: Newline+indentation in Python? Zoom to ↗ View details A/1/395 This feature attends to token sequences indicative of function or method declarations and definitions in programming languages like C++, Ruby and Python. Zoom to ↗ View details A/1/662 " if" in [context] Zoom to ↗ View details A/1/852 Code: equal/not-equal conditions in C/C++ code Zoom to ↗ View details A/1/988 Code: Newlines and spaces after curly braces (open or close) in C/C++/Java/similar Zoom to ↗ View details A/1/1878 Code: " =" assigning a variable in a JavaScript/Java context (variable naming) Zoom to ↗ View details A/1/2057 Code: " =" assigning a variable in a C/C++ context Zoom to ↗ View details A/1/3023 " return" in [context] Zoom to ↗ View details A/1/3031 " -" in [context] Zoom to ↗ View details A/1/3299 This feature seems to activate most strongly when there are 4 or more spaces at the start of a line. This trend is most noticeable in examples 2, 3, 4, 5, 6, 7, 8, 12, 25, 32, 37, and 41. It appears that this feature is detecting indentation in code. Zoom to ↗ View details A/1/3320 Code: C++ streams Zoom to ↗ View details A/1/3607 Code: Newline followed by spaces (C/C++/Java/C#?) Zoom to ↗ View details A/1/3334 Code: identifiers close after tabs Zoom to ↗ View details A/1/699 " /" Zoom to ↗ View details Cluster #188 A/0/109 The feature fires for code in C languages based on whitespace, curly braces, semicolons, comments, function declarations, preprocessor directives, etc. Zoom to ↗ View details A/1/418 Closing parenthesis or bracket, possibly with other punctuation, in technical contexts but not code Zoom to ↗ View details A/1/1380 " //" Zoom to ↗ View details A/1/1557 Code: punctuation beginning comments like "//", "/", or "#" Zoom to ↗ View details A/1/1937 Code: C (or Java?) *'s in doc-comments Zoom to ↗ View details A/1/3157 " #" Zoom to ↗ View details A/1/3259 "####" Zoom to ↗ View details A/1/675 Code: Long runs of asterisks in comments Zoom to ↗ View details A/1/3177 [Ultralow density cluster] Zoom to ↗ View details A/1/570 Code: "define" Zoom to ↗ View details A/1/2873 Code: " *" for pointers in C/C++ code Zoom to ↗ View details A/1/2402 Code: "java" in (file.java:line) errors/stack traces Zoom to ↗ View details Cluster #60 A/0/166 This feature attends to URL links. Zoom to ↗ View details A/1/1279 "." in [context] Zoom to ↗ View details A/1/1320 Code: " at" in Java stack traces Zoom to ↗ View details A/1/1367 "." in [context] Zoom to ↗ View details A/1/1503 "." in domain names, esp. email addresses Zoom to ↗ View details A/1/1589 ":" in [context] Zoom to ↗ View details A/1/2255 "." in domain names in URLs, mildly open-source-flavored Zoom to ↗ View details A/1/3281 "." in [context] Zoom to ↗ View details A/1/3582 Code: "." in Java import paths? Zoom to ↗ View details A/1/3732 Code: "." in C# import paths? Zoom to ↗ View details A/1/4064 "/" in URLs Zoom to ↗ View details Cluster #197 A/0/118 The feature appears to fire on parentheses, arithmetic symbols, punctuation, whitespace and other programming/markup language syntax. Zoom to ↗ View details A/0/139 Zoom to ↗ View details A/0/298 This feature attends to text formatting characters such as slashes, quotes, brackets, braces, and backslashes. Zoom to ↗ View details A/1/764 Code: punctuation near string manipulation and parsing Zoom to ↗ View details A/1/767 Code: variables/attributes predicting "=" Zoom to ↗ View details A/1/817 Code: Assembly Zoom to ↗ View details A/1/996 %-based Format String Zoom to ↗ View details A/1/1535 Whitespace or English text near square-bracketed numbers/text Zoom to ↗ View details A/1/1641 Math entity prediction Zoom to ↗ View details A/1/1865 [Ultralow density cluster] Zoom to ↗ View details A/1/2990 Code: Statistics programming languages? (some Pandas, some others) Zoom to ↗ View details A/1/3434 Code: Haskell Zoom to ↗ View details A/1/3610 Regular expressions Zoom to ↗ View details A/1/3314 This feature fires on lines, dashes, underlines, and other horizontal dividers in text. Zoom to ↗ View details A/1/1423 [Ultralow density cluster] Zoom to ↗ View details Cluster #59 A/0/406 This feature attends to sentence features that include object-oriented programming concepts like classes, methods, constructors, functions, variables, parameters, arguments, etc. Zoom to ↗ View details A/1/110 Code: "." in long namespace/attribute member access chains (Java?) Zoom to ↗ View details A/1/481 " ." in [context] Zoom to ↗ View details A/1/1436 [Ultralow density cluster] Zoom to ↗ View details A/1/1696 "." in [context] Zoom to ↗ View details A/1/1738 "." in [context] Zoom to ↗ View details A/1/1775 Code: Function/method invocation in getter chains Zoom to ↗ View details A/1/2219 "." in [context] Zoom to ↗ View details A/1/2814 Code: "." in Java import paths? Zoom to ↗ View details A/1/3022 Code: "." as attribute access, accessing TitleCase members; likely Go Zoom to ↗ View details A/1/3318 "." in [context] Zoom to ↗ View details A/1/3539 Code: "." separating CapitalCamelCase identifiers (C#, Unity, etc.) Zoom to ↗ View details A/1/3615 [Ultralow density cluster] Zoom to ↗ View details A/1/3972 Code: "." sometimes with preceding punctuation in varying contexts Zoom to ↗ View details A/1/4087 Code: '). in jQuery invocation Zoom to ↗ View details Cluster #33 A/0/326 This feature fires on code snippets, specifically identifier names, keywords, braces, semicolons, and other syntactical elements. Zoom to ↗ View details A/1/1418 Tabs near uppercase letters (stock tickers? code?) Zoom to ↗ View details A/1/3830 "\t" in [context] Zoom to ↗ View details A/1/3872 "\t" in [context] Zoom to ↗ View details A/1/3988 Newline after "-"-based horizontal rules Zoom to ↗ View details A/1/940 [Ultralow density cluster] Zoom to ↗ View details A/1/3192 "://" Zoom to ↗ View details A/0/178 This feature fires on Twitter usernames in angled brackets (< and >). Zoom to ↗ View details Cluster #204 A/0/414 The feature fires when it sees groups of characters in URLs that often represent file paths, folders, file types, domains and subdomain names. Zoom to ↗ View details A/1/1570 "@", usually in email addresses Zoom to ↗ View details A/1/1979 Code: '="' in HTML attributes, particularly <a href> Zoom to ↗ View details A/1/2683 "/" and some other separators in URLs Zoom to ↗ View details A/1/3338 Code: hyphens in hyphenated code identifiers Zoom to ↗ View details A/1/4043 Code: "/" in import-paths Zoom to ↗ View details Cluster #175 A/1/152 Code: ":" in CSS specifically Zoom to ↗ View details A/1/1208 Code: CSS alignment (predicting that a vertical/horizontal alignment follows) Zoom to ↗ View details A/1/1430 Code: hyphen in CSS Zoom to ↗ View details A/1/1935 Code: "-" in font spec in CSS Zoom to ↗ View details A/1/2545 Code: =" when setting width/height in html/css Zoom to ↗ View details A/1/3577 "="" in [context] Zoom to ↗ View details A/1/3509 Subdomains or domains in URLs (after "https://" etc.) Zoom to ↗ View details Cluster #216 A/0/20 This feature attends to opening and closing HTML tags. Zoom to ↗ View details A/1/121 Code: HTML angle brackets opening/closing lists Zoom to ↗ View details A/1/290 Code: HTML tag syntax that could/does enclose table-related tags Zoom to ↗ View details A/1/968 Code: HTML/XML beginnings of close tags "</", sometimes with preceding punctuation Zoom to ↗ View details A/1/1030 Starts of HTML tags: "<" or "</", sometimes with preceding punctuation Zoom to ↗ View details A/1/1645 HTML tag beginnings "<", sometimes with preceding punctuation, predicting "br" Zoom to ↗ View details A/1/3556 "</", sometimes with preceding punctuation, beginning HTML closing tags Zoom to ↗ View details A/1/4005 Code: "><" in XML? Zoom to ↗ View details A/1/4081 Code: HTML Angle Brackets before UPPERCASE Zoom to ↗ View details A/1/279 "<" in chat logs Zoom to ↗ View details Cluster #174 A/0/284 This feature fires on HTML, CSS, and other code-heavy syntax like indentation, brackets, semicolons, and hash symbols. Zoom to ↗ View details A/1/953 Code: CSS preprocessor? Zoom to ↗ View details A/1/1449 Code: Newline +/- spaces in CSS Zoom to ↗ View details A/1/2253 Code: image file path manipulation Zoom to ↗ View details A/1/2635 "" for snake_case within androidmanifest.xml files Zoom to ↗ View details A/1/3003 Code: CSS padding Zoom to ↗ View details A/1/3218 Code: Punctuation in HTML properties Zoom to ↗ View details Cluster #215 A/0/265 This feature fires on the opening angle bracket '<' symbol, especially when it is at the beginning of a line or followed by a tag name, suggesting it is identifying HTML/XML tags. Zoom to ↗ View details A/1/607 Code: "</" in XML (with <string>, <key> tags) Zoom to ↗ View details A/1/1720 Code: Token ends with HTML open tag character Zoom to ↗ View details A/1/2540 Opening quotes in technical writing Zoom to ↗ View details A/1/3056 "<" in [context] Zoom to ↗ View details A/1/3955 "<" in [context] Zoom to ↗ View details A/1/2423 Code: Punctuation near packages and versions, esp. in Node Zoom to ↗ View details A/1/2416 Code: opening delimiters and/or quotes of any kind Zoom to ↗ View details A/1/1764 "=" in [context] Zoom to ↗ View details Cluster #231 A/0/133 The feature seems to fire on code in various programming languages, particularly around string literals and function or variable names. Zoom to ↗ View details A/0/177 This feature seems to fire most strongly for open/close parentheses. Zoom to ↗ View details A/0/409 This feature seems to fire on punctuation such as quotes, parentheses, brackets, commas, colons, semicolons, arrows, and hyphens. It also fires a bit on dollar signs and formatting such as newlines and tabs. Zoom to ↗ View details A/1/39 Code: opening quotes in data? Zoom to ↗ View details A/1/918 Code: punctuation near price calculations/processing? Zoom to ↗ View details A/1/1344 Code: Opening parenthesis in C-like for/if/while statements Zoom to ↗ View details A/1/1616 Code: "" used in snake_case to join multiple words together, usually in code contexts Zoom to ↗ View details A/1/2179 Code: usually some opening delimiter + some quote, often handling basic website user info (PHP/Perl?) Zoom to ↗ View details A/1/2224 "[" in [context] Zoom to ↗ View details A/1/2262 Code: " $" as variable sigil Zoom to ↗ View details A/1/2274 "="" in [context] Zoom to ↗ View details A/1/3093 Code: "(" calling a function/constructor Zoom to ↗ View details A/1/3864 " @" in [context] Zoom to ↗ View details A/1/3210 [Ultralow density cluster] Zoom to ↗ View details A/1/3019 Code: Punctuation near file handling Zoom to ↗ View details A/0/168 This feature seems to fire on code snippets and paths, looking for things like class names, function names, file extensions, #includes, and library imports. Zoom to ↗ View details A/1/2087 Code: punctuation in authentication-handling (PHP?) Zoom to ↗ View details A/1/1335 [Ultralow density cluster] Zoom to ↗ View details A/1/925 [Ultralow density cluster] Zoom to ↗ View details A/1/339 "" within citation-ish things, often followed by a year-of-publication Zoom to ↗ View details A/1/2310 Code: punctuation near multiprocessing and scheduling Zoom to ↗ View details A/1/2708 "::" in [context] Zoom to ↗ View details A/1/1069 Code: time manipulation Zoom to ↗ View details A/1/172 Code: Network programming? Zoom to ↗ View details Cluster #232 A/0/10 This feature attends to programming code. The feature fires more for syntax common in programming languages such as curly braces, parentheses, semi-colons, arrows, commas, hashtag/number comments, indentation, variable declarations, function calls, if/else statements, html tags, etc. Zoom to ↗ View details A/0/462 This feature detects hyphens between words that indicate compound terms. Zoom to ↗ View details A/1/1546 Code: :: token in C++ namespaces Zoom to ↗ View details A/1/1846 Code: C for low-level (circuit boards etc.) programming? Zoom to ↗ View details A/1/2231 "->" Zoom to ↗ View details A/1/2748 Code: Underscores in snake_case identifiers Zoom to ↗ View details A/1/3747 Code: Open parentheses, sometimes with more punctuation, in C-like languages Zoom to ↗ View details A/1/1669 "" for snake_case within mathematical variable names Zoom to ↗ View details A/1/1007 Code: security key references Zoom to ↗ View details A/0/199 This feature appears to fire on tokens related to computer networking, such as IP addresses, TCP, TLS, SSL, HTTPS, ports, sockets, servers, certs, URLs, etc. Zoom to ↗ View details A/0/216 Zoom to ↗ View details A/1/1450 Code: mostly punctuation in maybe function metaprogramming? Zoom to ↗ View details A/1/28 Code: making/manipulating HTTP requests and responses Zoom to ↗ View details A/1/1709 Code: " __" in special identifiers Zoom to ↗ View details A/1/3270 Words related to logging in/authentication Zoom to ↗ View details Cluster #141 A/0/358 This feature seems to attend to code snippets and programming-related text, looking for things like variable names, function names, keywords, and other code-specific syntax. Zoom to ↗ View details A/1/126 Code: Underscores in UPPER_SNAKE_CASE identifiers Zoom to ↗ View details A/1/209 [Ultralow density cluster] Zoom to ↗ View details A/1/477 Code: "" in UPPER_SNAKE_CASE identifiers (registers, low-level C?) Zoom to ↗ View details A/1/896 [Ultralow density cluster] Zoom to ↗ View details A/1/1201 Code: CMake Zoom to ↗ View details A/1/2328 " "" for opening (and sometimes "." for closing) an all-caps quoted sentence, that guides further all-caps Zoom to ↗ View details A/1/3347 Code: _ in C++ macro, especially after BOOST Zoom to ↗ View details A/1/2444 Code: JavaScript or web frameworks (React etc.?) Zoom to ↗ View details A/1/575 Code: CSS Zoom to ↗ View details A/1/2009 Code: Command lines / shell scripts Zoom to ↗ View details A/1/2473 Code: C++? Gtk/UI programming? Zoom to ↗ View details A/1/3100 [Ultralow density cluster] Zoom to ↗ View details A/1/644 Code: C++ include statements Zoom to ↗ View details A/1/371 English descriptions of character classes Zoom to ↗ View details Cluster #118 A/0/207 This feature seems to fire on code-like tokens such as variable names, function names, keywords, preprocessor directives, nested blocks, etc. Zoom to ↗ View details A/1/1102 Code: ALL_CAPS with underscores Zoom to ↗ View details A/1/1325 ALLCAPS Syscall names, predicting runs of spaces? Zoom to ↗ View details A/1/1455 Code: Uppercase letters in SNAKE_CASE identifiers Zoom to ↗ View details A/1/2133 Code: Uppercase letters in SNAKE_CASE identifiers (in C preprocessor?) Zoom to ↗ View details A/1/3485 Capitalized letters and punctuation near/predicting "P" Zoom to ↗ View details A/1/3589 This feature seems to attend to proper names or acronyms starting with the letter M. Zoom to ↗ View details A/1/3651 TitleCase word prefixes predicting -ex, esp. in code contexts, esp. "Mut" Zoom to ↗ View details Cluster #194 A/0/257 This feature fires when it sees web addresses and URLs. Zoom to ↗ View details A/0/262 This feature seems to fire on stylistic features such as backticks () and different kinds of brackets/parentheses including angle brackets (<>), square brackets ([]) and curly braces ({}). It also fires on short hyphens/dashes (-) and tildes (~). Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-262) A/1/44 Usernames in a chat transcript of some sort? Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-44) A/1/105 Words in URLs (excluding the "/" delimiters), focusing more on characters than numbers Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-105) A/1/360 "com" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-360) A/1/540 Code: Various kinds of markup code (emails, html, cssy-stuff, misc data formats, etc) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-540) A/1/1458 TLDs in URLS (com in github.com, org in wikipedia.org) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1458) A/1/2089 Parts of domain names Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2089) A/1/2620 Path components after and predicting "/" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2620) Cluster #198 A/1/289 "https" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-289) A/1/2370 Code: Linux command line Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2370) A/1/3011 " lib" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3011) A/1/3129 "http" in urls Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3129) Cluster #148 A/0/384 This feature seems to fire strongly on uppercase, camel case and punctuation such as hyphens. These all appear to be common in code, variable names, function names, etc. So this feature likely attends to stylistic features common in programming languages and code. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-384) A/1/769 OCR Errors Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-769) A/1/2774 Text or word fragments, maybe medical Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2774) A/1/3010 " extends" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3010) A/1/3797 [Ultralow density cluster] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3797) A/1/3085 Nouns in computer programming, which maybe hold code/state Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3085) A/1/2121 Object-oriented programming (English prose) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2121) A/1/938 Capitalized New Word Prediction Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-938) A/0/150 This feature fires on variable, function and class names in a variety of programming languages. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-150) A/1/1263 The feature appears to fire on tokens that typically contain the letter v. The feature fires most strongly on occurrences of the letter v itself, but also activates some for words containing v, variable and function names including v, programming language identifiers starting with v, urls containing /v/, and hex color codes containing v. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1263) A/1/3367 Code: identifier fragments esp. non-English, or sometimes typos Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3367) Cluster #202 A/0/256 The feature fires when it sees code comments, denoted by /* ... */ or // in programming languages such as C, C++, Java, etc. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-256) A/1/34 Code: Comments: Nouns in systems/database engineering? Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-34) A/1/577 Code: documentation in markdown? Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-577) A/1/1600 Code: Capitalized words at beginnings of code comments Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1600) A/1/1672 Code-related English prose, e.g. API documentation Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1672) A/1/3382 Documentation around memory/CPU concepts (stack, pointer, structure, clock, size, etc) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3382) Cluster #201 A/0/362 This feature attends to code snippets, specifically Python code. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-362) A/1/751 Generic part of variable name Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-751) A/1/3848 Code: Names being imported in Python Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3848) A/1/3884 Code: Python imports Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3884) A/1/4089 Components of period-separated attribute/package paths Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-4089) A/1/2147 Code: C style comments about low-level hardware Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2147) A/1/3444 TitleCase identifier components, esp. final ones, esp. with some abstract code meaning like "Class" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3444) A/1/692 Code: predicting byte/buffer? Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-692) A/1/724 "include" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-724) A/1/567 "import" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-567) Cluster #65 A/0/386 This feature fires for numbers enclosed with symbols such as parentheses or brackets. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-386) A/1/1642 Caesar-shift encoded words Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1642) A/1/2950 ASCII control characters Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2950) A/1/2389 "x" in "0x" hex literals with many leading 0s Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2389) Cluster #107 A/0/119 This feature attends to hexadecimal strings. It appears to fire most strongly on strings of length 6-8. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-119) A/1/97 Long strings of digits Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-97) A/1/198 Lowercase hexadecimal (digit token) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-198) A/1/1444 Hexadecimal, esp. lowercase letters, predicting digits Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1444) A/1/2025 Digits esp. after the decimal point in decimals Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2025) A/1/2048 List of Numbers (space-separated) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2048) A/1/3629 "x" in hexadecimal literals Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3629) A/1/3817 Hexadecimal (uppercase) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3817) Cluster #64 A/0/45 This feature fires when it sees base64 encoded text. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-45) A/1/1493 Synthetic math: repetitive letter strings being picked "without replacement from" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1493) A/1/1544 base64 of ASCII Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1544) A/1/2357 base64 (esp. uppercase letters) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2357) A/1/2364 base64 digits Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2364) A/1/1961 Letters in short fragments of uppercase hexadecimal or some alphanumeric IDs Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1961) Cluster #106 A/0/283 The feature attends to numbers containing hyphens commonly found in phone numbers, dates, times, and item numbers. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-283) A/1/327 Hour parts of timestamps, esp. with leading space and 0 Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-327) A/1/1881 Numbers in various contexts e.g. error IDs Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1881) A/1/2215 Grant and project IDs, mostly digits with few capital letters Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2215) A/1/3807 2-digit time components separated by ":"s Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3807) A/1/4027 Numbers in hyphen-separated sequences Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-4027) A/1/3941 Parts of phone numbers Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3941) A/1/1036 Digits in URLs Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1036) A/1/2859 Dot-separated version numbers Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2859) A/1/1573 File path components esp. related to installable software, packages, fonts Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1573) A/1/605 Space+number tokens in various technical contexts Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-605) A/1/3920 Code: Punctuation esp. at end of first line of class declarations Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3920) A/1/2945 Code: Objective C method declarations, with ":(" indicating a type will come next as part of a declaration Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2945) A/1/3020 Python-adjacent text/punctuation, esp. "#," preceding " python-format" in .po/.pot files Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3020) A/1/2998 Usernames in irc-style <username> format Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2998) A/0/153 This feature attends to HTML tags. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-153) Cluster #150 A/0/0 This feature attends to HTML and XML tags. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-0) A/1/173 Code: HTML attribute names Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-173) A/1/259 Code: Numbers/hexadecimals inside quoted strings for UX-related config/markup (XML?) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-259) A/1/978 Code: HTML class name, particularly abstract layout-related like "container" or "child" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-978) A/1/985 Android XML layout file properties Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-985) A/1/1082 Code: HTML/XML tag names in closing tags Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1082) A/1/1713 Code: Java/C++ types inside a template/generic instantiation Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1713) A/1/3457 Code: HTML/XML opening tag names Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3457) A/1/4031 " class" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-4031) A/1/4086 HTML tag names (generally after "<") Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-4086) A/1/1879 Text in HTML or XML tags (predicting close tags) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1879) A/1/3034 Code: Parts of strings in compact JSON Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3034) A/1/4069 HTML/CSS tutorials (prose) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-4069) Cluster #151 A/0/266 This feature attends to HTML programming code including HTML tags and attributes. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-266) A/1/244 Mid-word quoted text, predicting closing quotes Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-244) A/1/1124 Double-quotes string as first argument to a function or method call Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1124) A/1/2175 Code: Single-quoted strings (often in an array, set, or function call) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2175) A/1/3226 Words in string literals in JSON or similar in package metadata ("integrity", "metadata", "outputs") Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3226) A/1/1603 Code: jQuery methods Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1603) A/1/2095 Short text in double quotes, esp. in technical contexts Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2095) A/1/815 " click" / instructions for interacting with UIs Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-815) Cluster #192 A/0/209 This feature attends to the syntactic and structural features of SQL code. It fires on common keywords, symbols, and formatting in SQL such as SELECT, FROM, DISTINCT, *, ", (, ), \n, AS, etc. as well as code structure like indentation. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-209) A/1/1618 Letter strings that predict "ID"/"id" (no space) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1618) A/1/2060 Verbs and adjectives in discussions of tabular databases / spreadsheets Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2060) A/1/2164 Code: Testing-related Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2164) A/1/3518 Code: Visual Basic for Excel Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3518) A/1/3550 Code: SQL-related C/C++/Java code, constants, and comments Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3550) A/1/4010 Code: SQL Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-4010) A/1/3825 [Ultralow density cluster] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3825) A/1/2038 Code: Error conditions esp. "Failed" in error message string literals Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2038) A/1/1242 " var" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1242) A/1/3012 Code: .Net Manifest XML? Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3012) A/1/1269 Code: related to IDs, users, accounts, and similar Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1269) A/1/2779 Code: Java CamelCase identifier constituents? ("Manager" "Application" "Bean" etc.) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2779) A/1/3072 Code: Field names in JavaScript Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3072) Cluster #240 A/0/39 The feature attends to code-like structures such as identifiers, keywords and symbols and longer code-fragments in various programming languages. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-39) A/0/211 This feature seems to attend to UI layout code for mobile apps, firing strongly on class names, methods, and UI element names commonly used when defining app layouts and styles. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-211) A/1/236 Code: "get" in getter method names Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-236) A/1/668 Code: CamelCase identifier components esp after "get" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-668) A/1/1026 Code: File Manipulation Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1026) A/1/1140 [Ultralow density cluster] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1140) A/1/1318 Code: the start of a line of indented code that is operating on a object/class (vs control flow) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1318) A/1/1749 Code: Java class/interface names in a class definition Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1749) A/1/1766 "nbsp" and some other HTML ampersand escape names Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1766) A/1/1844 Code: Date/time-related in Java/Objective-C languages Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1844) A/1/1876 Code: Android UX Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1876) A/1/2015 Code: CamelCase versions of UI/UX concepts Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2015) A/1/2107 Code: Objective C function/method calls on iOS Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2107) A/1/2532 Code: relating to processes and tasks and async execution Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2532) A/1/2607 Code: words in CamelCase, particularly prepositions: "To", "For", etc. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2607) A/1/2886 Code: C# components of CamelCase identifiers (metaprogramming?) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2886) A/1/4012 Spanish and Portuguese: Pseudocode or coding related words? Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-4012) A/1/2892 Code: abstract-ish identifiers in object names, method calls, variable declarations Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2892) A/1/3228 Code: $-sigil-prefixed variable names (PHP/Perl?) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3228) A/1/232 Code: some serialization or dump of networking info? Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-232) A/1/1606 "Exception" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1606) A/1/1227 Code typically near string concatenation Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1227) A/1/2417 This feature seems to activate for code snippets and programming-related text. Some indications of this: - Frequent use of programming-related symbols and keywords like :=, void, int, def, public, etc. - Indentation and structure common in code, like braces { }, indentation, newlines, etc. - Frequent variable and function names like input, printf, copy, assign, etc. - Presence of comments like /* ... */ and // So in summary, this feature strongly attends to programming code and related text. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2417) Cluster #243 A/0/388 The feature appears to respond strongest to code-like text and variable names, particularly shorter words like "var", "int", "mem", etc. It also seems to fire on function names, boolean values, and math operators. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-388) A/1/20 Code: println and other method calls, esp in Java Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-20) A/1/3165 Code: PHP loop iteratees? Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3165) A/1/3684 Code: arguments in comma-separated argument lists Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3684) A/1/3644 Code: " String" in C++ Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3644) A/1/2342 Code: C++ " private" and other keywords Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2342) A/1/1149 Code: Variable names after "var", likely JavaScript Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1149) Cluster #173 A/0/511 This feature attends to code and programming language syntax such as variable declarations and function calls. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-511) A/1/186 [Ultralow density cluster] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-186) A/1/454 Code: punctuation near geometry / graphics calculations Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-454) A/1/1762 Code: identifier components used in geometry / graphics Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1762) A/1/2306 " E" or other identifier prefixes or punctuation predicting "GL" in OpenGL contexts Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2306) A/1/4080 This feature attends to text dealing with lung diseases, specifically chronic obstructive pulmonary disease (COPD). Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-4080) A/1/1995 Code: Components of CamelCase identifiers (in C/C++?) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1995) A/1/1476 Code: Python (Machine Learning) (esp. punctuation) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1476) A/1/2193 [Ultralow density cluster] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2193) A/0/349 This feature attends to code blocks, particularly Python code. It fires on syntax like variable assignments, function definitions, class definitions, imports, strings, comments, and other Python-specific syntax. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-349) A/1/2574 Code: Tree traversal (mix of Java, Go, Javascript, maybe others) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2574) Cluster #225 A/1/430 " char" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-430) A/1/837 " void" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-837) A/1/1845 " unsigned"/"unsigned" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1845) A/1/3286 " int" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3286) A/1/2101 Code: identifier fragments, often after "_", related to data or dimension/shape Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2101) A/0/460 This feature attends to programming language syntax, particularly C/C++. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-460) A/1/386 Code: C++ template type variables, esp. " T" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-386) A/1/573 Code: " std" and other C++ namespaces (anticipating "::") Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-573) Cluster #207 A/0/140 The feature appears to fire on identifier names in programming languages. It attends to variable, function, and class names in code. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-140) A/0/411 This feature fires on source code tokens related to declaring variables, functions, structs, etc. such as int, void, struct as well as punctuation like ; , ( ) { } and identifiers that look like variable names. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-411) A/1/29 Code: Beginnings of components of snake_case identifiers Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-29) A/1/218 Code: short variable names? Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-218) A/1/447 " i" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-447) A/1/1051 Code: space+letter tokens, often single-letter variable names) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1051) A/1/2993 Code: C in hardware drivers Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2993) A/1/144 Code: C++ type-level programming Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-144) A/1/94 Code: Python Definition Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-94) A/1/3992 Code: " null" or sometimes " false" esp. after ":" or "return" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3992) A/1/1760 Fields accessed with member-of-pointer (arrow operator "->") in C++ Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1760) A/1/2468 " len" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2468) A/1/899 " x" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-899) A/1/3048 Code: argument name after "(" or "(&" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3048) Cluster #92 A/0/305 This feature seems to fire on numbers with decimal points, especially when they are close to 0.5. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-305) A/1/705 Code: Single digits, usually not numeric literals (e.g. in identifiers or versions) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-705) A/1/718 Single-digit tokens esp. after "=", often some software flag or argument Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-718) A/1/3989 " 0" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3989) Cluster #242 A/0/196 The feature seems to fire on string formatting in code, particularly left and right parentheses, string formatting characters like %s, and tokens associated with variable names. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-196) A/1/409 Code: Identifiers after "(", likely arguments, in C#? Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-409) A/1/1729 Code: variable in if () condition Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1729) A/1/3033 Code: words referring to measurements or quantities: "length"/"width"/"height"/"count" etc. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3033) A/1/3128 Code: End of parenthetical Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3128) A/1/1442 Code: Small numeric constants in parentheses (predicting close parentheses) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1442) A/1/1379 " As" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1379) Cluster #265 A/0/282 This feature seems to fire when it detects the use of comparative language such as "than", "except when", and "other than". It detects phrases that compare two things, either explicitly using "than" or "more/less than", or implicitly through use of "except" or "other than". Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-282) A/1/16 " than" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-16) A/1/3849 " than" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3849) A/0/351 This feature attends to the word "as" used as a conjunction. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-351) Cluster #264 A/0/104 This feature fires when it sees the word "as" being used as a preposition or conjunction. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-104) A/1/555 " as" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-555) A/1/631 " as" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-631) A/1/1978 " as" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1978) A/1/3252 " as" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3252) A/1/3666 " as" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3666) A/1/963 Adverb in "as ... as" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-963) A/1/1083 "As" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1083) A/1/1390 " since" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1390) A/1/3293 " until" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3293) A/1/1686 " except" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1686) A/1/3674 This feature fires when transition words like "furthermore", "moreover", "thus", etc are used. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3674) A/1/3035 " while" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3035) Cluster #253 A/1/1111 Express uncertainty with maybe/probably/perhaps Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1111) A/1/1784 " then" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1784) A/1/2054 " Well" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2054) Cluster #274 A/0/502 This feature seems to fire on words like "moreover", "because", and "however", which are used to signal logical connections in arguments. So in summary, this feature attends to argument structure and transition words. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-502) A/1/622 " but" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-622) A/1/1560 Sentence-starting word like "Moreover" and "Therefore" (predicting ",") Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1560) A/1/3525 " however" mid-sentence (after commas or semicolons) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3525) Cluster #275 A/0/29 This feature fires when the word "if" is present. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-29) A/1/592 " if" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-592) A/1/2278 "if" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2278) A/1/2406 "If" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2406) A/1/3059 "though"/"although"/"while"/forms Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3059) A/1/3852 " Whether"/" whether" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3852) A/1/3918 " when" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3918) Cluster #263 A/0/116 This feature fires in response to transition words like "however", "but", "although", "though", "even though", "yet", and "until". Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-116) A/0/191 The feature fires for the word "And" as a discourse or stylistic marker to conjoin phrases or clauses. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-191) A/1/355 " Or"/"Or" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-355) A/1/1021 " but" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1021) A/1/2088 " Nor" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2088) A/1/2972 Sentence-starting conjunctions " And"/" But" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2972) A/1/3304 " So"/"So" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3304) A/1/2531 " because" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2531) A/1/2699 [Ultralow density cluster] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2699) Cluster #269 A/0/141 This feature attends to phrases that contain the word "that". Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-141) A/1/254 " that" Relative Pronoun, news Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-254) A/1/450 " that" Relative Pronoun, Scientific Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-450) A/1/604 " that" Relative Pronoun, Narrative Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-604) A/1/1177 " that" conjuction scientific Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1177) A/1/1250 " that" Indicative/Conjunction Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1250) A/1/1551 " that" Demonstrative Pronoun Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1551) A/1/1863 " which" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1863) A/1/2645 " that" legal Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2645) A/1/4082 " which" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-4082) A/0/127 This feature appears to activate when surrounding text contains relative pronouns like "which", "who", and "whom". Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-127) Cluster #258 A/0/222 This feature attends to the interrogative pronoun "what". Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-222) A/1/372 " how" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-372) A/1/752 "Why" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-752) A/1/2102 " what" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2102) A/1/2603 " What"/"What" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2603) A/1/3555 "How" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3555) A/1/1362 " That"/"That" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1362) A/1/1484 " Oh"/"Oh" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1484) A/1/501 " who" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-501) A/1/263 " Which"/"Which" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-263) A/1/3288 Affirmative utterances: "Yeah", "Yes", "Okay" etc. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3288) Cluster #177 A/0/186 This feature is firing for interrogative sentences starting with “what”. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-186) A/1/130 " can"/" could"/" would" after "How" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-130) A/1/156 Word after "What" where "what" is the start of a phrase Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-156) A/1/1580 " you" as a question (often a yes/no question) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1580) A/1/2122 Concepts/words in questions, predicting the end of the question "?", optionally with more punctuation Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2122) A/1/3626 [Ultralow density cluster] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3626) Cluster #170 A/0/122 The feature attends to statements or phrases using the words "there is," "there are," or "here" to indicate existence, presence, location or emphasis. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-122) A/0/394 This feature fires when the token is "it's" or "It's". Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-394) A/1/141 " it"/" It" in scientific contexts Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-141) A/1/600 " it" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-600) A/1/618 Abstract nouns in "If"/"When" sentences, esp. computing or astrophysics related (e.g. "algorithm", "universe") Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-618) A/1/794 " it" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-794) A/1/1610 " you" and other pronouns after "thought" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1610) A/1/1776 " it" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1776) A/1/1870 "It" in "It's", at the start of quoted speech Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1870) A/1/2168 " There"/"There" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2168) A/1/2546 " there" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2546) A/1/3152 " It"/"It" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3152) A/1/3460 " Here"/"Here" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3460) A/1/3366 Emphasis, specificity, or exclusivity Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3366) Cluster #189 A/0/24 This feature attends to first person plural pronouns. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-24) A/0/73 This feature fires when the word "you" or variations of it ("your", "you've", etc.) are present. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-73) A/0/171 The feature fires when it sees second person pronouns such as "you", "your", and "yours". Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-171) A/0/190 This feature attends to sentences with the pronoun "they", especially in contexts where "they" refers to people. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-190) A/1/77 " authors" (and capitalization/spacing variants) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-77) A/1/486 " We"/" we" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-486) A/1/616 " You"/"You" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-616) A/1/655 " they" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-655) A/1/1218 " You"/"You" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1218) A/1/1346 " you" in conditional "if" sentences Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1346) A/1/1793 " They"/" they" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1793) A/1/2084 " we", in political punditry / media reviews? Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2084) A/1/2270 " we", esp. after a comma, in legal contexts Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2270) A/1/2493 "We" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2493) A/1/2568 Words after "we"/"We", esp. adverbs indicating time or chronological position ("firstly", "then", etc.) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2568) A/1/2827 "they"/"you"/"didn" predicting U+2019 Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2827) A/1/2847 " it"/" she"/" he" after "if" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2847) A/1/3014 " you" as subject of subclause Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3014) A/1/3310 " you" as direct object Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3310) A/1/3532 " We" in scientific contexts (royal "we found" etc.) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3532) Cluster #190 A/0/154 This feature attends to the pronoun "she" and associated female pronouns (her, herself). Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-154) A/0/482 The feature fires when it sees pronouns such as "he", "she", "who", etc. in the context of the sentence. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-482) A/1/650 " he"/" she" esp. in legal reports Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-650) A/1/745 " He"/"He" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-745) A/1/1342 " She"/" she"/"she" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1342) A/1/2069 "he" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2069) A/1/2549 This feature attends to instances of the pronoun "he", referring to a male person. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2549) Cluster #179 A/0/224 The feature detects first person singular pronouns and contractions such as "I", "I'm", "I've", "I'd", etc. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-224) A/0/271 This feature attends to the usage of the word "I" and related pronouns like "I'm", "I've", etc. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-271) A/1/52 " I" present tense Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-52) A/1/1725 " I" (or "I") at the beginning of a double-quoted statement Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1725) A/1/2241 " I", often in technical/troubleshooting contexts Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2241) A/1/2624 "I" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2624) A/1/2640 " i", typically as a pronoun or in "iirc" in casual writing or chat Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2640) A/1/2715 " I" in a conditional(subjunctive?) sense: "when I", "If I", "because I", etc Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2715) A/1/2765 " I" at the beginning of a sentence Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2765) A/1/3487 " I", esp. in medical contexts as either the Roman numeral for 1 or start of an abbreviation Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3487) A/1/3676 'I' usually after 'but' Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3676) A/1/4022 " I" in a proper noun (usually? Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-4022) A/1/4045 " I" past tense Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-4045) A/1/874 " Which"/"Which" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-874) Cluster #223 A/0/444 This feature appears to fire for sentences with mathematical questions or formulas that reference specific terms in sequences, such as the nth term. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-444) A/1/201 Synthetic math: " replacement" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-201) A/1/1350 This feature attends to mathematical terms and concepts such as highest common factor, derivatives, prime factors, and integer rounding. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1350) A/1/1388 " nearest" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1388) A/1/2681 " prime" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2681) A/1/3682 " divided" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3682) A/1/3922 Synthetic math: " first"/" second"/" third" before " derivative" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3922) A/1/3167 Newlines before/after "True/False" in math problems Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3167) A/1/2834 Synthetic math: " is" in division problems Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2834) A/1/653 Numerical place ('thousands', 'tens', 'hundreds'), predicts digit, from math dataset Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-653) A/1/3397 " the" in "What is the..." etc. math problems Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3397) A/1/3280 "-" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3280) A/1/735 [Ultralow density cluster] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-735) A/1/4007 Synthetic math: ":" in multisets that are being sampled "without replacement from" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-4007) Cluster #224 A/0/96 This feature seems to detect math-related questions and phrases, like "What is..." and "Find the...". It looks for mathematical operations and concepts like derivatives, divisors, factors, roots, etc. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-96) A/1/485 " to" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-485) A/1/777 "of" in a Math context, for denominator/term/derivative "of" a number Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-777) A/1/1813 " What"/"What" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1813) A/1/2609 " is" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2609) A/1/2764 " without" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2764) A/1/3554 " prob" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3554) A/1/3652 " in" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3652) Cluster #185 A/1/930 " (" for multiple choice answers in math; generic "(" in math in lower quantiles Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-930) A/1/1323 " ||" in wikitext tables involving dates Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1323) A/1/2214 Synthetic math: Spaces and closing parentheses before choices in math multiple-choice questions Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2214) A/1/2729 "⁄" U+2044 in normalized UTF-8 as latin1 mojibake Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2729) A/1/3602 [Ultralow density cluster] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3602) A/1/2192 " and" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2192) Cluster #203 A/0/505 This feature fires on arithmetic symbols such as the minus sign and equals sign. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-505) A/1/1986 " +" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1986) A/1/2216 "," in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2216) A/1/2308 " -" as minus sign in math Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2308) A/1/2349 " -" indicating a negative number in a math problem Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2349) A/1/2474 This feature seems to fire when mathematical operations and notation are present, such as determining values, calculating probabilities, solving equations, etc. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2474) A/1/2500 " =" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2500) A/1/3991 Verbs, esp. imperative, in (often synthetic) math Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3991) A/1/3693 [Ultralow density cluster] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3693) Cluster #191 A/0/195 This feature fires for characters and patterns associated with mathematical expressions and equations such as parentheses, decimal points, division signs, exponents, equals signs, variables, numbers, and equations. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-195) A/1/782 [Ultralow density cluster] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-782) A/1/3343 "?" after non-words? Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3343) A/1/3969 "." in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3969) A/1/2856 " be" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2856) Cluster #186 A/0/105 This feature attends to numerical formatting such as numbers, mathematical symbols and fractions. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-105) A/1/1826 "](#" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1826) A/1/2789 [Ultralow density cluster] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2789) A/1/3188 Burmese: ? Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3188) Cluster #219 A/0/293 This feature seems to attend to mathematical equations and formulas containing variables, operations, and numbers. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-293) A/1/2277 Synthetic math: "Let" introducing a math equation after a period Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2277) A/1/2753 " Suppose" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2753) A/1/2207 ")." as an end of a math formula sentence Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2207) A/1/14 Synthetic math: Open parenthesis in "Let a(b)..." Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-14) A/1/3865 Synthetic math: numbers being exponentiated (after "**") Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3865) A/1/1022 "sqrt" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1022) A/1/1568 "**" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1568) Cluster #220 A/0/149 This feature appears to fire for numbers and math symbols, particularly exponents, in the context of mathematical equations and expressions. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-149) A/0/233 This feature attends to the phrases like 'let x = ...' and other statements of equations, variables, and mathematical expressions. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-233) A/1/62 [Ultralow density cluster] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-62) A/1/495 Synthetic math: Single-letter variables or functions Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-495) A/1/812 Single-letter variables in synthetic math esp. polynomials Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-812) A/1/847 Synthetic math: numeric constants before "*" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-847) A/1/855 This feature attends to mathematical expressions involving variables. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-855) A/1/1471 Synthetic math: numbers, about to be multiplied, after "Solve"/"Suppose" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1471) A/1/2302 Synthetic math: digits between newlines (problem numbers?) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2302) A/1/2572 [Ultralow density cluster] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2572) A/1/2662 Synthetic math: space followed by digit usu. after "+" or "-" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2662) A/1/3032 Year in Month Day Year format dates Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3032) A/1/3091 Synthetic math: numbers after single-letter keys "x:" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3091) A/1/3387 Synthetic math: number after "Let x =" (where x is any single letter) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3387) A/1/3400 LaTeX math-mode-ending "$" esp. shortly after "Let"? Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3400) A/1/3526 Single-letter variables in polynomials? (where exponentiation is **) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3526) A/1/3568 This feature attends to basic arithmetic operations and equations involving addition, subtraction, multiplication and equal signs. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3568) A/1/3573 ")" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3573) A/1/3584 Synthetic math: single-letter variables esp. after number and "*" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3584) A/1/3762 Synthetic math: Single Token "*" in problems Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3762) Cluster #206 A/0/68 This feature appears to fire on mathematical expressions involving fractions, exponents, parentheses, variables, operators, and numbers. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-68) A/0/324 This feature fires on mathematical expressions and equations involving multiplication, exponentiation and variable names. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-324) A/1/46 "*" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-46) A/1/70 Synthetic math: numbers esp. in sqrt() Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-70) A/1/528 "(-" as the beginning of parenthesized negative number in math Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-528) A/1/583 Synthetic math: Variable name inside the parens of a definition of a function in math Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-583) A/1/593 Synthetic math: "(" of a sqrt(number) call where number is numbers and not a variable Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-593) A/1/781 Synthetic math?: Numbers and variables in equations Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-781) A/1/1321 ")/(-" or "/(-" in mathematical expressions Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1321) A/1/1689 ")/" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1689) A/1/2743 Newline-space in some serialization format? (YAML?) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2743) A/1/2952 Synthetic math: exponentiation starting with "**" with optional "(" and "-" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2952) A/1/3095 Synthetic math: minus sign in mathematical expressions Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3095) A/1/3276 ")*(-" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3276) A/1/3472 "/" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3472) A/1/3617 Synthetic math: numbers in nested fractions Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3617) A/1/3743 Synthetic math: Expression after "Simplify" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3743) A/1/3870 "/" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3870) A/1/332 xAB hex escapes (without backslashes or other delimiters) near text Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-332) A/1/842 LaTeX punctuation after \sum or \prod (either subscript or "\" anticipating "limits") Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-842) A/1/1564 Consecutive numbers Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1564) Cluster #210 A/0/292 This feature fires for mathematical expressions involving integers. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-292) A/1/315 Synthetic math: Arithmetic, numbers with small digits, in unusual bases Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-315) A/1/876 Numbers, esp. negative, in comma-separated lists Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-876) A/1/1599 Synthetic math: Numbers that we will need to answer whether it is composite/prime or divides other numbers Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1599) A/1/2019 Synthetic math: Numbers or fractions that are to be sorted Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2019) A/1/2489 Synthetic math: problem involving division Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2489) A/1/2867 Synthetic math: Numbers in math problems Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2867) A/1/3306 Mathematical sequences (numbers separated by ", ") Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3306) A/1/3354 Synthetic math: Numbers in math problems involving rounding Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3354) A/1/1441 "}{-" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1441) A/1/3814 Code: fileID, maybe numeric values in "key:value" more generally Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3814) A/1/635 Double-pipe delimited data Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-635) A/1/1416 "**" in [context] Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1416) A/1/810 Numbers near Japanese and/or " -->" arrows Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-810) A/1/3305 Bug ids (mostly in URLs but also outside of URLs in context too) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3305) A/1/3076 Numbers written in exponential notation (but not the "E", which is predicted) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3076) A/1/2687 Markdown footnotes Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2687) Cluster #134 A/0/301 The feature seems to attend to headers of different sections in text, it especially activates on section headers containing numbers and horizontal lines/dashes below the headers. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-301) A/1/693 "######" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-693) A/1/728 Lots of dashes separating sections in LaTeX Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-728) A/1/2180 "================================" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2180) A/1/2298 Legal discovery emails, esp. "@" in "ECT@ECT" (Enron emails) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2298) A/1/2761 "Introduction" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2761) A/1/3341 "![" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3341) A/1/3514 "References" / other headers surrounded by (double) newlines Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-3514) Cluster #102 A/0/110 This feature appears to attend to numbers. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-110) A/1/10 Numbers after 3-ish newlines (legal contexts?) Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-10) A/1/2504 1–2 digit tokens, esp. after double newlines, sometimes after other punctuation Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2504) Cluster #135 A/0/347 This feature seems to fire on backslashes, quotes, hyphens, newlines, parentheses and other punctuation. It is particularly attentive to common punctuation around citations, code, equations, lists, tables, headings, and other text formatting. Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a0.html#feature-347) A/1/1513 EOT at start Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1513) A/1/2754 EOT in middle Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-2754) A/1/1033 Long runs of hyphens" Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1033) A/1/1807 US court case numbers Zoom to [↗ View details](https://transformer-circuits.pub/2023/monosemantic-features/vis/a1.html#feature-1807) Cluster #128 A/0/87 This feature seems to fire when there are code snippets and programming language examples in the text, especially with programming keywords like "try", "catch", "method", "class", etc. or symbols like curly braces ({}), tabs/whitespace, backticks () and newlines (\n). There also seems to be a preference for C# and Java examples. Zoom to ↗ View details A/0/323 This feature fires when it detects the presence of a question followed by a new line, indicated by the \n token. The feature seems to specifically look for questions in a Q&A format, with the question preceded by "Q:" and followed by a new line. Some of the strongest activations occur when a question is formatted in this way: Q: \n [question] The feature also seems to fire on multiple new line tokens (\n\n), indicating a double space after the question. While the feature responds most strongly to typical phrasing of "Q:" followed by the question, it also activates to some degree for other question-related words like "Why," "What," etc. So in summary, the feature is detecting a specific formatting pattern of questions in a Q&A context, looking for "Q:", new lines, and the content of the question. Zoom to ↗ View details A/1/717 Q before a : at the start of a sequence Zoom to ↗ View details A/1/1726 Title-Case metadata-ish nouns like "Title", "Name", or "Location" Zoom to ↗ View details A/1/2740 "0" or some other numbers after <EOT> Zoom to ↗ View details A/1/4036 "External" Zoom to ↗ View details A/1/2163 US Court of Appeals Zoom to ↗ View details A/1/377 Legal docs: Citation numbers in square brackets Zoom to ↗ View details A/1/2721 Legal docs Zoom to ↗ View details A/1/449 Period in legal docs, especially conflict of interest? Zoom to ↗ View details Cluster #123 A/1/1927 ".", sometimes with preceding punctuation, in legal contexts Zoom to ↗ View details A/1/2404 "." in [context] Zoom to ↗ View details A/1/3231 "." in "v." (legal cases) Zoom to ↗ View details Cluster #96 A/0/405 The feature fires when sentences end with punctuation (e.g. period, question mark, exclamation mark). Zoom to ↗ View details A/1/1653 "." in [context] Zoom to ↗ View details A/1/2311 Period in mathematical proofs Zoom to ↗ View details A/1/2584 "." in [context] Zoom to ↗ View details A/1/3425 "." in [context] Zoom to ↗ View details A/1/3036 "." in [context] Zoom to ↗ View details Cluster #122 A/0/250 This feature fires when it sees case law citations. Zoom to ↗ View details A/0/346 This feature fires on abbreviations that are followed by periods such as "S." and "e.g.". Zoom to ↗ View details A/1/125 "." after "Dr" and few other honorifics Zoom to ↗ View details A/1/741 "." in [context] Zoom to ↗ View details A/1/1061 "." in [context] Zoom to ↗ View details A/1/1206 "." in [context] Zoom to ↗ View details A/1/1432 "." in [context] Zoom to ↗ View details A/1/1548 "." in [context] Zoom to ↗ View details A/1/1697 "." in abbreviations for legal citations Zoom to ↗ View details A/1/1783 "." in legal/formal abbreviations? Zoom to ↗ View details A/1/2373 "." in [context] Zoom to ↗ View details A/1/2642 "." in [context] Zoom to ↗ View details A/1/3520 "." after single letters, likely abbreviations ("i.e.", "e.g.", "p.") Zoom to ↗ View details A/1/3950 "." in [context] Zoom to ↗ View details A/1/4035 "." in [context] Zoom to ↗ View details A/1/2794 "." after initials of people (in academic contexts / citations?) Zoom to ↗ View details Cluster #91 A/0/376 This feature attends to citations of journal publications in the format "<Last name>, <Initials.>, <Publication name>, <Volume number> (<Year>)." Zoom to ↗ View details A/1/1060 "." in [context] Zoom to ↗ View details A/1/1343 ".," in [context] Zoom to ↗ View details A/1/1438 ")." suffixing a year, in a bibliography/citation context Zoom to ↗ View details A/1/1608 "]{}," Zoom to ↗ View details A/1/1640 " [" Zoom to ↗ View details A/1/2079 "." in abbreviations of chemistry/physics journals? Zoom to ↗ View details A/1/3796 "." in [context] Zoom to ↗ View details Cluster #69 A/1/1045 " \u00a7" Zoom to ↗ View details A/1/1125 Numbers inside of [NUM]{} citations Zoom to ↗ View details A/1/2533 Page numbers in citations Zoom to ↗ View details A/1/2865 " \u00b6" Zoom to ↗ View details Cluster #78 A/1/2173 " See" Zoom to ↗ View details A/1/3138 Patent Numbers Zoom to ↗ View details A/1/4006 " also" of "See also" Zoom to ↗ View details Cluster #81 A/0/22 This feature attends to references to sections and subsections of legal documents, such as statutes, patent numbers, court cases, etc. Zoom to ↗ View details A/0/169 This feature seems to attend to text that shows dates and days of the week, often in news-like contexts such as headlines. Zoom to ↗ View details A/1/61 Legal: ends of case numbers Zoom to ↗ View details A/1/136 Legal numbers after " at" Zoom to ↗ View details A/1/183 " v" in "v." (legal cases) Zoom to ↗ View details A/1/789 Numbers in legal citations, usually after "," and predicting a court Zoom to ↗ View details A/1/1489 Section number (after "section" or "§", esp. after "Code") Zoom to ↗ View details A/1/1559 "d" Zoom to ↗ View details A/1/1659 Legal digit esp. after "F." before "d" Zoom to ↗ View details A/1/1761 Supreme Court case numbers Zoom to ↗ View details A/1/1806 " Id" Zoom to ↗ View details A/1/2132 " Cir" Legal Citation Zoom to ↗ View details A/1/2222 This feature fires on parenthetical citations with a year inside such as (2002). Zoom to ↗ View details A/1/2706 Months in dates, predicting days of months Zoom to ↗ View details A/1/3749 Space and digit after "X v. Y," court case citations Zoom to ↗ View details A/1/3755 " supra" Zoom to ↗ View details A/1/4059 Numerical day of a date (Month day, day Month, Month day'th, etc) Zoom to ↗ View details A/1/398 "." in [context] Zoom to ↗ View details A/1/787 "." in "Fig." (predicting a figure number) Zoom to ↗ View details A/1/1612 "." in [context] Zoom to ↗ View details A/1/1512 Supplementary data in papers Zoom to ↗ View details Cluster #94 A/0/378 This feature fires on the label "Fig." that usually precedes a figure number in academic papers. Zoom to ↗ View details A/1/278 " Fig" Zoom to ↗ View details A/1/1531 " Table" Zoom to ↗ View details A/1/2488 " FIG" Zoom to ↗ View details A/1/3723 " Eq" before an equation reference Zoom to ↗ View details Cluster #95 A/0/238 This feature attends to citations of figures in academic papers. Zoom to ↗ View details A/1/265 Short table names (" S" in "Table S1.") Zoom to ↗ View details A/1/282 ""}" Zoom to ↗ View details A/1/362 "Fig" Zoom to ↗ View details A/1/3070 Figure numbers (after "Figure"/"Fig"/...) Zoom to ↗ View details A/1/370 "[", especially after "Fig. " Zoom to ↗ View details A/1/543 Letters in figure names that are parenthesized or bracketed, like "[Figure 4A]" Zoom to ↗ View details A/1/3675 Many hyphens Zoom to ↗ View details A/1/353 Chemical molecular data, showing atoms, bonds, and geometry, near many spaces and "---" Zoom to ↗ View details A/1/283 "/" as dimensional units "x per y" Zoom to ↗ View details Cluster #129 A/0/465 This feature attends to lines and horizontal lines in particular. Zoom to ↗ View details A/1/2051 Many hyphens Zoom to ↗ View details A/1/3868 Whitespace, often right after EOT Zoom to ↗ View details A/1/3880 Long runs of spaces in medical reports? Zoom to ↗ View details Cluster #26 A/0/160 This feature fires for square or curly brackets [ ] { }. The brackets are mostly used for citations, references, links, math expressions, arrays, lists, and occasionally for emphasis or indicating action. Zoom to ↗ View details A/1/473 "[" in [context] Zoom to ↗ View details A/1/1229 " (**" Zoom to ↗ View details A/1/2949 " [" in [context] Zoom to ↗ View details A/1/3291 " ([" Zoom to ↗ View details A/1/702 { and ^{ in LaTeX Zoom to ↗ View details Cluster #25 A/0/229 This feature attends to parentheses () in the text. Zoom to ↗ View details A/1/457 " (" in [context] Zoom to ↗ View details A/1/536 Opening parenthesis after name or institution, where the parenthesis often contains a date Zoom to ↗ View details A/1/929 Open parentheses after more than one newline Zoom to ↗ View details A/1/1065 " (" in an informal narrative or commentary Zoom to ↗ View details A/1/1259 " (" Citation, Reference, or Note Zoom to ↗ View details A/1/1491 [Ultralow density cluster] Zoom to ↗ View details A/1/2276 " (" medical/epidemiological context with a focus on statistical analysis Zoom to ↗ View details A/1/2943 " (" in a math/physics technical paper Zoom to ↗ View details A/1/3064 "(" in a legal context referencing a particular clause: ie "924(c)(1)" Zoom to ↗ View details A/1/3365 " (" in a legal/judicial context Zoom to ↗ View details A/1/3449 " (" in [context] Zoom to ↗ View details A/1/3689 Open parentheses with no leading space, often in math notation or chemical formulas Zoom to ↗ View details A/1/3776 " (" in a medical/biological context with a focus on biological terms/parenthetical-acronyms Zoom to ↗ View details A/1/3844 " (" in a software-development/technical document Zoom to ↗ View details Cluster #21 A/0/52 This feature attends to acronyms in parentheses. Zoom to ↗ View details A/0/249 The feature attends to parentheticals, which are phrases or clauses set off by parentheses or other punctuation marks. Zoom to ↗ View details A/1/157 Letter after opening parenthesis, particularly "(i.e.)" or "(e.g.)" Zoom to ↗ View details A/1/292 Parenthesized numbers of quantities/units Zoom to ↗ View details A/1/768 Short lowercase word after "(", esp. in English prose mid-sentence Zoom to ↗ View details A/1/1457 Single lower case letter in parentheses Zoom to ↗ View details A/1/2204 "see" Zoom to ↗ View details A/1/2248 Years in parentheses, esp. citations Zoom to ↗ View details A/1/2296 Words inside parenthetical expressions that could be the end of the parenthetical phrase, predicting punctuation including ")" Zoom to ↗ View details A/1/2553 Text in parentheses, esp. proper nouns Zoom to ↗ View details A/1/2673 Parenthesized abbreviations (abbreviating the preceding text?) Zoom to ↗ View details A/1/2842 This feature activates most strongly when it sees the presence of mathematical functions and equations, signified by characters like parentheses, exponents, division signs, etc. Zoom to ↗ View details A/1/3088 "0" in [context] Zoom to ↗ View details A/1/3096 "," in [context] Zoom to ↗ View details A/1/3466 Words inside parentheses, esp. right after open parentheses, in medical/experimental contexts Zoom to ↗ View details A/1/4074 Numbered citations/footnotes Zoom to ↗ View details A/1/3990 " \u00b1" Zoom to ↗ View details Cluster #138 A/0/313 This feature attends to numbers with decimal points representing measurements such as weight or concentration. Zoom to ↗ View details A/1/2140 " **" in [context] Zoom to ↗ View details A/1/3162 "--" Zoom to ↗ View details Cluster #140 A/0/472 This feature fires for numbers formatted with spacing around the decimal points. Zoom to ↗ View details A/1/59 " \u23ce\n "/" \u23ce\n "/"\u23ce\n "/"\u23ce\n " in [context] Zoom to ↗ View details A/1/166 Long runs of whitespace near numbers/statistics Zoom to ↗ View details A/1/404 " "/" "/" "/" "/" "/" "/" " in [context] Zoom to ↗ View details A/1/726 Runs of whitespace in medical contexts? Zoom to ↗ View details A/1/1178 " "/" "/" "/" "/" "/" " in [context] Zoom to ↗ View details A/1/1453 Long spaces next to escaped arithmetic operators, potentially in tables? Zoom to ↗ View details A/1/3028 " =" in [context] Zoom to ↗ View details A/1/3808 " ×" in numeric dimension pairs Zoom to ↗ View details A/1/2377 "---" Zoom to ↗ View details A/1/1382 " "/" "/" "/" "/" " in [context] Zoom to ↗ View details A/1/3504 Capital letters and/or punctuation predicting 3-digit numbers? Zoom to ↗ View details Cluster #137 A/0/88 This feature seems to fire on numbers, punctuation like parentheses, commas, periods, colons, and mathematical operators like +, -, =. Zoom to ↗ View details A/1/88 Closing parenthesis after number predicting run of space Zoom to ↗ View details A/1/3567 Punctuation or tokens preceding "fn" referring to footnotes in {} citation format Zoom to ↗ View details A/1/134 " vs" / "versus" etc. Zoom to ↗ View details A/1/133 Hebrew?: mojibake UTF-8 as latin1? Zoom to ↗ View details A/1/712 " " when used in sequence with additional "" and " * tokens, in comments Zoom to ↗ View details A/1/3040 " ", usually as markdown bold delimiters Zoom to ↗ View details Cluster #139 A/0/400 The feature attends to tables and formatting, specifically numbers, text alignment, and punctuation. Zoom to ↗ View details A/1/1424 Numbers and punctuation near numbers, often "%)" Zoom to ↗ View details A/1/2424 Human body or medical supply related, near and predicting long runs of spaces Zoom to ↗ View details A/1/2781 " \<" Zoom to ↗ View details A/1/3885 "" in [context] Zoom to ↗ View details A/0/477 This feature appears to attend to text containing various symbols like parentheses, dollar signs, percent signs, asterisks, hashtags, tildes, etc. Often there is math notation or references to figures/tables. Zoom to ↗ View details A/1/819 "," in [context] Zoom to ↗ View details Cluster #136 A/0/67 The feature fires when it sees numbers. Zoom to ↗ View details A/1/1510 Digits, usually 2 or 3, after the decimal point in such numbers separated by many spaces Zoom to ↗ View details A/1/3467 " 0" in [context] Zoom to ↗ View details A/1/3756 Predicting whitespace after legal citations Zoom to ↗ View details Cluster #89 A/0/247 The feature fires when it sees dates formatted as two-digit to four-digit numbers representing years between 1900-2020. Zoom to ↗ View details A/1/869 A year, in talking about history and what happened Zoom to ↗ View details A/1/1634 Years, 19xx or 20xx, often in citations of journals and the like Zoom to ↗ View details A/1/642 "" in [context] Zoom to ↗ View details A/1/834 ANOVA and related statistical tests Zoom to ↗ View details A/1/66 [Ultralow density cluster] Zoom to ↗ View details Cluster #131 A/0/94 The feature attends to numbers with decimals in scientific writing. Zoom to ↗ View details A/0/242 This feature fires when it sees statistical symbols and formatting, particularly p-values, standard error, and statistical significance indicators. Zoom to ↗ View details A/1/469 Numbers in percentages Zoom to ↗ View details A/1/709 Digits after the decimal point after "=" in parentheses Zoom to ↗ View details A/1/2793 Numbers after/near " ±" Zoom to ↗ View details A/1/3233 "%" in [context] Zoom to ↗ View details A/1/3887 " C" in [context] Zoom to ↗ View details Cluster #90 A/0/261 This feature attends to numbers between 20-50. Zoom to ↗ View details A/1/224 " million"/" billion" big numbers or things measured in such quantities Zoom to ↗ View details A/1/235 Various European languages: Number text Zoom to ↗ View details A/1/740 Page numbers esp. in page ranges Zoom to ↗ View details A/1/828 Numbers after Title-Case nouns suggesting sections of a larger work, like "Volume" or "Issue" Zoom to ↗ View details A/1/867 Single letters, esp. lowercase, immediately after numbers Zoom to ↗ View details A/1/954 Inline numbers in English text, esp. >2 digits predicting measurements/units Zoom to ↗ View details A/1/1126 This feature fires on numbers that contain a 1, 4 or 8 in the tenths or hundredths place. Zoom to ↗ View details A/1/1209 Digits in mixed digits/uppercase letter sequences (uppercase base36 maybe) Zoom to ↗ View details A/1/1862 Small single-digit numbers (as Arabic numerals) Zoom to ↗ View details A/1/1992 Numbers in English sentences Zoom to ↗ View details A/1/2026 ~2-digit numbers (ages, page numbers) Zoom to ↗ View details A/1/2448 Numbers in Bible verse citations (separated by colons) Zoom to ↗ View details A/1/2634 This feature attends to numbers greater than or equal to 100. Zoom to ↗ View details A/1/2820 Numbers after " in"/" on" etc., predicting months Zoom to ↗ View details A/1/3703 Numeric dollar amounts, after "$" Zoom to ↗ View details A/1/3902 This feature fires when it sees numbers and letter combinations that appear to be vehicle, product or model numbers. Zoom to ↗ View details A/1/908 "" in [context] Zoom to ↗ View details A/1/226 "^" in Markdown-style superscripts in chemistry? Zoom to ↗ View details Cluster #110 A/0/152 This feature attends to numerical values and measurements. Zoom to ↗ View details A/1/1183 Nuclear Magnetic Resonance Zoom to ↗ View details A/1/1954 " 0" in [context] Zoom to ↗ View details A/1/2100 Space + 2 or 3 digit number, inline in English prose (mechanical engineering?) Zoom to ↗ View details A/1/2337 ~2-digit numbers in medical studies Zoom to ↗ View details A/1/2394 Numbers of units after the decimal point Zoom to ↗ View details A/1/2812 " 1" Zoom to ↗ View details A/1/2857 Numbers before acronyms/units in scientific papers Zoom to ↗ View details A/1/3284 1 to 3 digit numbers, often scientific measurements/units Zoom to ↗ View details A/1/2210 "~" in chemistry Markdown subscripts Zoom to ↗ View details A/1/533 This feature fires when it sees exponents, superscripts, and other mathematical notation. Zoom to ↗ View details Cluster #111 A/0/51 The feature fires when it detects scientific notation and chemical formulae. Zoom to ↗ View details A/1/154 Badly formatted math operators Zoom to ↗ View details A/1/816 ~2-digit numbers in scientific contexts, predicting various units Zoom to ↗ View details A/1/1465 Numbers in Markdown ("~") subscripts near single capital letters (chemistry?) Zoom to ↗ View details A/1/2167 Code: double-asterisk-emphasized numbers and letters Zoom to ↗ View details A/1/2362 " \u00b0" Zoom to ↗ View details A/1/1162 " (" Preceding Roman Numeral Zoom to ↗ View details A/1/461 Code: HTML & escape character before lt/gt/nbsp/quot/amp Zoom to ↗ View details A/1/2877 Punctuation in JSON-like data, regexes... predicting single digits Zoom to ↗ View details Cluster #39 A/0/466 This feature attends to the ampersand symbol (&). Zoom to ↗ View details A/1/393 [Ultralow density cluster] Zoom to ↗ View details A/1/4013 LaTeX table (delimiters?) Zoom to ↗ View details Cluster #38 A/0/407 This feature fires on numeric values, including both integers and decimals. Zoom to ↗ View details A/1/388 Numbers in LaTeX tables Zoom to ↗ View details A/1/878 Whitespace esp. near/between LaTeX math mode expressions Zoom to ↗ View details A/1/1122 Base-ten numbers, especially decimal, negative, and in comma-separated lists without spaces Zoom to ↗ View details A/1/2351 Numbers and some English/abbreviations, separated by and predicting & (LaTeX?) Zoom to ↗ View details A/1/2393 Numbers in (X,Y) pairs? (coordinate-based plotting?) Zoom to ↗ View details A/1/1670 Punctuation tokens in math ending with "(" and near "x" Zoom to ↗ View details A/1/1991 Math notation, synthetic math operators, or LaTeX near the letter "w" Zoom to ↗ View details A/0/287 This feature attends to LaTeX code blocks. Zoom to ↗ View details A/1/488 Newline-spaces in LaTeX commands Zoom to ↗ View details Cluster #63 A/0/146 This feature attends to LaTeX math expressions containing fractions. Zoom to ↗ View details A/0/228 This feature seems to fire for dollar signs ($) used in mathematical formulas and equations. Zoom to ↗ View details A/0/303 This feature attends to mathematical expressions, especially those containing Greek letters, math symbols, and formulas. Zoom to ↗ View details A/0/340 This feature attends to subscripts that use curly braces such as C{D}. Zoom to ↗ View details A/0/470 This feature attends to subscripts of mathematical variables. Zoom to ↗ View details A/0/501 This feature attends to mathematical equations and formulas that contain exponents. Zoom to ↗ View details A/1/167 "^{" Zoom to ↗ View details A/1/237 LaTeX: "-" in math mode (subtraction) esp. superscripts or subscripts Zoom to ↗ View details A/1/330 LaTeX: " =" assigning a variable Zoom to ↗ View details A/1/345 "{" in LaTeX after mbox/hbox/text/... Zoom to ↗ View details A/1/364 Synthetic math: operators near "f" Zoom to ↗ View details A/1/444 "{" in [context] Zoom to ↗ View details A/1/813 "(" and other opening delimiters after LaTeX "\left" Zoom to ↗ View details A/1/931 Backslashes predicting "u" in Unicode character escapes Zoom to ↗ View details A/1/1089 Synthetic math: parentheses and arithmetic near "c" Zoom to ↗ View details A/1/1181 "{" in [context] Zoom to ↗ View details A/1/1233 LaTeX begin inline math Zoom to ↗ View details A/1/1256 Predicting Short Math Variable Zoom to ↗ View details A/1/1328 "{" in [context] Zoom to ↗ View details A/1/1754 Math punctuation near/predicting "n" Zoom to ↗ View details A/1/1768 LaTeX subscripts with preceding punctuation, predicting "i", "j", etc. Zoom to ↗ View details A/1/1923 " $" in [context] Zoom to ↗ View details A/1/1955 LaTeX: "" used for subscript Zoom to ↗ View details A/1/1982 " $" in [context] Zoom to ↗ View details A/1/2263 LaTeX: Underscores and similar punctuation, predicting digits Zoom to ↗ View details A/1/2316 "^" in [context] Zoom to ↗ View details A/1/2405 "," in [context] Zoom to ↗ View details A/1/3180 "}{" in [context] Zoom to ↗ View details A/1/3248 Synthetic math: "" in polynomials etc Zoom to ↗ View details A/1/3403 "{" in [context] Zoom to ↗ View details A/1/3529 Open parentheses in LaTeX? Zoom to ↗ View details A/1/3569 Parens, brackets, subscripts, and mathematical operators, predicting a variable "k" Zoom to ↗ View details A/1/3632 Mostly capital letter fragments predicting X, Y, Z Zoom to ↗ View details A/1/3889 "{" in [context] Zoom to ↗ View details A/1/3952 Operators and punctuation in math near/predicting "q" Zoom to ↗ View details A/1/3976 "=" in [context] Zoom to ↗ View details A/1/871 Letters near "+", often but not always scientific notation "1e+5" Zoom to ↗ View details A/1/1017 LaTeX esp. opening braces Zoom to ↗ View details Cluster #58 A/0/416 This feature fires on math equations written in LaTeX. Zoom to ↗ View details A/1/375 LaTeX: Curly brace in setting mathbb font Zoom to ↗ View details A/1/399 "}{" in LaTeX, esp. array environments Zoom to ↗ View details A/1/678 "{" in [context] Zoom to ↗ View details A/1/1664 "{" in [context] Zoom to ↗ View details A/1/1105 Punctuation in LaTeX Zoom to ↗ View details A/1/1275 LaTeX measurements Zoom to ↗ View details A/1/1135 Capital letters or punctuation near/predicting "G" Zoom to ↗ View details A/1/1947 "}" in [context] Zoom to ↗ View details A/1/107 LaTeX math environment names Zoom to ↗ View details Cluster #34 A/0/312 This feature fires on text snippets that contain LaTex syntax. In particular, it appears to be attending to structural elements like section headers, equations, references, and formatting. Zoom to ↗ View details A/0/316 This feature attends to LaTeX math notation. Zoom to ↗ View details A/1/55 "}" in [context] Zoom to ↗ View details A/1/273 "]{" in LaTeX Zoom to ↗ View details A/1/679 LaTeX: " \"/"\" in [context] Zoom to ↗ View details A/1/943 "}" in [context] Zoom to ↗ View details A/1/1076 "}" in [context] Zoom to ↗ View details A/1/1205 "}" in [context] Zoom to ↗ View details A/1/2381 "12" Zoom to ↗ View details A/1/2778 "}" in [context] Zoom to ↗ View details A/1/3490 "{" in [context] Zoom to ↗ View details A/1/3981 "was" Zoom to ↗ View details Cluster #47 A/0/329 The feature attends to LaTeX math environments, equations, and symbols. Zoom to ↗ View details A/0/418 This feature fires for LaTeX math mode environments, equations, theorems, tables, figures, algorithms, etc. Zoom to ↗ View details A/1/113 " [" Zoom to ↗ View details A/1/1132 LaTeX equation tags Zoom to ↗ View details A/1/1283 Citations and references after (\[, predicting \]) Zoom to ↗ View details A/1/1461 " (\\[" Zoom to ↗ View details A/1/2205 Filenames in maybe Markdown link targets? Zoom to ↗ View details A/1/3543 "{" esp. in LaTeX labels Zoom to ↗ View details A/1/3578 " \\[" Zoom to ↗ View details A/1/3587 ":" in [context] Zoom to ↗ View details A/1/3660 Markup references to tables/algorithms/etc., in brackets before colons Zoom to ↗ View details Cluster #27 A/0/21 This feature fires when it sees brackets [] around numbers, letters and variable names. Zoom to ↗ View details A/1/396 Code: Single-digit numbers in square-bracket array indexing Zoom to ↗ View details A/1/3505 English in [square brackets] Zoom to ↗ View details A/1/2094 "$-", sometimes with prior punctuation, joining hyphenated LaTeX-math-and-word forms Zoom to ↗ View details A/1/212 "." surrounding sub/sup for subscript/superscript formatting requests Zoom to ↗ View details A/1/359 Data Label prefixes: basically of the form: .[]{data-label=" Zoom to ↗ View details A/1/999 LaTeX tokens after open square brackets (left ends of intervals, etc.) Zoom to ↗ View details A/1/3275 LaTeX formatting Zoom to ↗ View details A/1/3863 "amsmath" Zoom to ↗ View details A/1/851 Code: identifiers (variables, key or field names) in curly braces Zoom to ↗ View details Cluster #292 A/0/259 This feature fires when it sees mathematical symbols and equations such as dollar signs, subscripts, fractions, greek letters, parentheses, etc. Zoom to ↗ View details A/1/402 "}$$" Zoom to ↗ View details A/1/638 This feature fires when equations (written in LaTeX or MathML format) are present in the text. Zoom to ↗ View details A/1/1507 "\\]" Zoom to ↗ View details A/1/2266 Closing LaTeX math mode Zoom to ↗ View details A/1/3912 This feature attends to mathematical symbols and formulas like variables, operators, functions, fractions etc. Zoom to ↗ View details A/1/1475 "$" in [context] Zoom to ↗ View details Cluster #291 A/0/40 The feature attends to mathematical notation such as inline formulas, equations, theorems, proofs, symbols, Greek letters, subscripts, and other math syntax. Zoom to ↗ View details A/1/175 " Let" in/near math or LaTeX Zoom to ↗ View details A/1/879 " Then"/" then" in [context] Zoom to ↗ View details A/1/3557 Prepositions near LaTeX math Zoom to ↗ View details A/1/3873 " that" LaTeX Scientific Zoom to ↗ View details A/1/3646 Numeric tokens, sometimes after all-caps abbreviations/identifiers Zoom to ↗ View details A/1/1474 'follows' in logic, usually related to code Zoom to ↗ View details A/1/549 " such" in [context] Zoom to ↗ View details A/1/437 Mathematical quantifier, e.g. " some"/" any"/" every" after "for", near LaTeX and predicting " $" Zoom to ↗ View details A/1/1195 This feature attends to mathematical formulas. Zoom to ↗ View details A/1/1268 " Proposition"/" Theorem"/capitalized words for mathematical statements Zoom to ↗ View details A/1/936 Prepositions and relational verbs, esp. at beginnings of sentences in LaTeX/math-related contexts, predicting " Eq" or math mode starting Zoom to ↗ View details Cluster #307 A/0/281 This feature attends to mathematical terminology and notation related to abstract algebra, especially homomorphisms, isomorphisms, and topological spaces. Zoom to ↗ View details A/1/491 Topology, abstract algebra Zoom to ↗ View details A/1/1661 Advanced physics (mostly GR, but some QFT) Zoom to ↗ View details A/1/2595 Abstract adjectives in math: " convex", " regular", " arbitrary", etc. Zoom to ↗ View details A/1/3740 Astronomical bodies and related phrases: stars, galaxies, dwarfs, pulsars, etc Zoom to ↗ View details A/1/3847 Adjectives in math / linear algebra: " linear" etc. Zoom to ↗ View details A/1/1932 [Ultralow density cluster] Zoom to ↗ View details A/1/2871 High energy physics Zoom to ↗ View details Cluster #308 A/0/84 This feature attends to technical language related to physics and astronomy, looking for words and phrases related to brightness, luminosity, energy, and associated units of measurement. Zoom to ↗ View details A/1/588 [Ultralow density cluster] Zoom to ↗ View details A/1/3711 Galactic astronomy (prepositions) Zoom to ↗ View details A/1/1950 " between"/" through"/similar prepositions in electromagnetics/quantum physics? Zoom to ↗ View details A/0/103 The feature fires in response to usage of the preposition "by" in contexts describing mathematical or scientific processes. Zoom to ↗ View details A/1/1555 Abstract verbs or endings, as might be done to equations or expressions, in math / theoretical physics? (" solve", " compute" etc.) Zoom to ↗ View details A/1/3429 " of" in [context] Zoom to ↗ View details Cluster #293 A/0/239 This feature seems to attend to mathematical expressions, formulas, and equations. Zoom to ↗ View details A/1/1626 " Note" Zoom to ↗ View details A/1/2979 Math nouns, predicting inline LaTeX Zoom to ↗ View details A/1/3090 This feature appears to activate when numbers or mathematical symbols appear in the context of equations, matrices, vectors, norms, spaces, parameters, eigenvalues, functions, etc. Zoom to ↗ View details A/1/3542 " theorem", " section", and other parts/units of math papers Zoom to ↗ View details A/1/3761 The feature appears to fire on symbols and terminology associated with mathematical expressions, equations, operators, and concepts. Zoom to ↗ View details A/1/3975 [Ultralow density cluster] Zoom to ↗ View details A/1/4054 Abstract nouns in mathematics after "the" Zoom to ↗ View details Cluster #295 A/0/318 This feature fires when it sees the word "the" in the token immediately preceding a technical term. Zoom to ↗ View details A/0/341 This feature seems to attend to mathematical expressions involving the word "the". Many of the highest activations contain math equations, formulas, or terminology with "the" present. Zoom to ↗ View details A/1/512 " a" in the context of math, expected to be followed by a math word. E.g. "a subset" or "a Hilbert space" Zoom to ↗ View details A/1/1078 " the" in physics, esp electromagnetism? Zoom to ↗ View details A/1/1452 " the" in theory of machine learning / statistics Zoom to ↗ View details A/1/1638 " the" in math (advanced geometry? algebra?) Zoom to ↗ View details A/1/1652 " The" in [context] Zoom to ↗ View details A/1/1780 " the" in astrophysics? Zoom to ↗ View details A/1/3362 " the" in mathematics/physics/dynamical systems? Zoom to ↗ View details A/1/2183 Astronomy, especially solar-system Zoom to ↗ View details A/1/976 " a" in physics or other sciences contexts Zoom to ↗ View details A/1/3503 Famous mathematicians, predicting things named after them like " theorem" Zoom to ↗ View details A/1/1637 " for" in [context] Zoom to ↗ View details A/1/2395 " such" in [context] Zoom to ↗ View details A/1/1811 The feature fires when it sees scientific terms or concepts. Zoom to ↗ View details Cluster #304 A/0/357 This feature attends to words related to Coulomb interactions in a physics context. Zoom to ↗ View details A/1/128 Physics relating to motion and change: speed, rising/falling, developing/unstable/steady, etc Zoom to ↗ View details A/1/342 " electron" Zoom to ↗ View details A/1/1558 " of" in [context] Zoom to ↗ View details A/1/2878 Key actions, operands and logical constructs that are part of statistical analysis / modeling (prose) Zoom to ↗ View details A/1/3502 " with" in math (esp. geometry?) Zoom to ↗ View details Cluster #285 A/0/315 This feature attends to hyphens appearing in scientific writing. Zoom to ↗ View details A/1/216 Abstract nouns like "stability" in numerical systems, astrophysics, etc. Zoom to ↗ View details A/1/823 Graph theory (esp. adjectives) Zoom to ↗ View details A/1/3158 Nouns in math, esp. linear algebra ("matrix", "vector") Zoom to ↗ View details A/1/3435 Neuron networks/machine learning (prose) Zoom to ↗ View details A/1/1164 " function", esp. in biology Zoom to ↗ View details A/1/541 Physics-related noun of a particular flavor, e.g. "curvature", "velocity", "lattice", "transition" Zoom to ↗ View details A/1/341 This feature attends to scientific terminology related to dynamics, structures, gradients, perturbations, equations, behaviors, and parameters. Zoom to ↗ View details Cluster #277 A/0/16 This feature fires on word endings that describe geometric shapes and locations. Zoom to ↗ View details A/0/210 This feature fires when it sees technical terms and concepts commonly found in physics and engineering documents, particularly those related to optics and lasers. Zoom to ↗ View details A/1/65 " wave" Zoom to ↗ View details A/1/322 Physics (Optics) Zoom to ↗ View details A/1/2112 " horizontal"/" vertical" geometry? Zoom to ↗ View details A/1/3733 Graphics processing? Zoom to ↗ View details A/1/2134 " respectively" Zoom to ↗ View details A/1/118 Statistics (English text) Zoom to ↗ View details A/1/272 Abstract nouns esp related to paths in astronomy Zoom to ↗ View details Cluster #16 A/0/63 This feature fires when the word "according" is followed by the word "to". Zoom to ↗ View details A/1/890 " according" in [context] Zoom to ↗ View details A/1/1403 "According" Zoom to ↗ View details A/1/2064 " according" in [context] Zoom to ↗ View details A/1/1518 Graph/diagram-related nouns (curves, lines, squares, diagrams) Zoom to ↗ View details A/1/2744 Functions of mechanical systems / devices Zoom to ↗ View details A/1/800 " invention" Zoom to ↗ View details Cluster #276 A/0/31 The feature attends to text related to semiconductor transistors with respect to their components and fabrication. Zoom to ↗ View details A/0/129 This feature attends to technical language describing the physical structure or form of mechanical objects. Zoom to ↗ View details A/0/306 This feature attends to descriptions of rotating mechanical parts such as shafts, knobs, axles, and gears. Zoom to ↗ View details A/1/365 Prepositions and abstract verbs in mechanical engineering? metalworking? Zoom to ↗ View details A/1/521 Printing / recording / photographing Zoom to ↗ View details A/1/685 "relates to" (and similar phrases) in patent filings. Zoom to ↗ View details A/1/915 HVAC Zoom to ↗ View details A/1/1319 English nouns for mechanical components, predicting numbers (patents?) Zoom to ↗ View details A/1/1742 Semiconductors / Computer Manufacturing Zoom to ↗ View details A/1/2127 " crystal" Zoom to ↗ View details A/1/2485 English (Signal Processing) Zoom to ↗ View details A/1/3074 Material science phrases Zoom to ↗ View details A/1/3227 Electrical engineering Zoom to ↗ View details A/1/3792 Engineering devices (circuit, lamp, disk drive, instrument, device) Zoom to ↗ View details A/1/3901 Adjectives describing geometries of mechanical connections Zoom to ↗ View details A/1/3230 Concurrency, multiprocessing? Zoom to ↗ View details Cluster #259 A/0/81 This feature fires on text talking about technical concepts related to electronic communication, signal processing, and data transmission. Zoom to ↗ View details A/1/233 CPU architecture Zoom to ↗ View details A/1/307 Computer networking concepts Zoom to ↗ View details A/1/1841 Connector words in electronic storage/protocols Zoom to ↗ View details A/1/2066 Wireless networks Zoom to ↗ View details A/1/2096 " surface" Zoom to ↗ View details A/1/1166 Nouns or word fragments in biology, esp. animals or fungi Zoom to ↗ View details A/1/3631 " needle" and broadly similar nouns in sewing/crafting Zoom to ↗ View details A/1/2907 Abstract nouns in medicine and physics, often related to filtering Zoom to ↗ View details A/1/1301 Generic, inspecific terms for mechanical, biomechanical, and electronic components Zoom to ↗ View details A/1/1034 Words in scientific text, esp. atomic chemistry Zoom to ↗ View details A/1/3322 "aid" in "Chinese/Japanese Patent [Application] Laid-Open" Zoom to ↗ View details Cluster #272 A/0/254 The feature appears to fire on words and phrases related to chemical processes. Zoom to ↗ View details A/1/373 Excerpts from technical documents describing polymer chemistry processes and properties Zoom to ↗ View details A/1/2910 " with"/" containing" in chemistry Zoom to ↗ View details Cluster #260 A/1/241 "xe" Zoom to ↗ View details A/1/385 Phrases around chemical substances Zoom to ↗ View details A/1/1567 Chemical abbreviations Zoom to ↗ View details A/1/181 Chemistry " pH", " temperature", etc. Zoom to ↗ View details A/1/3287 " results" Zoom to ↗ View details A/1/3261 Statistics-related nouns or endings thereof, in "######" section titles Zoom to ↗ View details Cluster #312 A/0/218 The feature attends to words and phrases commonly found in sections describing the results of scientific papers. Zoom to ↗ View details A/1/3214 " study" Zoom to ↗ View details A/1/3253 " studies" Zoom to ↗ View details A/1/4076 " difference" Zoom to ↗ View details Cluster #311 A/0/83 The feature attends to words referring to different types of cells. Zoom to ↗ View details A/0/179 The feature attends to text describing figures and plots. Zoom to ↗ View details A/0/321 The feature attends to words and phrases related to cell death and injury. Zoom to ↗ View details A/1/159 This feature fires when it sees words related to chemical processes, such as polymerization, oxidation, precipitation, elution, etc. Zoom to ↗ View details A/1/336 The feature fires on tokens related to biological or medical samples. Zoom to ↗ View details A/1/997 Mostly " cells" and similar terms Zoom to ↗ View details A/1/1070 " Expression"/" expression" Zoom to ↗ View details A/1/1144 " age" Zoom to ↗ View details A/1/1434 " group" Zoom to ↗ View details A/1/1981 The feature fires when it sees words related to time periods or durations such as 'after', 'during', 'weeks', 'months', etc. Zoom to ↗ View details A/1/2510 This feature attends to words and phrases related to growth, proliferation, and increase. Zoom to ↗ View details A/1/2951 The feature fires when it sees words related to genes and genetic concepts. Zoom to ↗ View details A/1/3324 Some nouns esp. in medicine/science, but pretty varied Zoom to ↗ View details A/1/3332 Biomedical techniques Zoom to ↗ View details A/1/3470 Blood test results (as levels or concentrations) Zoom to ↗ View details A/1/3948 Abstract plural nouns in broadly technical/scientific contexts Zoom to ↗ View details A/1/4071 This feature attends to words related to research, diagnoses and treatments for diseases and disorders. Zoom to ↗ View details A/1/2321 [Ultralow density cluster] Zoom to ↗ View details A/1/1412 " population" Zoom to ↗ View details A/1/1840 The feature fires when it follows words that end with "s". Zoom to ↗ View details Cluster #286 A/0/49 This feature seems to fire on words related to measurements, including units of measurement and words describing amounts. For example, it often fires on words like "temperature", "pH", "concentration", "volume", "score", "sensitivity", "specificity", "latency", "rate", "flow", "velocity", "weight", etc. as well as numerical values. Zoom to ↗ View details A/1/98 " count"/" phase" in various contexts Zoom to ↗ View details A/1/3772 Mechanical engineering performance Zoom to ↗ View details A/1/1086 " patients" Zoom to ↗ View details A/1/3750 " disease" Zoom to ↗ View details A/1/3131 Biology terms Zoom to ↗ View details A/1/907 " treatment"/" therapy" medical nouns Zoom to ↗ View details A/1/3760 Unit of time in days/months/years (but not minutes/hours) Zoom to ↗ View details A/1/1405 Demographic information stratified by age Zoom to ↗ View details A/1/1933 Synthetic biology Zoom to ↗ View details Cluster #317 A/0/41 This feature attends to wording related to perceptual and cognitive processing in scientific and research writing. Zoom to ↗ View details A/0/145 The feature attends to parenthetical information (e.g. numbers in parentheses). Zoom to ↗ View details A/1/482 "%" or verbs in stats from medical trials? Zoom to ↗ View details A/1/811 Medical imaging, esp. abbreviations like " CT"/" MR" Zoom to ↗ View details Cluster #169 A/0/108 The feature seems to be attending to biological and scientific language describing experiments, results, and processes related to cells, including activation, signaling, proliferation, inflammation, expression, phosphorylation, suppression, upregulation, pathways, responses, and treatments. Zoom to ↗ View details A/1/22

Summary of Results


Problem Setup

A key challenge to our agenda of reverse engineering neural networks is the curse of dimensionality: as we study ever-larger models, the volume of the latent space representing the model's internal state that we need to interpret grows exponentially. We do not currently see a way to understand, search or enumerate such a space unless it can be decomposed into independent components, each of which we can understand on its own. In certain limited cases, it is possible to side step these issues by rewriting neural networks in ways that don't make reference to certain hidden states. For example, in A Mathematical Framework for Transformer Circuits , we were able to analyze a one-layer attention-only network without addressing this problem. But this approach becomes impossible if we consider even a simple standard one-layer transformer with an MLP layer with a ReLU activation function. Understanding such a model requires us to have a way to decompose the MLP layer. In some sense, this is the simplest language model we profoundly don't understand. And so it makes a natural target for our paper. We aim to take its MLP activations – the activations we can't avoid needing to decompose – and decompose them into "features": Crucially, we decompose into more features than there are neurons. This is because we believe that the MLP layer likely uses superposition to represent more features than it has neurons (and correspondingly do more useful non-linear work!). In fact, in our largest experiments we'll expand to have 256 times more features than neurons, although we'll primarily focus on a more modest 8× expansion.
| | Transformer | Sparse Autoencoder |
| --- | --- | --- |
| Layers | 1 Attention Block
1 MLP Block (ReLU) | 1 ReLU (up)
1 Linear (down) |
| MLP Size | 512 | 512 (1×) – 131,072 (256×) |
| Dataset | The Pile
(100 billion tokens) | Transformer MLP Activations
(8 billion samples) |
| Loss | Autoregressive Log-Likelihood | L2 reconstruction

Features as a Decomposition

There is significant empirical evidence suggesting that neural networks have interpretable linear directions in activation space. This includes classic work by Mikolov et al. investigating "vector arithmetic" in word embeddings (but see ) and similar results in other latent spaces (e.g. ). There is also a large body of work investigating interpretable neurons, which are just basis dimensions (e.g. in RNNs ; in CNNs ; in GANs ; but see ). A longer review and discussion of this work can be found in the Motivation section of Toy Models , although it doesn't cover more recent work (e.g. ).We'd particularly highlight an exciting exchange between Li et al. and Nanda et al. : Li et al. found an apparent counterexample where features were not represented as directions, which was then resolved by Nanda finding an alternative interpretation in which features were directions. If linear directions are interpretable, it's natural to think there's some "basic set" of meaningful directions which more complex directions can be created from. We call these directions features, and they're what we'd like to decompose models into. Sometimes, by happy circumstances, individual neurons appear to be these basic interpretable units (see examples above). But quite often, this isn't the case. Instead, we decompose the activation vector \mathbf{x}^j as a combination of more general features which can be any direction: \mathbf{x}^j \approx \mathbf{b} + \sum_i f_i(\mathbf{x}^j) \mathbf{d}i (1) where \mathbf{x}^j is the activation vector of length d{\rm MLP} for datapoint j, f_i(\mathbf{x}^j) is the activation of feature i, each \mathbf{d}_i is a unit vector in activation space we call the direction of feature i, and \mathbf{b} is a bias.While not the focus of this paper, we could also imagine decomposing other portions of the model’s latent state or activations in this way. For instance, we could apply this decomposition to the residual stream (see e.g. ), or to the keys and queries of attention heads, or to their outputs. Note that this decomposition is not new: it is just a linear matrix factorization of the kind commonly employed in dictionary learning. In our sparse autoencoder setup, the feature activations are the output of the encoder f_i(x) = \text{ReLU}( W_e (\mathbf{x} - \mathbf{b}_d) + \mathbf{b}_e )_i, where W_e is the weight matrix of the encoder and \mathbf{b}_d, \mathbf{b}_e are a pre-encoder and an encoder bias. The feature directions are the columns of the decoder weight matrix W_d. (See appendix for full notation.) If such a sparse decomposition exists, it raises an important question: are models in some fundamental sense composed of features or are features just a convenient post-hoc description? In this paper, we take an agnostic position, though our results on feature universality suggest that features have some existence beyond individual models.

Superposition Hypothesis

To see how this decomposition relates to superposition, recall that the superposition hypothesis postulates that neural networks “want to represent more features than they have neurons”. We think this happens via a kind of “noisy simulation”, where small neural networks exploit feature sparsity and properties of high-dimensional spaces to approximately simulate much larger much sparser neural networks . A consequence of this is that we should expect the feature directions to form an overcomplete basis. That is, our decomposition should have more directions \mathbf{d}_i than neurons. Moreover, the feature activations should be sparse, because sparsity is what enables this kind of noisy simulation. This is mathematically identical to the classic problem of dictionary learning.

What makes a good decomposition?

Suppose that a dictionary exists such that the MLP activation of each datapoint is in fact well approximated by a sparse weighted sum of features as in equation 1. That decomposition will be useful for interpreting the neural network if:

  1. We can interpret the conditions under which each feature is active. That is, we have a description of which datapoints j cause the feature to activate (i.e. for which f_i(\mathbf{x}^j) is large) that makes sense on a diverse dataset (including potentially synthetic or off-distribution examples meant to test the hypothesis).This property is closely related to the desiderata of Causality, Generality, and Purity discussed in Cammarata et al. , and those provide an example of how we might make this property concrete in a specific instance.
  2. We can interpret the downstream effects of each feature, i.e. the effect of changing the value of f_i on subsequent layers. This should be consistent with the interpretation in (1).
  3. The features explain a significant portion of the functionality of the MLP layer (as measured by the loss; see How much of the model does our interpretation explain?).

A feature decomposition satisfying these criteria would allow us to:

  1. Determine the contribution of a feature to the layer’s output, and the next layer’s activations, on a specific example.
  2. Monitor the network for the activation of a specific feature (see e.g. speculation about safety-relevant features).
  3. Change the behavior of the network in predictable ways by changing the values of some features. In multilayer models this could look like predictably influencing one layer by changing the feature activations in an earlier layer.
  4. Demonstrate that the network has learned certain properties of the data.
  5. Demonstrate that the network is using a given property of the data in producing its output on a specific example.This is similar in spirit to the evidence provided by influence functions.
  6. Design inputs meant to activate a given feature and elicit certain outputs.

Of course, decomposing models into components is just the beginning of the work of mechanistic interpretability! It provides a foothold on the inner workings of models, allowing us to start in earnest on the task of unraveling circuits and building a larger-scale understanding of models.

Why not use architectural approaches?

In Toy Models of Superposition , we highlighted several different approaches to solving superposition. One of those approaches was to engineer models to simply not have superposition in the first place. Initially, we thought that this might be possible but come with a large performance hit (i.e. produce models with greater loss). Even if this performance hit had been too large to use in practice for real models, we felt that success at creating monosemantic models would have been very useful for research, and in a lot of ways this felt like the "cleanest" approach for downstream analysis. Unfortunately, having spent a significant amount of time investigating this approach, we have ultimately concluded that it is more fundamentally non-viable. In particular, we made several attempts to induce activation sparsity during training to produce models without superposition, even to the point of training models with 1-hot activations. This indeed eliminates superposition, but it fails to result in cleanly-interpretable neurons! Specifically, we found that individual neurons can be polysemantic even in the absence of superposition. This is because in many cases models achieve lower loss by representing multiple features ambiguously (in a polysemantic neuron) than by representing a single feature unambiguously and ignoring the others. To understand this, consider a toy model with a single neuron trained on a dataset with four mutually-exclusive features (A/B/C/D), each of which makes a distinct (correct) prediction for the next token, labeled in the same fashion. Further suppose that this neuron’s output is binary: it either fires or it doesn’t. When it fires, it produces an output vector representing the probabilities of the different possible next tokens. We can calculate the cross-entropy loss achieved by this model in a few cases:

  1. Suppose the neuron only fires on feature A, and correctly predicts token A when it does. The model ignores all of the other features, predicting a uniform distribution over tokens B/C/D when feature A is not present. In this case the loss is \frac{3}{4}\ln 3 \approx 0.8.
  2. Instead suppose that the neuron fires on both features A and B, predicting a uniform distribution over the A and B tokens. When the A and B features are not present, the model predicts a uniform distribution over the C and D tokens. In this case the loss is \ln 2 \approx 0.7.

Because the loss is lower in case (2) than in case (1), the model achieves better performance by making its sole neuron polysemantic, even though there is no superposition. This example might initially seem uninteresting because it only involves one neuron, but it actually points at a general issue with highly sparse networks. If we push activation sparsity to its limit, only a single neuron will activate at a time. We can now consider that single neuron and the cases where it fires. As seen earlier, it can still be advantageous for that neuron to be polysemantic. Based on this reasoning, and the results of our experiments, we believe that models trained on cross-entropy loss will generally prefer to represent more features polysemantically than to represent fewer "true features" monosemantically, even in cases where sparsity constraints make superposition impossible. Models trained on other loss functions do not necessarily suffer this problem. For instance, models trained under mean squared error loss (MSE) may achieve the same loss for both polysemantic and monosemantic representations (e.g. ), and for some feature importance curves they may actively prefer the monosemantic solution . But language models are not trained with MSE, and so we do not believe architectural changes can be used to create fully monosemantic language models. Note, however, that in learning to decompose models post-training we do use an MSE loss (between the activations and their representation in terms of the dictionary), so sparsity can inhibit superposition from forming in the learned dictionary. (Otherwise, we might have superposition "all the way down.")

Using Sparse Autoencoders To Find Good Decompositions

There is a long-standing hypothesis that many natural latent variables in the world are sparse (see , section "Why Sparseness?"). Although we have a limited understanding of the features that exist in language models, the examples we do have (e.g. ) are suggestive of highly sparse variables. Our work on Toy Models of Superposition shows that a large set of sparse features could be represented in terms of directions in a lower dimensional space. For this reason, we seek a decomposition which is sparse and overcomplete. This is essentially the problem of sparse dictionary learning. (Note that, since we're only asking for a sparse decomposition of the activations, we make no use of the downstream effects of \mathbf{d}_i on the model's output. This means we'll be able to use those downstream effects in later sections as a kind of validation on the features found.) It's important to understand why making the problem overcomplete – which might initially sound like a trivial change – actually makes this setting very different from similar approaches seeking sparse disentanglement in the literature. It's closely connected to why dictionary learning is such a non-trivial operation; in fact, as we'll see, it's actually kind of miraculous that this is possible at all. At the heart of dictionary learning is an inner problem of computing the feature activations f_i(\mathbf{x}) for each datapoint \mathbf{x}, given the feature directions \mathbf{d}_i. On its surface, this problem may seem impossible: we're asking to determine a high-dimensional vector from a low-dimensional projection. Put another way, we're trying to invert a very rectangular matrix. The only thing which makes it possible is that we are looking for a high-dimensional vector that is sparse! This is the famous and well-studied problem of compressed sensing, which is NP-hard in its exact form. It is possible to store high-dimensional sparse structure in lower-dimensional spaces, but recovering it is hard. Despite its difficulty, there are a host of sophisticated methods for dictionary learning (e.g. ). These methods typically involve optimizing a relaxed problem or doing a greedy search. We tried several of these classic methods, but ultimately decided to focus on a simpler sparse autoencoder approximation of dictionary learning (similar to Sharkey, et al. ). This was for two reasons. First, a sparse autoencoder can readily scale to very large datasets, which we believe is necessary to characterize the features present in a model trained on a large and diverse corpus.For the model discussed in this paper, we trained the autoencoder on 8 billion datapoints. Secondly, we have a concern that iterative dictionary learning methods might be "too strong", in the sense of being able to recover features from the activations which the model itself cannot access. Exact compressed sensing is NP-hard, which the neural network certainly isn't doing. By contrast, a sparse autoencoder is very similar in architecture to the MLP layers in language models, and so should be similarly powerful in its ability to recover features from superposition.

Sparse Autoencoder Setup

We briefly overview the architecture and training of our sparse autoencoder here, and provide further details in Basic Autoencoder Training. Our sparse autoencoder is a model with a bias at the input, a linear layer with bias and ReLU for the encoder, and then another linear layer and bias for the decoder. In toy models we found that the bias terms were quite important to the autoencoder’s performance.We tie the biases applied in the input and output, so the result is equivalent to subtracting a fixed bias from all activations and then using an autoencoder whose only bias is before the encoder activation. We train this autoencoder using the Adam optimizer to reconstruct the MLP activations of our transformer model, with an MSENote that using an MSE loss avoids the challenges with polysemanticity that we discussed above in Why Not Architectural Approaches? loss plus an L1 penalty to encourage sparsity. In training the autoencoder, we found a couple of principles to be quite important. First, scale really matters. We found that training the autoencoder on more data made features subjectively “sharper” and more interpretable. In the end, we decided to use 8 billion training points for the autoencoder (see Autoencoder Dataset). Second, we found that over the course of training some neurons cease to activate, even across a large number of datapoints. We found that “resampling” these dead neurons during training gave better results by allowing the model to represent more features for a given autoencoder hidden layer dimension. Our resampling procedure is detailed in Neuron Resampling, but in brief we periodically check for neurons which have not fired in a significant number of steps and reset the encoder weights on the dead neurons to match data points that the autoencoder does not currently represent well. For readers looking to apply this approach, we supply an appendix with Advice for Training Sparse Autoencoders.

How can we tell if the autoencoder is working?

Usually in machine learning we can quite easily tell if a method is working by looking at an easily-measured quantity like the test loss. We spent quite some time searching for an equivalent metric to guide our efforts here, and unfortunately have yet to find anything satisfactory. We began by looking for an information-based metric, so that we could say in some sense that the best factorization is the one that minimizes the total information of the autoencoder and the data. Unfortunately, this total information did not generally correlate with subjective feature interpretability or activation sparsity. (Runs whose feature activations had an average L0 norm in the hundreds but low reconstruction error could have lower total information than those with smaller average L0 norm and higher reconstruction error.) Thus we ended up using a combination of several additional metrics to guide our investigations:

  1. Manual inspection: Do the features seem interpretable?
  2. Feature density: we found that the number of “live” features and the percentage of tokens on which they fire to be an extremely useful guide. (See appendix for details.)
  3. Reconstruction loss: How well does the autoencoder reconstruct the MLP activations? Our goal is ultimately to explain the function of the MLP layer, so the MSE loss should be low.
  4. Toy models: Having toy models where we know the ground truth and so can cleanly evaluate the autoencoder’s performance was crucial to our early progress.

Interpreting or measuring some of these signals can be difficult, though. For instance, at various points we thought we saw features which at first didn’t make any sense, but with deeper inspection we could understand. Likewise, while we have identified some desiderata for the distribution of feature densities, there is much that we still do not understand and which prevents this from providing a clear signal of progress. We think it would be very helpful if we could identify better metrics for dictionary learning solutions from sparse autoencoders trained on transformers.

The (one-layer) model we're studying

We chose to study a one-layer transformer model. We view this model as a testbed for dictionary learning, and in that role it brings three key advantages:

  1. Because one-layer models are small they likely have fewer "true features" than larger models, meaning features learned by smaller dictionaries might cover all their "true features". Smaller dictionaries are cheaper to train, allowing for fast hyperparameter optimization and experimentation.
  2. We can highly overtrain a one-layer transformer quite cheaply. We hypothesize that a very high number of training tokens may allow our model to learn cleaner representations in superposition.
  3. We can easily analyze the effects features have on the logit outputs, because these are approximately linear in the feature activations.Note that this linear structure makes it even more likely that features should be linear. On the one hand, this means that the linear representation hypothesis is more likely to hold for this model. On the other hand, it potentially means that our results are less likely to generalize to multilayer models. Fortunately, others have studied multilayer transformers with sparse autoencoders and found interpretable linear features, which gives us more confidence that what we see in the one-layer model indeed generalizes . This provides helpful corroboration that the features we have found are not just telling us about the data distribution, and actually reflect the functionality of the model.

We trained two one-layer transformers with the same hyperparameters and datasets, differing only in the random seed used for initialization. We then learned dictionaries of many different sizes on both transformers, using the same hyperparameters for each matched pair of dictionaries but training on the activations of different tokens for each transformer. We refer to the main transformer we study in this paper as the “A” transformer. We primarily use the other transformer (“B”) to study feature universality, as we can e.g. compare features learned from the “A” and “B” transformers and see how similar they are.

Notation for Features

Throughout this draft, we'll use strings like "A/1/2357" to denote features. The first portion "A" or "B" denote which model the features come from. The second part (e.g. the "1" in "A/1") denotes the dictionary learning run. These vary in the number of learned factors and the L1 coefficient used. A table of all of our runs is available here. Notably, A/0…A/5 form a sequence with fixed L1 coefficients and increasing dictionary sizes. The final portion (e.g. the "2357" in "A/1/2357") corresponds to the specific feature in the run. Sometimes, we want to denote neurons from the transformer rather than features learned by the sparse autoencoder. In this case, we use the notation "A/neurons/32".

Interface for Exploring Features

We provide an interface for exploring all the features in all our dictionary learning runs. Links to the visualizations for each run can be found here. We suggest beginning with the interface for A/1, which we discuss the most. These interfaces provide extensive information on each feature. This includes examples of when they activate, what effect they have on the logits when they do, examples of how they affect the probability of tokens if the feature is ablated, and much more: Our interface also allows users to search through features: Additionally, we provide a second interface displaying all features active on a given dataset example. This is available for a set of example texts.


Detailed Investigations of Individual Features

The most important claim of our paper is that dictionary learning can extract features that are significantly more monosemantic than neurons. In this section, we give a detailed demonstration of this claim for a small number of features which activate in highly specific contexts. The features we study respond to

For each learned feature, we attempt to establish the following claims:

  1. The learned feature activates with high specificity for the hypothesized context. (When the feature is on the context is usually present.)
  2. The learned feature activates with high sensitivity for the hypothesized context. (When the context is present, the feature is usually on.)
  3. The learned feature causes appropriate downstream behavior.
  4. The learned feature does not correspond to any neuron.
  5. The learned feature is universal – a similar feature is found by dictionary learning applied to a different model.

To demonstrate claims 1–3, we devise computational proxies for each context, numerical scores estimating the (log-)likelihood that a string (or token) is from the specific context. The contexts chosen above are easy to model based on the defined sets of unicode characters involved. We model DNA sequences as random strings of characters from [ATCG] and we model base64 strings as random sequences of characters from [a-zA-Z0-9+/]. For Arabic script and Hebrew features, we exploit the fact that each language is written in a script consisting of well-defined Unicode blocks. Each computational proxy is then an estimate of the log-likelihood ratio of a string under the hypothesis versus under the full empirical distribution of the dataset. The full description of how we estimate \log(P(s|\text{context}) / P(s)) for each feature hypothesis is given in the appendix section on proxies. In this section we primarily study the learned feature which is most active in each context. There are typically other features that also model that context, and we find that rare “gaps” in the sensitivity of a main feature are often explained by the activity of another. We discuss this phenomenon in detail in sections on Activation Sensitivity and Feature Splitting. We take pains to demonstrate the specificity of each feature, as we believe that to be more important for ruling out polysemanticity. Polysemanticity typically involves neurons activating for clearly unrelated concepts. For example, one neuron in our transformer model responds to a mix of academic citations, English dialogue, HTTP requests, and Korean text. In vision models, there is a classic example of a neuron which responds to cat faces and fronts of cars . If our proxy shows that a feature only activates in some relatively rare and specific context, that would exclude the typical form of polysemanticity. We finally note that the features in this section are cherry-picked to be easier to analyze. Defining simple computational proxies for most features we find, such as text concerning fantasy games, would be difficult, and we analyze them in other ways in the following section.

Arabic Script Feature

The first feature we'll consider is an Arabic Script feature, A/1/3450. It activates in response to text in Arabic, Farsi, Urdu (and possibly other languages), which use the Arabic script. This feature is quite specific and relatively sensitive to Arabic script, and effectively invisible if we view the model in terms of individual neurons.

Activation Specificity

Our first step is to show that this feature fires almost exclusively on text in Arabic script. We give each token an "Arabic script" score using an estimated likelihood ratio \log(P(s|\text{Arabic Script}) / P(s)), and break down the histogram of feature activations by that score. Arabic text is quite rare in our overall data distribution – just 0.13% of training tokens — but it makes up 81% of the tokens on which our feature is active. That percentage varies significantly by feature activity level, from 25% when the feature is barely active to 98% when the feature activation is above 5. We also show dataset examples demonstrating different levels of feature activity. In interpreting them, it's important to note that Arabic Unicode characters are often split into multiple tokens. For example, the character ث (U+062B) is tokenized as \xd8 followed by \xab.This kind of split tokenization is common for Unicode characters outside the Latin script and the most common characters from other Unicode blocks. When this happens, A/1/3450 typically only fires on the last token of the Unicode character. The upper parts of the activation spectrum, above an activity of ~5, clearly respond with high specificity to Arabic script. What should we make of the lower portions? We have three hypotheses:

Regardless, large feature activations have larger impacts on model predictions,Why do we believe large activations have larger effects? In the case of a one-layer transformer like the one we consider in this paper, we can make a strong case for this: features have a linear effect on the logits (modulo rescaling by layer norm), and so a larger activation of the feature has a larger effect on the logits. In the case of larger models, this follows from a lot of conjectures and heuristic arguments (e.g. the abundance of linear pathways in the model and the idea of linear features at each layer), and must be true for sufficiently small activations by continuity, but doesn't have a watertight argument. so getting their interpretation right matters most. One useful tool for assessing the impact of false positives at low activation levels is the "expected value plot" of Cammarata et al. . We plot the distribution of feature activations weighted by activation level. Most of the magnitude of activation provided by this feature comes from dataset examples which are in Arabic script.

Activation Sensitivity

In the Feature Activation Distribution above, it's clear that A/1/3450 is not sensitive to all tokens in Arabic script. In the random dataset examples, it fails to fire on five examples of the prefix "ال", transliterated as "al-", which is the equivalent of the definite article "the" in English. However, in exactly those places, another feature which is specific to Arabic script, A/1/3134, fires. There are several additional features that fire on Arabic and related scripts (e.g. A/1/1466, A/1/3134, A/1/3399) which contribute to representing Arabic script. Another example deals with Unicode tokenization: when Arabic characters are split into multiple tokens, the feature we analyze here only activates at the final token comprising the character, while A/1/3399 activates on the first token comprising the character. To see how these features collaborate, we provide an alternative visualization showing all the features active on a snippet of Arabic text. We consider such interactions more in the Phenomenology section below. Nevertheless, we find a Pearson correlation of 0.74 between the activity of our feature and the activity of the Arabic script proxy (thresholded at 0), over a dataset of 40 million tokens. Correlation provides a joint measure of sensitivity and specificity that takes magnitude into account, and 0.74 is a substantial correlation.

Feature Downstream Effects

Because the autoencoder is trained on model activations, the features it learns could in theory represent structure in the training data alone, without any relevance to the network’s function. We show instead that the learned features have interpretable causal effects on model outputs which make sense in light of the features’ activations. Note that these downstream effects are not inputs to the dictionary learning process, which only sees the activations of the MLP layer. If the resulting features also mediate important downstream behavioral effects then we can be confident that the feature is truly connected to the MLP’s functional role in the network and not just a property of the underlying data. We begin with a linear approximation to the effect of each feature on the model logits. We compute the logit weight following the path expansion approach of , (also called “logit attribution”, see similar work e.g. ) multiplying each feature direction by the MLP output weights, an approximation of the layer norm operation combining a projection to remove the mean and a diagonal matrix approximating the scaling terms, and the unembedding matrix (d_iW_{down}\pi L W_{unembed}). Because the softmax function is shift-invariant there is no absolute scale for the logit weights; we shift these so that the median logit weight for each feature is zero. Each feature, when active, makes some output tokens more likely and some output tokens less likely. We plot that distributionof logit weights.We exclude weights corresponding to extremely rare or never used vocabulary elements. These are perhaps similar to the "anomalous tokens" (e.g., "SolidGoldMagikarp") of Rumbelow & Watkins . There is a large primary mode at zero, and a second much smaller mode on the far right, the tokens whose likelihood most increases when our feature is on. This second mode appears to correspond to Arabic characters, and tokens which help represent Arabic script characters (especially \xd8 and \xd9, which are often the first half of the UTF-8 encodings of Arabic Unicode characters in the basic Arabic Unicode block). This suggests that activating this feature increases the probability the network predicts Arabic script tokens. There are in theory several ways the logit weights could overestimate the model's actual use of a feature:

  1. It could be that these output weights are small enough that, when multiplied by activations, they don't have an appreciable effect on the model’s output.
  2. The feature might only activate in situations where other features make these tokens extremely unlikely, such that the feature in fact has little effect.
  3. It is possible that our approximation of linearizing the layer norm (see Framework ) is poor.
    Based on the subsequent analysis, which confirms the logit weight effects, we do not believe these issues arise in practice. To visualize these effects on actual data, we causally ablate the feature. For a given dataset example, we run the context through the model until the MLP layer, decode the activations into features, then subtract off the activation of A/1/3450, artificially setting it to zero on the whole context, before applying the rest of the model. We visualize the effect of ablating the feature using underlines in the visualization; tokens whose predictions were helped by the feature (ablation decreased likelihood) are underlined in blue and tokens whose predictions were hurt by the feature (ablation increased likelihood) are underlined in red. In the example on the right below we see that the A/1/3450 was active on every token in a short context (orange background). Ablating it hurt the predictions of all the tokens in Arabic script (purple underlines), but helped the prediction of the period . (orange underline). The rest of the figure displays contexts from two different ranges of feature activation levels. (The feature activation on the middle token of examples on the right ("subsample interval 5") is about half that of the middle token of examples on the left ("subsample interval 0")). We see that the feature was causally helping the model predictions on Arabic script through that full range, and the only tokens made less likely by the feature are punctuation shared with other scripts. The magnitudes of the impact are larger when the feature is more active. We encourage interested readers to view the feature visualization for A/1 to review this and other effects. We also validate that the feature's downstream effect is in line with our interpretation as an Arabic script feature by sampling from the model with the feature activity "pinned" at a high value. To do this, we start with a prefix 1,2,3,4,5,6,7,8,9,10 where the model has an expected continuation (keep in mind that this is a one layer model that is very weak!). We then instead set A/1/3450 to its maximum observed value and see how that changes the samples:

The feature is not a neuron

This feature seems rather monosemantic, but some models have relatively monosemantic neurons, and we want to check that dictionary learning didn't merely hand us a particularly nice neuron.Of course, some features might genuinely be neuron aligned. But we'd like to know that at least some of the features dictionary learning discovers were not trivial. We first note that when we search for neurons with Arabic script in their top dataset 20 examples, only one neuron turns up, with a single example in Arabic script. (Eighteen of the remaining examples are in English, and one is in Cyrillic.) We then look at the coefficients of the feature in the neuron basis, and find that the three largest coefficients by magnitude are all negative (!) and there are a full 27 neurons whose coefficients are at least 0.1 in magnitude. It is of course possible that these neurons engage in a delicate game of cancellation, resulting in one particular neuron's primary activations being sharpened. To check for this, we find the neuron whose activations are most correlated to the feature's activations over a set of ~40 million dataset examples. We also tried looking at the neurons which have the largest contribution to the dictionary vector for the feature. However, we found looking at the most correlated neuron to be more reliable – in earlier experiments, we found rare cases where the correlated method found a seemingly similar neuron, while the dictionary method did not. This may be because neurons can have different scales of activations. The most correlated neuron (A/neurons/489) responds to a mixture of different non-English languages.This makes sense as a superposition strategy: since languages are essentially mutually exclusive, they're natural to put in superposition with each other We can see this by visualizing the activation distribution of the neuron – the dataset examples are all other languages, with Arabic script present only as a small sliver. Logit weight analysis is also consistent with this neuron responding to a mixture of languages. For example, in the figure below many of the top logit weights appear to include Russian and Korean tokens. Careful readers will observe a thin red sliver corresponding to rare Arabic script tokens in the distribution. These Arabic script tokens have weight values that are very slightly positive leaning overall, but some are negative. Finally, scatter plots and correlations suggest the similarities between A/1/3450 and the neuron are non-zero, but quite minimal.By analogy, this also applies to B/1/1334. In particular, note how the y-axis of the logit weights scatter plot (corresponding to the feature) cleanly separates the Arabic script token logits, while the x-axis does not. More generally, note how the y-marginals both clearly exhibit specificity, but the x-marginals do not. We conclude that the features we study do not trivially correspond to a single neuron. The Arabic script feature would be effectively invisible if we only analyzed the model in terms of neurons.

Universality

We will now ask whether A/1/3450 is a universal feature that forms in other models and can be consistently discovered by dictionary learning. This would indicate we are discovering something more general about how one-layer transformers learn representations of the dataset. We search for a similar feature in B/1, a dictionary learning run on a transformer trained on the same dataset but with a different random seed. We search for the feature with the highest activation correlation "Activation correlation" is defined as the feature whose activations across 40,960,000 tokens has the highest Pearson correlation with those of A/1/3450. and find B/1/1334 (corr=0.91), which is strikingly similar: This feature clearly responds to Arabic script as well. If anything, it's nicer than our original feature – it's more specific in the 0–1 range. The logit weights tell a similar story: The effects of ablating this feature are also consistent with this (see the visualization for B/1/1334). To more systematically analyze the similarities between A and B, we look at scatter plots comparing the activations or logit weights: The activations are strongly correlated (Pearson correlation of 0.91), especially in the main Arabic mode. The logit weights reveal a two-dimensional version of the bimodality we saw in the histogram for A/1, with logit weights for Arabic tokens clustering at the top right. The correlation is more modest than that of the activations because the distribution is dominated by a relatively uncorrelated mode in the center. We hypothesize this central mode corresponds to "weight interference" and that the shared outlier mode is the important observation – that is, the model may ideally prefer to have all those weights be zero, but due to superposition with other features and their weights, this isn't possible.

DNA Feature

We now consider a DNA feature, A/1/2937. It activates in response to long uppercase strings consisting of A, T, C, and G, typically used to represent nucleotide sequences. We closely follow the analysis of the Arabic script feature above to show activation specificity and sensitivity for the feature, sensible downstream effects, a lack of neuron alignment, and universality between models. The main differences will be that (1) A/1/2937 is the only feature devoted to modeling the DNA context, and (2) our proxy is less sensitive to DNA than our feature is, missing strings containing punctuation, spaces, and missing bases.

Activation Specificity and Sensitivity

We begin with the computational proxy for "is a DNA sequence", \log(P(s|\text{DNA}) / P(s)). Because there are some vocabulary tokens, such as CAT, which could occur in DNA but also occur in other contexts, we always look at groups of at least two tokens when evaluating the proxy. The log-probabilities turn out to be quite bimodal, so we binarize the proxy (based on its sign). This binarized proxy then has a Pearson correlation of 0.8 with the feature activations. While the feature appears to be quite monosemantic in the feature's higher registers (all 10 random dataset examples above activation of 6.0 are DNA sequences), there is significant blue indicating the DNA proxy not firing in the lower registers. Below we show a grid of random examples at four activation levels (including feature off) where the proxy does and doesn't fire. We note that in all but two cases where the feature and proxy disagree, the feature does indicate a DNA sequence, just one outside our proxy's strict ATCG vocabulary. For example, the space present in the triplets TGG AGT makes the proxy fail to fire. The feature also fires productively on '-in the string 5'-TCT, because what follows that prefix should be DNA, even though the prefix is not itself DNA. (The causal ablation reveals that turning off the DNA feature hurts the prediction of the strings that follow.) We thus believe that A/1/2937 is quite sensitive and specific for DNA. The case where the proxy fires and the feature does not is indeed a DNA sequence, though the feature begins firing on the very next token. We observe that the DNA feature may not fire on the first few tokens of a DNA sequence, but by the end of a long DNA sequence, it is the only feature active.

Feature Downstream Effect

The downstream effect of the DNA feature being active, as measured by logit weights, make sense, with all the top tokens being combinations of nucleotides like AGT and GCC.

The Feature Is Not A Neuron

The most similar neuron to A/1/2937, as measured by activation correlation, is A/neurons/67. DNA contexts form a tiny sliver of that neuron's activating examples. The neuron whose coefficient is the highest in our feature's vector, A/neurons/227, also has no DNA sequences in its top activating examples.

Universality

A/1/2937 has a correlated feature (corr=0.92) in run B/1, B/1/3680. Their top logit weights agree, and are DNA tokens (e.g. AGT) forming a separate mode (circled on the right) than the bulk of the logit weights for both.

Base64 Feature

We now consider a base64 feature, A/1/2357. We're particularly excited by this feature because we discovered a base64 neuron in our SoLU paper , suggesting that base64 might be quite universal – even across models trained on somewhat different datasets and with different architectures. We model base64 strings as random sequences of characters from [a-zA-Z0-9+/]. The activation distribution colored by the corresponding computational proxy, together with the random dataset examples from each activation level, shows that this feature is quite specific to base64. This is not the only feature active in base64 contexts, and in a section below we discuss the two others, one of which fires on single digits in base64 contexts (like the 2, 4, 7, and 9 on which A/1/2357 doesn't activate in the figure above), exploiting a property of the BPE tokenizer to make a better prediction. Turning to the logit weights, they have a second mode consisting of highly base64-specific tokens. The main mode seems to primarily be interference, but the right side is skewed towards base64-neutral or slightly base64-leaning tokens. (If we look at the conditional below, we see a more continuous transition to base64-specific tokens.) There is a more continuous transition between non-base64 and base64 tokens than we saw in the Arabic script example. This difference likely arises because whether a token occurs more in Arabic script than in other text is a relatively binary distinction, whereas whether a token occurs more in base64 or other text varies more continuously. For instance, fr is both a common abbreviation for the French language and also a base64 token, so it makes sense for the model to be cautious in up-weighting fr because it might already have a higher prior due to use in French. Indeed, any token consisting of letters from the English alphabet will have some nontrivial probability of appearing in base64 strings. The Pearson correlation between the computational proxy and the activity of A/1/2357 is just 0.38. We believe that is mostly because the proxy is too broad. For example hexadecimal strings (those made of [0-9A-F]) activate the proxy, as they are quite different from the overall data distribution, but are actually predicted by a feature of their own, A/1/3817.

Universality

A/1/2357 has a correlated feature (corr=0.85) in run B/1, B/1/2165. It also has high activation specificity for base64 strings: Like A/1/2357, B/1/2165's logit weights have a second mode corresponding to base64 tokens: Correlations and scatter plots are also consistent with them being very similar features: Note that we expect the overlap between the interference and base64 token logit weights to be from the aforementioned usage of base64 tokens across many other contexts.

The Feature Is Not A Neuron

Looking at the neuron in model A that most correlates with this feature: A/neurons/470 (corr=0.18), we find that while it does notably respond to base64 strings, it also activates for lots of other things, including code, HTML labels, parts of URLs, etc.: The logit weights suggest it somewhat increases base64 tokens, but is much more focused on upweighting other tokens, e.g. filename endings. The activation and logit correlations are consistent with this neuron helping represent the same feature, but largely doing other things.

Hebrew Feature

Another interesting example is the Hebrew feature A/1/416. Like the Arabic feature, it's easy to computationally identify Hebrew text based on Unicode blocks. A/1/416 has high activation specificity in the upper spectrum. It does weakly activate for other things (especially other languages with Unicode scripts). There is also some blue in strong activations; this appears to significantly be on "common characters", such as whitespace or punctuation, which are from other unicode blocks (see more discussion of similar issues in the Arabic feature section). Its logit weights have a notable second mode, corresponding to Hebrew characters and relevant incomplete Unicode characters. Note that \xd7 is the first token in the UTF-8 encoding of most characters in the basic Hebrew Unicode block. The Pearson correlation of the Hebrew script proxy with A/1/416 is 0.55. Some of the failure of sensitivity may be due to a complementary feature A/1/1016 that fires on \xd7 and predicts the bytes that complete Hebrew characters' codepoints.

The Feature Is Not A Neuron

There doesn't appear to be a similar neuron. The most correlated neuron in model A is A/neurons/489 (corr=0.1), which has low activation and logit specificity. Consider the following activation and logit correlation plots: To cross-validate this, we also searched for any neuron where the main Hebrew Unicode block appeared in the top dataset examples. We found none.

Universality

A/1/416 has a correlated feature in the B/1 run, B/1/1901 (corr=0.92) that has significant activation specificity: Logit weights have a second mode, as before: Activation and logit weight correlations are again consistent:


Global Analysis

If the previous section has persuaded you that at least some of the features are genuinely interpretable and reflect the underlying model mechanics, it's natural to wonder how broadly this holds outside of those cherry-picked features. The primary focus of this section will be to answer the question, "how interpretable are the rest of the features?" We show that both humans and large language models find our features to be significantly more interpretable than neurons, and quite interpretable in absolute terms. There are a number of other questions one might also ask. To what extent is our dictionary learning method discovering all the features necessary to understand the MLP layer? Holistically, how much of the MLP layer's mechanics have been made interpretable? We are not yet able to fully answer these questions to our satisfaction, but will provide some preliminary speculation towards the end of this section. We note that of the 4,096 learned features in the A/1 autoencoder, 168 of them are "dead" (active on none of the 100 million dataset examples) and 292 of them are "ultralow density", active on less than 1 in a million dataset examples and exhibiting other atypical properties. We exclude both these groups of features from further analyses.

How Interpretable is the Typical Feature?

In this section, we use three different methods to analyze how interpretable the typical feature is, and how that compares to neurons: human analysis, and two forms of automated interpretability. All three approaches find that features are much more interpretable than neurons.

Manual Human Analysis

At present, we do not have any metric we trust more than human judgment of interpretability. Thus, we had a blinded annotator (one of the authors, Adam Jermyn) score features and neurons based on how interpretable they are. The scoring rubric can be found in the appendix and accounts for confidence in an explanation, consistency of the activations with that explanation, consistency of the logit output weights with that explanation, and specificity. In doing this evaluation, we wanted to avoid a weakness we perceived in our prior work (e.g., ) of focusing evaluation predominantly on maximal dataset examples, and paying less attention to the rest of the activation spectrum. Many polysemantic neurons appear monosemantic if you only look at top dataset examples, but are revealed to be polysemantic if you look at lower parts of the activation spectrum. To avoid this, we draw samples uniformly across the spectrum of feature activations,In order to sample uniformly across the spectrum of feature activations, we divide the activation spectrum into 11 "activation intervals" evenly spaced between 0 activation and the maximum activation. We sample uniformly from these intervals. and score each interval separately in light of the overall hypothesis suggested by the feature. Unfortunately, this approach is labor intensive and so the number of scored samples is small. In total, 412 feature activation intervals were scored across 162 features and neurons. We see that features are substantially more interpretable than neurons. Very subjectively, we found features to be quite interpretable if their rubric value was above 8. The median neuron scored 0 on our rubric, indicating that our annotator could not even form a hypothesis of what the neuron could represent! Whereas the median feature interval scored a 12, indicating that the annotator had a confident, specific, consistent hypothesis that made sense in terms of the logit output weights.

Automated Interpretability – Activations

To analyze features at a larger scale, we turned to automated interpretability . Following the approach of Bills et al. , we have a large language model, Anthropic’s Claude, generate explanations of features using examples of tokens where they activate. Next, we have the model use that explanation to predict new activations on previously unseen tokens.It's worth explicitly stating that our automated interpretability setup was designed to ensure that there's no leak of information about activation patterns, except for the explanation. For example, when predicting new activations, the model cannot see any true activations of that feature. Like with the human analysis, we used samples across the full range of activation intervals to evaluate monosemanticity.This is distinct from the evaluation strategy of Bills et al., who calculated their correlation of predicted and true activations on a mixture of maximal dataset examples and random samples. For sparse features, which don't fire on most random samples, this effectively tests the model's ability to distinguish a feature's large activations from zero. Concretely, for each feature, we computed the Spearman correlation coefficient between the predicted activation and the true activations for 60 dataset examples made up of nine tokens each, resulting in 540 predictions per feature. While only using completely random sequences would be the most principled approach to scoring, half of the examples are from across the feature intervals to get a more accurate correlation. See the appendix for additional information including the use of importance scoring to precisely counter-weight the bias of providing tokens the feature fires for. In agreement with the human analysis, Claude is able to explain and predict activations for features significantly better than for neurons.In instances where Claude predicts a constant score, most often all 0s, a correlation can't be computed and we assign a score of zero which explains the uptick there.

Automated Interpretability – Logit Weights

In our earlier analysis of individual features, we found that looking at the logits is a powerful tool for cross-validating the interpretability of features. We can take this approach in automated interpretability as well. Using the explanations of features generated in the previous analysis, we ask a language model to predict if a previously unseen logit token is something the feature should predict as likely to come next. This is then scored against a 50/50 mix of top positive logit tokens and random other logit tokens. Randomly guessing would give a 50% accuracy, but the model instead achieves a 74% average across features, compared to a 58% average across neurons. Failures here refer to instances where Claude failed to reply in the correct format for scoring.

Activation Interval Analysis

In addition to studying features as a whole, in our manual analysis we can zoom in on portions of the feature activation spectrum using the feature intervals. As before, a feature interval is the set of examples with activations closest to a specific evenly-spaced fraction of the max activation. So, rather than asking if a feature seems interpretable, we ask whether a range of activations is consistent with the overall hypothesis suggested by the full spectrum of the feature’s activation. This allows us to ask how interpretability changes with feature activation strength. Higher-activating feature intervals were more consistent with our interpretations than lower-activating ones. In particular:

It is possible that this is a sign that our features are not quite right. For instance, if one of our features is at a slight angle to the feature we’d really like to have learned, that can show up as inconsistent behavior in the lower activation intervals.

Caveats

Our manual and automated interpretability experiments have a few caveats:

Based on our inspection of many features in the visualization, we believe these caveats do not affect the experimental results. We encourage interested readers to open the visualization for A/1 and the corresponding neurons. You can sort by ‘random’ to get an unbiased sample and do your own version of the above experiment, or sort features by importance metrics such as max activation and max density to evaluate the final caveat above.

How much of the model does our interpretation explain?

We now turn to the question we're least able to answer – to what extent do these seemingly interpretable features represent the "full story" of the MLP? One could imagine posing this question in a variety of ways. What fraction of the MLP loss contribution have we made interpretable? How much model behavior can we understand? If there really are some discrete set of "true features", what fraction have we discovered? One way to partly get at this question is to ask how much of the loss is explained by our features. For A/1, the run we've focused most on in this paper, 79% of the log-likelihood loss reduction provided by the MLP layer is recovered by our features. That is, the additional loss incurred by replacing the MLP activations with the autoencoder's output is just 21% of the loss that would be incurred by zero ablating the MLP. This loss penalty can be reduced by using more features, or using a lower L1 coefficient. As an extreme example, A/5 (n_learned_sparse=131,072, l1_coefficient=0.004) recovers 94.5% of log-likelihood loss. These numbers should be taken with a significant grain of salt. The biggest issue is that framing this question in terms of fraction of loss may be misleading – we expect there to be a long-tail of features such that as the fraction of loss explained increases, more and more features are needed to explain the residual. Another issue is that we don't believe our features are completely monosemantic (some polysemanticity may be hiding in low activations), nor are all of them necessarily cleanly interpretable. With all of that said, our earlier analyses of individual features (e.g. the Arabic feature, base64 feature, etc.) do show that specific interpretable features are used by the model in interpretable ways – ablating them decreases probabilities in the appropriate way, and artificially activating them causes a corresponding behavior. This seems to confirm that the 79% of loss recovered is measuring something real, despite these caveats. In principle, one could use automated interpretability to produce a better measure here: replacing activations with those predicted from explanations. (We believe others in the community have recently been considering this!) The naive versions of this would be quite computationally expensive,Naively, simulating a layer with 100k features would be 100,000 times more expensive than sampling a large language model such as Claude 2 or GPT-4 (we'd need to sample the explaining large model once for every feature at every token). At current prices, this would suggest simulating 100k features on a single 4096 token context would cost $12,500–$25,000, and one would presumably need to evaluate over many contexts. although there may be approximations. More generally, there is a much broader space of possibilities here. Perhaps there's a principled way to do this analysis in terms of single features – there are significant conceptual issues, but one might be able to formalize earlier notions of "feature importance" as an independent loss contribution a feature makes, and then analyze how much of that specific feature can be recovered. Overall, we view the problem of measuring the degree to which a feature-based interpretation explains a model to be an important open question, where significant work is necessary on both defining metrics and finding efficient ways to compute them.

Do features tell us about the model or the data?

A model's activations reflect two things: the distribution of the dataset and the way that distribution is transformed by the model. Dictionary learning on activations thus mixes data and model properties, and intriguing properties of learned features may be attributed to either or both sources. Correlations in the data can persist after application of the first part of the model (up to the MLP), and it is in theory possible that the intriguing features we see are merely artifacts of dataset correlations projected into a different space. However, the use of those features by the second half of the model (MLP downprojection and unembedding) are not an input to dictionary learning, so the interpretability of the downstream effects of those features must be a property of the model. To assess the effect of dataset correlations on the interpretability of feature activations, we run dictionary learning on a version of our one-layer model with random weights.We generate a model with random weights by randomly shuffling the entries of each weight matrix of the trained transformer used in Run A. This guarantees that the distributions of individual weights match, and differences are due to structure. The resulting features are here, and contain many single-token features (such as "span", "file", ".", and "nature") and some other features firing on seemingly arbitrary subsets of different broadly recognizable contexts (such as LaTeX or code). However, we are unable to construct interpretations for the non-single-token features that make much sense and invite the reader to examine feature visualizations from the model with randomized weights to confirm this for themselves. We conclude that the learning process for the model creates a richer structure in its activations than the distribution of tokens in the dataset alone. To assess the interpretability of the downstream feature effects, we again use the three main approaches of the previous section:

  1. Logit weight inspection. The logit weights represent the effect of each feature on the logits, and, as demonstrated in our earlier investigations of individual features, they are consistent with the feature activations for the base64, Arabic, and Hebrew features. The reader is invited to inspect logit weights for all features in the visualization.
  2. Feature ablation. We set the value of a feature to zero throughout a context, and record how the loss on each token changes. Ablations are available for all features in the visualization.
  3. Pinned feature sampling. We artificially pinned the value of a feature to a fixed high number and then sample from the model. We find that the generated text matches the interpretation of the feature.

The empirical consistency of feature activations with their downstream effects across all these metrics provides evidence that the features found are being used by the model.


Phenomenology

Ultimately, the goal of our work is to understand neural networks. Decomposition of models into features is simply a means to this end, and one might very reasonably wonder if it's genuinely advancing our overall goal. So, in this section, we'll turn attention to the lessons these features can teach us about neural networks. (We've taken to calling this work of leveraging our theoretical understanding to reason about model properties phenomenology by analogy to phenomenology in physics, and the 2019 ICML workshop on phenomena in deep learning.) One way to do this would be to give a detailed discussion of the features we've found (similar to ), but we believe the best way to get a sense of the features we discovered is simply to browse the interface for exploring features which we've published alongside this paper. The features we find vary enormously, and no concise summary will capture their breadth. Instead, we will largely focus on more abstract properties and patterns that we notice. These abstract properties will be able to inform – although by no means answer – questions like "Are these the real features?" and "What is actually going on in a one-layer model?" We begin by discussing some basic motifs and observations about features. We'll then discuss how the features we relate compare to features in other dictionary learning runs and in other models. This will suggest that features are universal and that dictionary learning can be understood as a process of feature splitting that reflects something deep about the geometry of superposition. Finally, we'll explore how features connect together into "finite state automata" as systems that implement more complex behaviors.

Feature Motifs

What kinds of features do we find in our model? One strong theme is the prevalence of context features (e.g. DNA, base64) and token-in-context features (e.g. the in mathematics – A/0/341, < in HTML – A/0/20).From a purely theoretical lens, attention heads can largely implement "three point functions" (with two inputs, and an output). MLP layers are well positioned to instead implement N-token conjunctions, perhaps the most extreme of which are context features or token-in-context features. Thus, it is perhaps natural that we see many of these. These have been observed in prior work (context features e.g. ; token-in-context features e.g. ; preceding observations ), but the sheer volume of token-in-context features has been striking to us. For example, in A/4, there are over a hundred features which primarily respond to the token "the" in different contexts.Token-in-context features may offer a significant opportunity for simplifying analysis of the model – as Elhage et al. note, it may be possible to understand these features as two-dimensional family of features parameterized by a context and a token. Often these features are connected by feature splitting (discussed in the next section), presenting as pure context features or token features in dictionaries with few learned features, but then splitting into token-in-context features as more features are learned. Another interesting pattern is the implementation of what seem to be "trigram" features, such as a feature that predicts the 19 in COVID-19 (A/2/12310). Such features could in principle be implemented with attention alone, but in practice the model uses the MLP layer as well. We also see features which seem to respond to specific, longer sequences of tokens. These are particularly striking because they may implement "memorization" like behavior – we'll discuss this more later. Finally, it's worth noting that all the features we find in a one-layer model can be interpreted as "action features" in addition to their role as "input features". For example, a base64 feature can be understood both as activating in response to base64 strings, and also as acting to increase the probability of base64 strings. The "action" view can clarify some of the token-in-context features: the feature A/0/341 predicts noun phrases in mathematical text, upweighting nouns like denominator and adjectives like latter. Consequently, while it activates most strongly on the, it also activates on adjectives like special and this which are also followed by noun phrases. This dual interpretation of features can be explored by browsing our interface. Several papers have previously explored interpreting neurons as actions (e.g. ), and one-layer models are particularly suited to this, since it's a particularly principled way to understand the last MLP layer, and the only MLP in a one-layer model is the last layer.

Feature Splitting

One striking thing about the features we’ve found is that they appear in clusters. For instance, we observed above multiple base64 features, multiple Arabic script features, and so on. We see more of these features as we increase the total number of learned sparse features, a phenomenon we refer to as feature splitting. As we go from 512 features in A/0 to 4,096 features in A/1 and to 16,384 features in A/2, the number of features specific to base64 contexts goes from 1 to 3 to many more. To understand how the geometry of the dictionary elements correspond to these qualitative clusters, we do a 2-D UMAP on the combined set of feature directions from A/0, A/1, and A/2. We see clusters corresponding to the base64 and Arabic script features, together with many other tight clusters from specific contexts and a variety of other interesting geometric structures for other features. This confirms that the qualitative clusters are reflected in the geometry of the dictionary: similar features have small angles between their dictionary vectors. We conjecture that there is some idealized set of features that dictionary learning would return if we provided it with an unlimited dictionary size. Often, these "true features" are clustered into sets of similar features, which the model puts in very tight superposition. Because the number of features is restricted, dictionary learning instead returns features which cover approximately the same territory as the idealized features, at the cost of being somewhat less specific. In this picture, the reason the dictionary vectors of conceptually similar features are similar is that they are likely to produce similar behaviors in the model, and so should be responsible for similar effects in the neuron activations. For instance, it would be natural for a feature that fires on periods to predict tokens with a leading space followed by a capital letter. If there are multiple features that fire on periods, perhaps on periods in somewhat different contexts, these might all predict tokens with a leading space, and those predictions might well involve producing similar neuron activations. The combination of features being highly correlated and having similar "output actions", causes real models to have both denser and more structured superposition than what we observed in our previous toy models work .Toy Models considered correlated features (see in particular organization of correlated features and collapsing of correlated features), but only features which were correlated in whether they were active (and not their value if active), and had nothing analogous to the similar "output actions" described here. Nonetheless, Toy Models' experiments may be a useful intuition pump, especially in noticing the distinction between similar features in superposition vs features collapsing into a single broader feature. If this picture is true, it would be important for a number of reasons. It suggests that determining the "correct number of features" for dictionary learning is less important than it might initially seem. It also suggests that dictionary learning with fewer features can provide a "summary" of model features, which might be very important in studying large models. Additionally, it would explain some of the stranger features we observe in the process of dictionary learning, suggesting that these are either "collapsed" features which would make sense if split further (see "Bug" 1: Single Token Features), or else highly-specific "split" features which do in fact make sense if analyzed closely (see "Bug" 2: Multiple Features for a Single Context). Finally, it suggests that our basic theory of superposition in toy models is missing an important dimension of the problem by not adequately studying highly correlated and "action sharing" features.

Example: Mathematics and Physics Features

In this example, our coarsest run (with 512 learned sparse features) has three features describing tokens in different technical settings. Using the masked cosine similarityFor each pair of features, we compute the cosine similarity between their activations on the subset of tokens for which one of them fires. We repeat this, restricting to the subset on which the other fires, and take the greater of the two. We draw a connection between the features if this measure exceeds ~0.4. This threshold was chosen to balance producing a small enough graph to visualize while also showing some of the richness of feature splitting. We omit the ultralow density features from this analysis. between feature activations, we are able to identify how these features refine and split in runs with more learned sparse features. What we see is that the finer runs reveal more fine-grained distinctions between e.g. concepts in technical writing, and distinguish between the articles the and a, which are followed by slightly different sets of noun phrases. We also see that the structure of this refinement is more complex than a tree: rather, the features we find at one level may both split and merge to form refined features at the next. In general though, we see that runs with more learned sparse features tend to be more specific than those with fewer. It's worth noting that these more precise features reflect differences in model predictions as well as activations. The general the in mathematical prose feature (A/0/341) has highly generic mathematical tokens for its top positive logits (e.g. supporting the denominator, the remainder, the theorem), whereas the more finely split machine learning version (A/2/15021) has much more specific topical predictions (e.g. the dataset, the classifier). Likewise, our abstract algebra and topology feature (A/2/4878) supports the quotient and the subgroup, and the gravitation and field theory feature (A/2/2609) supports the gauge, the Lagrangian, and the spacetime.

Features which seemed like Bugs

"Bug" 1: Single-Token Features When we limit dictionary learning to use very few learned sparse features, the features that emerge sometimes look quite strange. In particular, there are a large number of high-activation magnitude features which each only fire on a single token, and which seem to fire on every instance of that token. Such features are strange because the model could achieve the same effect entirely by learning different bigram statistics, and so should have no reason to devote MLP capacity to these. Similar features were also recently observed in a report by Smith . We believe that feature splitting explains this phenomenon: the model hasn’t learned a single feature firing on the letter P,The features fire on the token " P" of words where it appears as the first token, such as [ P][attern]. for instance. Rather, it’s learned many features which fire on P in different contextsIn this instance we found the refined P features by manual inspection rather than by cosine similarity., with correspondingly different effects on the neuron activations and output logits (see below). At a sufficiently coarse level dictionary learning cannot tell the difference between these, but when we allow it to use more learned sparse features, the features split and refine into a zoo of different P features that fire in different contexts. "Bug" 2: Multiple Features for a Single Context We also observed the converse, where multiple features seemed to cover roughly the same concept or context. For example, there were three features in A/1 which fired on (subsets of) base64 strings, and predicted plausible base64 tokens like zf, mF, and Gp. One of these features was discussed in detail earlier, where we showed it fired for base64 strings. But we also observed that it didn't fire for all base64 strings – why? And what are the other two features doing? Why are there three? In A/0 (with 512 features), the story is simple. There is only one base64-related feature, A/0/45, which seems to activate on all tokens of base64-encoded strings. But in A/1, that feature splits into three different features whose activations seem to jointly cover those of A/0/45: Two of these features seem relatively straightforward. A/1/2357 seems to fire preferentially on letters in base64, while A/1/2364 seems to fire preferentially on digits. Comparing the logit weights of these features reveals that they predict largely the same sets of tokens, with one significant difference: the feature that fires on digits has much lower logit weights for predicting digits. Put another way, if the present token is made of digits, the model will predict that the next token is a non-digit base64 token. We believe this is likely an artifact of tokenization! If a single digit were followed by another digit, they would have been tokenized together as a single token; [Bq][8][9][mp] would never occur, as it would be tokenized instead as [Bq][89][mp]. Thus even in a random base64 string, the fact that the current token is a single digit gives information about the next token. But what about the third feature, A/1/1544? At first glance, there isn't an obvious rule for when it fires. But if we look more closely, we notice that it seems to respond to base64 strings which encode ASCII text.Our initial clue that A/1/1544 might fire on base64 strings encoding ASCII text was the token ICAgICAg which this feature particularly responds to, and corresponds to six spaces in a row. If we look at the top dataset examples for each feature, we find that examples for A/1/1544 contain substrings which decode as ASCII, while none of the top activating examples for A/1/2357 or A/1/2364 do:Determining when a dataset example encodes ASCII text is somewhat subtle because base64 can only be decoded to ASCII in groups of four characters, since four base64 characters encode triples of ASCII characters. Thus, we select substrings which – when decoded with the python base64 library – contain the maximal number of printable ASCII characters. This pattern of investigation, where one looks at coarser sets of features to understand categories of model behavior, and then at more refined sets of features to investigate the subtleties of that behavior, may prove well adapted to larger models where the feature set is expected to be quite large. It's also worth noting how dictionary learning features were able to surprise us here. Many approaches to interpretability are top-down, and look for things we expect. But who would have known that models not only have a base64 feature, but that they distinguish between distinct kinds of base64 strings? This reminds us of cases like high-low frequency detectors or multimodal neurons where surprising and unexpected features were discovered in vision models.

Universality

One of the biggest "meta questions" about features is whether they're universal – do the same features form across different models? This question is generally important because it bears on whether the hard-earned lessons from studying one model will generalize to others. But it's especially important in the context of attempting to extract features from superposition because universality could provide significant evidence that the features we're extracting are "real", or at least reproducible.In what sense does universality suggest features are "real"? One basic observation is that they suggest the features we're finding are not just artifacts of the dictionary learning process – or at least that if they come from the dictionary learning process, it's in some consistent way. But there are also several deeper ways in which it's suggestive. It means that, whatever the source of the features, we can talk about features as replicable, reliable, recurring units of analysis. It's also just a surprising observation that one would expect if a strong version of the features in superposition hypothesis was true and models were literally representing some finite, discrete set of features in superposition. Earlier, we saw that all the features we performed detailed analyses of (e.g. the Arabic feature, or base64 feature) were universal between two one-layer models. But is this true for typical features in our model? And how broadly is it true – do we only observe the same feature if we train models of the same architectures on the same dataset, or do these features also occur in more divergent models? This section will seek to address these two questions. The first subsection will quantitatively analyze how widespread universality is between the two one-layer models we studied, while the second will compare the features we find to others reported in the literature in search of a stronger form of universality. We observe substantial universality of both types.In fact, we found some features so universal that we began to take it for granted as a basic tool in our workflow of evaluating dictionary learning runs. For example, the base64 feature – which we previously observed in SoLU models – was so consistently universal that its presence was a useful debugging heuristic. At a high-level, this makes sense: if a feature is useful to one model in representing the dataset, it's likely useful to others, and if two models represent the same feature then a good dictionary learning algorithm should find it.

Comparing features between two one-layer transformers

To compare features from different models, we need model-independent ways to represent a feature. One natural approach is to think of a feature as a function assigning values to datapoints; two features would be similar in this sense if they take similar values over a diverse set of data. This general approach has been explored by a number of prior papers (e.g. ). In practice, this can be approximated by representing the feature as a vector, with indices corresponding to a fixed set of data points. We call the correlations between these vectors the activation similarity between features. A second natural approach is to think of a feature in terms of its downstream effects; two features would be similar in this sense if their activation changes their models' predictions in similar ways. In our one-layer model, a simple approximation to this is the logit weights. This approximation represents each feature as a vector with indices corresponding to vocabulary tokens. We call the correlations between these vectors the logit weight similarity between features. These two notions of similarity correspond to the correlations of the points in the two scatter plots we used when analyzing individual features earlier. We've reproduced the plots for the Arabic feature below: For each feature in run A/1, we find the closest feature by activation similarity in run B/1, which is a different dictionary learning run trained on different activations from a different transformer with different random seeds but otherwise identical hyperparameters. We find that many features are highly similar between models, with features in A/1 having a median activation correlation of 0.72 with the most similar feature from B/1. (We perform the same analysis finding the closest neurons between the transformers, and find significantly less similarity, with median activation correlation 0.46.) The features with low activation correlation between models may represent different "feature splittings" in the dictionaries learned or different "true features" learned by the base models. A natural next question is whether features that fire on the same tokens also have the same logit effects. That is, how well do activation similarity and logit weight similarity agree? Some gap between the two is visible for the Arabic feature above: the "important tokens" for the features' effects (the ones in Arabic script) are upweighted by features from both models, but there is a large cloud of tokens with smaller effects that appear to almost be isotropic noise, resulting in a logit weight correlation of just 0.23, significantly below the activation correlation of 0.91. In the scatterplot below, we find that this kind of disagreement is widespread. The most dramatic example of this disparity is for the features A/1/3949 and B/1/3321, with an activation correlation of 0.98 but a negative logit weight correlation. These features fire on pone (and occasionally on pgen and pcbi) as abbreviations for the journal name PLOSOne in citations, like @pone.0082392, and predict the . that follows.The feature is bimodal, monosemantic in the larger of the modes, and fires on 0.02% of tokens. This means that at least 1 in 10,000 tokens in the Pile dataset are abbreviations for PLoS journals in citations! This is an example of how inspecting features can reveal properties of the dataset, in this case the strong bias of the Pile towards scientific content. Zooming in on the logit weight scatterplot (inset in the figure above), we see that only the . token has high logit weight in both models, and that every other token is in the 'interference' portion of the logit weight distribution. Indeed, the model may simply not care about what the feature does to tokens which were already implausible because they are suppressed by the direct path, attention layer, or other features of the MLP. We want to measure something more like "the actual effect a feature has on token probabilities." One way to get at this would be to compute a vector of ablation effects for every feature on every data point; pairs of features whose ablations hurt the model's predictions on the same tokens must have been predicting the same thing. Unfortunately, this would be rather expensive computationally. Instead, we scale the activation vector of a feature by the logit weights of the tokens that empirically come next in the dataset to produce an attribution vector.Suppose feature f_i has logit weights v_{ik} for k \in \{1,\ldots,n_{\text{vocab}}\}. At a given token t_j, we compute the activation of the feature f_i(t_j) and multiply it by the logit weight v_{it_{j+1}} of the token t_{j+1} that comes next to get an attribution score of f_i(t_j)v_{it_{j+1}}. The attribution vector is given by stacking the attribution scores for a random sampling of datapoints. This approximates the classic attribution method of multiplying the gradient by the activation, differing in that we ignore the denominators of the softmax and the layer norm. Correlations between those vectors provide an attribution similarity that combines both the activity of the feature with the effect it has on the loss. We find that the attribution similarity correlates quite highly with the activation similarity, meaning that features that were coactive between models were useful at predicting the same tokens. In light of this, we feel that the activation correlation used throughout the paper is in fact a good proxy for both notions of universality in the context of our one-layer models.

Comparing features with the literature

So far, we've established that many of our features are universal in a limited sense. Features found in one of our transformers can also be found in an alternative version trained with a different random seed. But this second model has an identical architecture and was trained on identical data. This is the most minimal version of universality one could hope for. Despite this, we believe that many of the features we've found are universal in a deeper sense, because very similar features have been reported in the literature before. The first comparison which struck us is that many features seem quite similar to neurons we previously found in one-layer SoLU models, which use an activation function designed to make neurons more monosemantic . In particular, we observed a base64 neuron, hexadecimal neuron, and all caps neuron in our SoLU investigations, and base64 (A/0/45), hexadecimal (A/0/119), and all caps (A/0/317) features here. Discussion of some of these neurons can be found in Section 6.3.1 of the SoLU paper. We also find many features similar to Smith , who applies dictionary learning to the residual stream. In addition to us also observing preponderance of single token features they note (see our interpretation of this phenomenon), we find a similar German detector (e.g. A/0/493) and similar title case detectors (e.g. A/0/508). Likewise, we find a number of features similar to Gurnee et al. , including a "prime factors" feature (A/4/22414) and a French feature (A/0/14). At a more abstract level, many features we find seem similar to features reported in multimodal models by Goh et al. . For example, we find many similar features including an Australia feature (A/3/16085), Canada feature (A/3/13683), Africa feature (A/3/14490), and Israel-Palestine feature (A/3/739) which predict locations in those regions when grammatically appropriate. This vaguely mirrors "region neurons" reported by Goh et al.'s paper. For other families of features, the parallels are less clear. For example, one of the most striking results of Goh et al. was person detector neurons (similar to famous results in neuroscience). We find some features that are person detectors in very narrow contexts, such as responding to a person’s name and predicting appropriate next words, or predicting their name (e.g. A/1/3240 is somewhat similar to Goh et al.'s Trump neuron), but they seem quite narrow. We also don't find features that seem clearly analogous to Goh et al.'s emotion neurons.

"Finite State Automata"

One of the most striking phenomena we've observed in our study of the features in one-layer models is the existence of "finite state automata"-like assemblies of features. These assemblies aren't circuits in the conventional sense – they're formed by one feature increasing the probability of tokens, which in turn cause another feature to fire on the next step, and so on.The "finite state automata"-esque feature assemblies are also different from circuits in that the model didn't learn them to work together. Rather, in the course of learning to autoregressively model text, it learned features that interact via the token stream because of patterns in the real datasets. In contrast, a language model trained with reinforcement learning might have systems like this – circuits whose feature components interact via generated tokens – which co-evolved and adapted to work together during RL training. The simplest example of this is features which excite themselves on the next token, forming a single node loop. For example, a base64 feature increases the probability of tokens like Qg and zA – plausible continuations which would continue to activate it. It's worth noting that these examples are from A/0, a dictionary learning run which is not overcomplete (the dictionary dimensionality is 512, equal to the transformer MLP dimension). As we move to runs with larger numbers of features, the central feature will experience feature splitting, and become a more complex system. Let's now consider a two-node system for producing variables in "all caps snake case" (e.g. ARRAY_MAX_VALUE). One node (A/0/207) activates on the all caps text tokens, the other (A/0/358) on underscores: This type of two-node system is quite common for languages where Unicode characters are sometimes split into two tokens. (Again, with more feature splitting, these would expand into more complex systems.) For example, Tamil Unicode characters (block U+0B80–U+0BFF) are typically split into two tokens. For example, the character "ண" (U+0BA3) is tokenized as \xe0\xae followed by \xa3. The first part (\xe0\xae or \xe0\xaf) roughly specifies the Unicode block, while the second component specifies the character within that block. Thus, it's natural for the model to alternate between two features, one for the Unicode prefix token, and one for the suffix token. A more complex example is Chinese. While many common Chinese characters get dedicated tokens, many others are split. This is further complicated by Chinese characters being spread over many Unicode blocks, and those blocks being large and cutting across many logical blocks specified in terms of bytes. To understand the state machine the model implements to handle this, the key observation is that complete characters are similar to the "suffix" part of a split character: both can be followed by either a new complete character, or a new prefix. Thus, we observe two features, one of which fires on either complete characters or the suffix (predicting either a new complete character, or a prefix), while the other only fires on the prefixes and predicts suffixes. Let's now consider a very simple four node system which models HTML. The "main path" through it is:

A prototypical sample this might generate is something like <div>\n\t\t<span>. The full system can be seen below: Keep in mind that we're focusing on the A/0 features where this is very simple – if we looked at A/1, we'd find something much more complex! One particularly striking shortcoming of the A/0 features is that they don't describe what happens when A/0/0 emits a token like href, which leads to a more complex state. It's important to note that these features can be quite contextual. There are several features related to IRC transcripts which form a totally different finite state automata like system: A prototypical sample this might generate is something like <nickonia_> lol ubuntu ;). Presumably the Pile dataset heavily represents IRC transcripts about linux. One particularly interesting behavior is the apparent memorization of specific phrases. This can be observed only in runs with relatively large numbers of features (like A/4). In the following example, a sequence of features seem to functionally memorize the bolded part of the phrase MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This is a relatively standard legal language, and notably occurs in the file headers for popular open source software licenses, meaning the model likely saw it many times during training. This seems like an example of the mechanistic theory of memorization we described in Henighan et al. – we observe features which appear to be relatively binary and respond to a very specific situation. This might also be seen as an instance of mechanistic anomaly detection : the model behaves differently in a specific, narrow case. It's somewhat surprising that something so narrow can be found in a model with only 512 neurons; from this perspective it's an interesting example of superposition's ability to embed many things in few neurons. On the other hand, because these mechanisms are buried deep in superposition, they are likely very noisy.


Related Work

Superposition and attempts to resolve it have deep connections to many lines of research, including general investigations of interpretable features, linear probing, compressed sensing, dictionary learning and sparse coding, theories of neural coding, distributed representations, mathematical frames, vector symbolic architectures, and much more. Rather than attempt to do justice to all these connections here, we refer readers to the related work section of Toy Models of Superposition where we discuss these topics in depth, and also to our essay Distributed Representations: Composition & Superposition . Instead, we'll focus our discussion on work connected to our attempts to solve superposition, and also more recent advancements in our understanding of superposition.

Superposition

Since we published Toy Models of Superposition there has been significant further work attempting to better understand superposition. We briefly summarize below. Is superposition real? Gurnee et al. demonstrate some compelling examples of features which may be in superposition, using sparse linear probes. Separately, an exchange between Li et al. and Nanda et al. seems like an update on whether the general picture of features as directions is correct; Li et al. seemed to show that it wasn't, putting the hypothesis in jeopardy, which was then resolved by Nanda et al. When and why does superposition occur? Scherlis et al. provide a mathematical framework for thinking about monosemanticity vs polysemanticity. lsgos explored the effects of dropout on toy models of superposition. Memorization – In Henighan et al. , we studied the same toy model as in Toy Models of Superposition, but this time trained on many repetitions of finite-sized datasets. We found that small datasets are memorized in superposition, instead of generalizing features in the case of large datasets. Hobbhahn replicated some of these findings, and further showed extensions to other settings including bottlenecks between layers (analogous to the residual stream between MLP layers). Subsequently, in a monthly update we examined the boundary between the memorization and generalization regimes and found a sharp phase transition, as well as dataset clustering in superposition on the memorization side of the boundary.

Disentanglement and Architectural Approaches

There is also a rich and related literature on disentanglement, which seeks to find representations of data that separate out (disentangle) conceptually-distinct phenomena influencing the data. In contrast to superposition, this work typically seeks to find a number of factors of variation or features which are equal to the dimensionality of the space being represented, whereas superposition seeks to find more. This is often approached as an architecture/training-time problem. For instance, Kim & Mnih proposed a method that pushes variational autoencoders to disentangle factors by encouraging independence across dimensions. Similarly, Chen et al. developed a Generative Adversarial Network approach that attempts to disentangle factors by maximizing the mutual information between a small subset of factors and the dataset. And Makhzani & Frey use a TopK activation to encourage sparsity and hence disentanglement. See Bengio et al. and Räuker et al. for a discussion of other such approaches. Framed this way, some architectural approaches to superposition may also be understood as attempts at disentanglement. For instance, in Elhage et al. , we proposed the SoLU activation function, which increases the number of interpretable neurons in transformers by encouraging features to align to the neuron basis. Unfortunately, it appears that training models with the SoLU activation function may make some neurons more interpretable at the cost of making others even less interpretable than before. Similarly, Jermyn et al. studied MLP layers trained on a compressed sensing task and found multiple equal-loss minima, with some strongly polysemantic and others strongly monosemantic. This suggested that training interventions could steer models towards more monosemantic minima, though subsequent investigations on more realistic tasks suggested that the equal-loss property was specific to the chosen task. These two examples of attempts to tackle superposition through architecture, and the challenges they encountered, highlight a key distinction between the problems of disentanglement and that of superposition: disentanglement fundamentally seeks to ensure that the dimensions in the model’s latent space are disentangled, whereas superposition hypothesizes that this disentanglement typically hurts performance (since success would require throwing away many features), and that models will typically respond to disentangling interventions by making some features more strongly entangled (as was found by both Mahinpei et al. and Elhage et al. 2022 in somewhat different contexts).

Dictionary Learning and Features

Our work builds on a longer tradition of using dictionary learning and sparse autoencoders to decompose neural network activations. Early work in this space focused on word embeddings and other non-transformer neural networks. Faruqui et al. and Arora et al. both found linear structure in word embeddings using sparse coding approaches. Subramanian et al. similarly found linear factors for word embeddings, in this case using a sparse autoencoder. Zhang et al. solved a similar problem using methods from dictionary learning while Panigrahi et al. approached this with Latent Dirichlet Allocation. More recently, a number of works have applied dictionary learning methods to transformer models. Yun et al. applied dictionary learning to the residual stream of a 12-layer transformer to find an undercomplete basis of features. At this point, our work in Toy Models advocated for dictionary learning as a potential approach to superposition. This motivated a parallel investigation by our colleagues Cunningham et al., published as a series of interim reports with very similar themes to this paper, culminating in a manuscript . We've been excited to see so many corroborating findings between our work. In their interim reports, Sharkey et al. used sparse autoencoders to perform dictionary learning on a one-layer transformer, identifying a large (overcomplete) basis of features. (Sharkey et al. deserve credit for focusing on dictionary learning and especially the sparse autoencoder approach, while our investigation was only exploring it as one of several approaches in parallel.) This work was then partially replicated by Cunningham & Smith and Huben . Next, Smith used an autoencoder to find features in one MLP layer of a six-layer model. The resulting features appear interpretable, e.g. detecting ‘$’ in the context of LaTeX equations. In follow up work, Smith then extended this approach to the residual stream of the same model, identifying a number of interesting features (see earlier discussion). Building on these results, Cunningham applied autointerpretability techniques from Bills et al. to features in the residual stream and an MLP layer of the same six-layer model, finding that the features discovered by the sparse autoencoder are substantially more interpretable than neurons.


Discussion

Theories of Superposition

Coming into this work, our understanding of superposition was mostly informed by Toy Models . This gave us a picture one might call the isotropic superposition model. Features are discrete, one-dimensional objects which repel from each other due to interference, creating a roughly evenly spaced organization of feature directions. This work has persuaded us that our previous model was missing something crucial. At a minimum, features seem to clump together in higher density groups of related features. One explanation for this (considered briefly by Toy Models) is that the features may have correlated activations – firing together. Another – which we suspect to be more central – is that the features produce similar actions. The feature which fires on single digits in base64 predicts approximately the same set of tokens as the feature firing on other characters in base64, with the exception of other digits; these similar downstream effects manifest as geometrically close feature directions. Moreover, it isn't clear that features need to be one-dimensional objects (encoding only some intensity). In principle, it seems possible to have higher-dimensional "feature manifolds" (see earlier discussion here). These hypotheses are not mutually exclusive. The convex hull of several correlated features might be understood as a feature manifold. On the other hand, some manifolds would not admit a unique description in terms of a finite number of one-dimensional features. (Perhaps this accounts for the continued feature splitting observed above.) Nevertheless, these experiments have left us more confident that some version of the superposition hypothesis (and the linear representation hypothesis) is true. The number of interpretable features found, the way activation level seems to correspond to "intensity" or "confidence," the fact that logit weights mostly make sense, and the observation of "interference weights": all of these observations are what you would expect from superposition. Finally, we note that in some of these expanded theories of superposition, finding the "correct number of features" may not be well-posed. In others, there is a true number of features, but getting it exactly right is less essential because we "fail gracefully", observing the "true features" at resolutions of different granularity as we increase the number of learned features in the autoencoder.

Are "Token in Context" Features Real?

One of the most common motifs we found were "token-in-context" features. They also represent many of the features that emerge via feature splitting with increasing dictionary size. Some of these are intuitive – borrowing an example from , it makes sense to represent "die" in German (where it's the definite article) as distinct from "die" in English (where it means "death" or "dice"). But why do we see hundreds of different features for "the" (such as "the" in Physics, as distinct from "the" in mathematics)? We also observe this for other common words (e.g. "a", "of"), and for punctuation like periods. These features are not what we expected to find when we set out to investigate one-layer models! To make the question a bit more precise, it is helpful to borrow the language and examples of local vs compositional representations . Individually representing token-context pairs (such as "the" in Physics) is technically a "local code". The more intuitive way to represent this would instead be a "compositional code" – representing "the" as an independent feature from Physics. So the thing we really want to ask is why we're observing a local code, and whether it's really what's going on. There are two hypotheses:

If the former holds, then better dictionary learning schemes may help uncover a more compositional set of features from the same transformer. Local codes are sparser than compositional codes, and our L1 penalty may be pushing the model too far towards sparsity. However, we believe the second hypothesis is likely to hold to some extent. Let's consider the example of "the" in Physics again, which predicts noun phrases in Physics: if the model represented "the" and Physics context independently, it would be forced to have logits be the sum of "upweight tokens which come after the" and "upweight tokens which occur in Physics". But the model might wish to have "sharper" predictions than this, which is only possible with a local code.

Future Work

Scaling Sparse Autoencoders. Scaling the application of sparse autoencoders to frontier models strikes us as one of the most important questions going forward. We're quite hopeful that these or similar methods will work – Cunningham et al.'s work seems to suggest this approach can work on somewhat larger models, and we have preliminary results that point in the same direction. However, there are significant computational challenges to be overcome. Consider an autoencoder with a 100× expansion factor applied to the activations of a single MLP layer of width 10,000: it would have ~20 billion parameters. Additionally, many of these features are likely quite rare, potentially requiring the autoencoder to be trained on a substantial fraction of the large model's training corpus. So it seems plausible that training the autoencoder could become very expensive, potentially even more expensive than the original model. We remain optimistic, however, and there is a silver lining – it increasingly seems like a large chunk of the mechanistic interpretability agenda will now turn on succeeding at a difficult engineering and scaling problem, which frontier AI labs have significant expertise in. Scaling Laws for Dictionary Learning. It's worth noting that there's enormous uncertainty about the dynamics of scaling dictionary learning and sparse autoencoders discussed above. As we make the subject model bigger, how does the ideal expansion factor change? (Does it stay constant?) How does the necessary amount of data change? The resolution of these questions will determine whether it's possible for this approach, if executed well, to scale up to frontier models. Ideally, we'd like to have scaling laws which could answer this. How Can We Recognize Good Features? One of the greatest challenges of this work is that we're "wandering in the dark" to some extent. We don't have a great, systematic way to know if we're successfully extracting high quality features. Automated interpretability seems like a strong contender for solving this question. Alternatively, one might hope for some purely abstract definition (e.g. the information-based metric proposal), but we have not yet seen compelling signs of life for this on real data. It would also be helpful to have metrics beyond MMCS, activation similarity, and attribution similarity for comparing sets of features for the purposes of assessing consistency and universality. Scalability of Analysis. Suppose that sparse autoencoders fully solve superposition. Do we have a home run to fully mechanistically understanding models? It seems clear that there would be at least one other fundamental barrier: scaling analysis of models, so that we can turn microscopic insights into a more macroscopic understanding. Again, one approach here could be automated interpretability. But delegating the understanding of AI to AI may not be fully satisfying, for various reasons. It is possible that there may be other paths based on discovering larger scale structure (see discussion here). Algorithmic Improvements for Sparse Autoencoders. New algorithms refining the sparse autoencoder approach could be useful. One might explore the use of variational autoencoders (e.g., ), or sparsity promoting priors regularization techniques beyond a simple L1 penalty on activations (e.g., ), for example encouraging sparsity in the interactions between learned features in different layers. Earlier research has shown that noise injection can also increase neuron interpretability separately from an L1 penalty . Attentional Superposition? Many of the motivations for the presence of superposition in MLP layers apply to self-attention layers as well. It seems conceivable that similar methods may extract useful structure from attention layers, although a clear example has not yet been established (e.g., see our May and July Updates). If this is true, addressing this may become a future bottleneck for the mechanistic interpretability agenda. Theory of Superposition and Features. Many fundamental questions remain for our understanding of superposition, even if the hypothesis is right in some very broad sense. For example, as discussed above, this work suggests extensions of the superposition hypothesis covering clusters of features with similar effects, or continuous families of features. We believe there is important work to be done in exploring the theory of superposition further, perhaps through the use of toy models.


Comments & Replications

Inspired by the original Circuits Thread and Distill's Discussion Article experiment, the authors invited several external researchers who we had previously discussed our preliminary results with to comment on this work. Their comments are included below.

Replication & Tutorial

Neel Nanda is an external mechanistic interpretability researcher. This is a summary of a blog post replicating and extending this paper, with an accompanying tutorial to load some trained autoencoders and practice interpreting a feature. The core results of this paper seem to replicate. I trained a sparse autoencoder on the MLP layer of an open source 1 layer GELU language model, and a significant fraction of the latent space features were interpretable. I've open sourced two trained autoencoders and a tutorial for how to use them, and how to interpret a feature. I've also open sourced a (very!) rough training codebase, along with some of the implementation details that came up, and tips for training your own. I investigated how sparse the decoder weights are in the neuron basis and find that they’re highly distributed, with 4% well explained by a single neuron, 4% well explained by 2 to 10, and the remaining 92% dense. I find this pretty surprising! Despite this, kurtosis shows the neuron basis is still privileged. I also exhibit some case studies of the features I found, like a title case feature, and an "and I" feature I didn’t find any dead features, but more than half of the features form an ultra-low frequency cluster (frequency less than 1e-4). Surprisingly, I find that this cluster is almost all the same feature (in terms of encoder weights, but not in terms of decoder weights). On one input 95% of these ultra rare features fired!

One question from this work is whether the encoder and decoder should be tied. I find that, empirically, the decoder and encoder weights for each feature are moderately different, with median cosine similarity of only 0.5, which is empirical evidence they're doing different things and should not be tied. Conceptually, the encoder and decoder are doing different things: the encoder is detecting, finding the optimal direction to project onto to detect the feature, minimising interference with other similar features, while the decoder is trying to represent the feature, and tries to approximate the “true” feature direction regardless of any interference.

Author Contributions Statement

Infrastructure, Tooling, and Core Algorithmic Work

General Infrastructure – The basic framework for our dictionary learning work was built and maintained by Adly Templeton, Trenton Bricken, Tom Henighan, and Tristan Hume. Adly Templeton, in collaboration with Trenton Bricken and Tom Conerly, performed the engineering to scale up our experiments to large numbers of tokens. Robert Lasenby created tooling that allowed us to train extremely small language models. Yifan Wu imported the "Pile" dataset so we could train models on a standard external dataset. Tom Conerly broadly assisted with our infrastructure and maintaining high code quality. Adly Templeton implemented automatic plots comparing different experiments in a scan. Sparse Autoencoders (Algorithms / ML) – Trenton initially implemented and advocated for sparse autoencoders as an approach to dictionary learning. Trenton Bricken and Adly Templeton then collaborated on the research needed to achieve our results, including scanning hyperparameters, iterating on algorithms, introducing the "neuron resampling" method, and characterizing the importance of dataset scale. (It's hard for the other authors to communicate just how much work Trenton Bricken and Adly Templeton put into iterating on algorithms and hyperparameters.) Josh Batson assisted by analyzing runs and designing metrics with Chris Olah, Adly Templeton and Trenton Bricken to measure success. Analysis Infrastructure – The tooling to collect data for the visualizations was created by Trenton Bricken and Adly Templeton. Tom Conerly greatly accelerated this. Adly Templeton implemented the tooling to perform large scale feature ablation analysis, as well as creating the shuffled weights models as baselines. Interface – The interface for visualizing and exploring features was created by Brian Chen, with support from Shan Carter. It replaced a much earlier version by Trenton Bricken.

Analysis

Feature Deep Dives – The dataset examples and ablations came from Brian Chen's interface work and Adly Templeton's ablation infrastructure. Chris Olah developed the activation spectrum plots, broken down by proxy. Josh Batson developed the logit scatter plot visualization and the sensitivity analysis. Tom Henighan created the pinned sampling visualizations. Nick Turner, Josh Batson and Tom Henighan explored how best to analyze neuron alignment. Many people contributed to a push to systematically analyze many features in detail, including Tom Henighan, Josh Batson, Trenton Bricken, Adly Templeton, Nick Turner, Brian Chen, and Chris Olah. Manual Analysis of Features – Nick Turner and Adam Jermyn created our rubric for evaluating if a feature interval is interpretable. Adam Jermyn manually scored a random set of features. Automated Interpretability – Our automated interpretability pipeline was created by Trenton Bricken, Cem Anil, Carson Denison, and Amanda Askell. Trenton Bricken ran the experiments using it to evaluate our features. This built on earlier explorations of automated interpretability by Shauna Kravec, and was only possible due to infrastructure contributions by Tim Maxwell, Nicholas Schiefer, and Nicholas Joseph. Feature Splitting – Josh Batson, Adam Jermyn, and Chris Olah analyzed feature splitting. Shan Carter produced the UMAPs of features. Universality – Josh Batson analyzed universality, with engineering support from Trenton Bricken and Tom Henighan. "Finite State Automata" – Chris Olah analyzed "Finite State Automata".

Paper Production

Writing – The manuscript was primarily drafted by Chris Olah, Josh Batson, and Adam Jermyn, with extensive feedback and editing from all other authors. The detailed appendix on dictionary learning was drafted by Adly Templeton and Trenton Bricken. Josh Batson and Chris Olah managed the revision process in response to internal and external feedback. Illustration – Diagrams were created by Chris Olah, Josh Batson, Adam Jermyn, and Shan Carter, based on data generated by themselves and others.

Development of Intuition & Negative Results

Early Dictionary Learning Experiments – Many of the authors (including Trenton Bricken, Adly Templeton, Tristan Hume, Tom Henighan, Adam Jermyn, Josh Batson, and Chris Olah) did experiments applying both more traditional dictionary learning methods and sparse autoencoders to a variety of toy problems and small MNIST models. Much of this work focused on finding metrics which we hoped would tell us whether dictionary learning had succeeded in a simple context. These experiments, along with theoretical work, built valuable intuition and helped us discover several algorithmic improvements, and clarified challenges with traditional dictionary learning. Sparse Architectures – Brian Chen ran the experiments and generated the counter-examples which persuaded us that training models for sparse activations was less promising. Crucially, he produced models where neurons typically activated in isolation, and showed they were still polysemantic. He then produced the counter-example described in the text. Robert Lasenby implemented infrastructure that made it easier to experiment with sparse activation architectures.

Other

Support – Alex Tamkin, Karina Nguyen, Brayden McLean, and Josiah E Burke made a variety of contributions through infrastructure, operational support, labeling features, and commenting on the draft. Leadership – Tom Henighan led the dictionary learning project. Tristan Hume led an early version of the project, before handing it over to Tom Henighan. Shan Carter managed the overall team. Chris Olah provided general research guidance.

Acknowledgments

We are deeply grateful to Martin Wattenberg, Neel Nanda, Hoagy Cunningham, David Lindner, Logan Smith, Steven Bills, William Saunders, Jonathan Marcus, Daniel Mossing, Nick Cammarata, Robert Huben, Aidan Ewart, Nicholas Sofroniew, Anna Golubeva, Bruno Olshausen for their detailed comments and feedback, which greatly improved our work. We are also grateful to our colleagues at Anthropic who generously provided feedback, and many of whom also helped us explore the features discovered by dictionary learning as part of a "Feature Party". We particularly thank Oliver Rausch, Pujaa Rajan, Anna Chen, Alexander Silverstein, Marat Freytsis, Maryam Mortazavi, Mike Lambert, Justin Spahr-Summers, Emmanuel Ameisen, Andre Callahan, Shannon Yang, Zachary Witten, Zac Hatfield-Dodds, Karina Nguyen, Avital Balwit, Amanda Askell, Brayden McLean, and Nicholas Schiefer. Our work is only possible because of the extensive support of all our colleagues at Anthropic, from infrastructure, to engineering, to operations and more. It's impossible for us to list all the people whose work indirectly supported this paper, because there are so many, but we're deeply grateful for their support.

Citation Information

Please cite as:

Bricken, et al., "Towards Monosemanticity: Decomposing Language Models With Dictionary Learning", Transformer Circuits Thread, 2023.

BibTeX Citation:

    @article{bricken2023monosemanticity,
       title={Towards Monosemanticity: Decomposing Language Models With Dictionary Learning},
       author={Bricken, Trenton and Templeton, Adly and Batson, Joshua and Chen, Brian and Jermyn, Adam and Conerly, Tom and Turner, Nick and Anil, Cem and Denison, Carson and Askell, Amanda and Lasenby, Robert and Wu, Yifan and Kravec, Shauna and Schiefer, Nicholas and Maxwell, Tim and Joseph, Nicholas and Hatfield-Dodds, Zac and Tamkin, Alex and Nguyen, Karina and McLean, Brayden and Burke, Josiah E and Hume, Tristan and Carter, Shan and Henighan, Tom and Olah, Christopher},
       year={2023},
       journal={Transformer Circuits Thread},
       note={https://transformer-circuits.pub/2023/monosemantic-features/index.html}
    }

Feature Proxies

In order to analyze features, we construct "proxies" for each feature which can be easily computed. Our proxies are the log-likelihood ratio of a string under the feature hypothesis and under the full empirical distribution. For example, \log(P(s|\text{base64}) / P(s)) or \log(P(s|\text{Arabic Script}) / P(s)). We use log-likelihood proxies on the intuition that features, since they linearly interact with the logits, will be incentivized to track log-likelihoods. Since the activation of a feature at a token may be in part due to the preceding tokens (for example the Arabic feature could fire more strongly towards the end of a long Arabic string), we maximize the log-likelihood ratio over different prefixes leading up to and including the final token. But how can we estimate the different terms? Let's consider each part separately.

Estimating P(s)

To compute P(s), we use the unigram distribution over tokens and compute P(s) = \prod_{t\in s} p(t).

Estimating P(s|\text{base64}) (and other characters features)

For base64, we assume that we're modeling a random base64 string where the probability of a character c is P(c) = 1/64 if it's in a base64 character, and 10^{-10} otherwise. We then compute P(s) = \prod_{c\in s} P(c). We model DNA as a random string of [ATCG], each with probability 1/4. (Although we don't use them in this draft, we also found this approach helpful for hexadecimal, binary, and similar features.)

Estimating P(s|\text{Arabic}) (and other scripts features)

We also construct proxies for languages written in scripts that use distinctive unicode blocks. We'll use Arabic as an example of this. For P(s|\text{Arabic}), we use Bayes rule (i.e. P(s|\text{Arabic}) = P(\text{Arabic}|s) \cdot P(s) / P(\text{Arabic})). For P(s), we use the method discussed above. For the other terms, we exploit the fact that it is easy to detect whether a character is in a Unicode block associated with Arabic script (including e.g. U+0600–U+06FF, U+0750–U+077F). Note this will count common characters shared between languages, like punctuation, as non-Arabic characters. If a string s consists entirely of Arabic characters, P(Arabic|s) is 1; if it contains non-Arabic characters, P(\text{Arabic}|s) is assigned a tiny probability of 1e−10. (Keep in mind that we will be maximizing over multiple prefix strings.) If s consists of a single token which isn't a complete unicode character, we sample random occurrences of it and observe the fraction of the time it is used in a given script. We also estimate P(\text{Arabic}) by applying this heuristic to a random sample of the dataset.

Feature Ablations

We perform feature ablations by running the model on an entire context up through the MLP layer, running the autoencoder to compute feature activations, subtracting the feature direction times its activation from the MLP activation on each token in the context (replacing \mathbf{x}^j with \mathbf{x}^j - f_i(\mathbf{x}^j)\mathbf{d}_j) and then completing the forward pass. We record the resulting change in the predicted log-likelihood of each token in the context in the color of an underline of that token. Thus if a feature were active on token [B] in the sequence [A][B][C], and ablating that feature reduced the odds placed on the prediction of C, then there would be an orange background on [B] (the activation) and a blue underline on [C] (the ablation effect), indicating that ablating that feature increased the model’s loss on the prediction of [C] and hence that feature is responsible for improving the model’s ability to predict [C] in that context.

Feature Interpretability Rubric

Our rubric for scoring how interpretable features are has the following instructions:

  1. Form an interpretation of the feature based on the positive logits and feature activations across all intervals.
  2. On a scale of 0–3, rate your confidence in this interpretation.
  3. On a scale of 0–5, rate how consistent the high-activation (bolded) tokens are with your interpretation from (1).
  4. On a scale of 0–3, rate how consistent the positive logit effects are with your interpretation from (1).
  5. If some of the positive logit effects were inconsistent with your interpretation, was there a separation in effect size between the consistent and inconsistent ones? If so, score as 1, otherwise or if not applicable, score as 0.
  6. On a scale of 0–3, how specific is your interpretation of this feature?

The total score for a feature’s interpretability is the sum of ratings across these steps. Note that the maximum score is 14, because a perfect score on item #4 implies that item #5 is not applicable.

Feature Density Histograms

While iterating on different techniques, one important proxy for autoencoder performance is feature density. Each feature in our autoencoder only activates on a very small percentage of the total tokens in the training set. We define the feature density of each feature as the fraction of tokens on which the feature has a nonzero value. We hypothesize that language models contain a large number of features across a distribution of feature densities, and that lower-density features are harder for our autoencoder to discover because they appear less often in the training dataset. Using large training datasets was an attempt to recover such low-density features. As one way to measure the performance of an autoencoder, we take all the feature densities and plot a histogram of their distribution on a log scale. Roughly, we look for two histogram metrics: the number of features we’ve recovered, and the minimum feature density among features that we’ve recovered. Anecdotally, we find that these metrics are a decent proxy for subjective autoencoder performance and useful for quick iteration cycles. Ideally, the autoencoder neurons would be either meaningful features or completely dead. Indeed, training does completely leave some autoencoder neurons unused. Many neurons, however, seem to fall into a third category, which we tentatively name the ultralow density cluster. Many of the feature density histograms are bimodal. For example, consider the feature density histogram for A/16: This histogram has two main modes: a left mode around 10^{-7} (corresponding to the ultralow density cluster) and a right mode around 10^{-5}.The right mode in this example may actually be split into two modes, one around 10^{-5} and another around 10^{-3}. We are still investigating the nature of this split. We call the right mode the “high density cluster”, although the absolute magnitude of the density is very low. Anecdotally, almost all of the features in the high density cluster are interpretable, but almost none of the features in the ultralow density cluster are. As an aside, we suspect that this bimodality in feature density might partially explain the bimodality in cross-dictionary MCS observed by Huben . In many preliminary small-scale experiments, the two clusters are often perfectly separable. However, for runs with a large number of autoencoder neurons and a large L1 coefficient these two clusters often overlap. Even in these cases, the two clusters can be separated by combining other statistics. For each feature, in addition to density, we plot the bias and the dot product of the vectors in the decoder and the encoder corresponding to each feature. Along these three dimensions, the high density cluster is clearly separable. The ultralow density cluster appears to be an artifact of the autoencoder training process and not a real property of the underlying transformer. We are continuing to investigate the source of this phenomenon and other ways to either mitigate these features or to robustly automatically detect and filter them. Below, we present feature density histograms for all Seed A runs, grouped by L1 coefficient. As we increase the number of autoencoder neurons (or “N learned sparse”), we continue to discover not only more features but also rarer features, suggesting that we have not exhausted the features in our one-layer transformer.

Transformer Training and Preprocessing

The one-layer transformers we study are trained on the Pile . We chose to train these models on the Pile over Anthropic's internal dataset in order to make our experiments more reproducible. While we think many features are universal, others are very likely idiosyncratic to the dataset. We train the transformers on 100 billion tokens using the Adam optimizer . We hypothesize that a very high number of training tokens may allow our model to learn cleaner representations in superposition. These transformers have a residual stream dimension of 128, and an inner MLP dimension of 512. The MLP activation is a ReLU.

Advice for Training Sparse Autoencoders: Autoencoder Dataset and Basic Training

To create the dataset for autoencoder training, we evaluate the transformers on 40 million contexts from the Pile and collect the MLP activation vectors after the ReLU for each token within each context. We then sample activation vectors from 250 tokens in each context and shuffle these together so that samples within a batch come from diverse contexts. For training, we sample MLP activation vectors without replacement using a batch size of 8192. We’ve found that sampling without replacement (i.e., not repeating data) is important for optimal results. We perform 1 million update steps, using just over 8 billion activation vectors out of the total dataset size of 10 billion. We use an Adam optimizer to minimize the sum of mean squared error loss and an L1 regularization penalty on the hidden layer activations of the autoencoder.

Advice for Training Sparse Autoencoders: Autoencoder Architecture

Our dictionary learning model is a one hidden layer MLP. It is trained as an autoencoder, using the input weights as an encoder and output weights as the decoder. The hidden layer is much wider than the inputs and applies a ReLU non-linearity. We use the default Pytorch Kaiming Uniform initialization . Formally, let n be the input and output dimension and m be the autoencoder hidden layer dimension. Given encoder weights W_e \in \mathbb{R}^{m \times n}, decoder weights W_d \in \mathbb{R}^{n \times m} with columns of unit norm, and biases \mathbf{b}_e \in \mathbb{R}^{m}, \mathbf{b}d \in \mathbb{R}^{n}, the operations and loss function over a dataset X are: \begin{aligned} \bar{\mathbf{x}} &= \mathbf{x} - \mathbf{b}{d} \\ \mathbf{f} &= \text{ReLU}( W_e \bar{\mathbf{x}}+\mathbf{b}_e ) \\ \hat{\mathbf{x}} &= W_d \mathbf{f}+\mathbf{b}d \\ \mathcal{L} &= \frac{1}{|X|} \sum{\mathbf{x}\in X} ||\mathbf{x}-\hat{\mathbf{x}}||_2^2 + \lambda||\mathbf{f}||_1 \end{aligned} Note that our hidden layer is overcomplete m\geq n, and the MSE is a mean over each vector element while the L1 penalty is a sum (with \lambda being the L1 coefficient). The hidden layer activations \mathbf{f} are our learned features. As shown, we subtract the decoder bias from the inputs, and call this a pre-encoder bias. Recall that the decoder is also referred to as the “dictionary” while the encoder can be thought of as a linear, amortized approximation to more powerful sparse coding algorithms. Our modifications to a standard autoencoder are backed by theory and empirical ablations. However, because these modifications appeared at different periods during our research and can interact with each other, we do not provide rigorous ablation experiments and instead provide intuition and anecdotal evidence for why each is justified. There are likely many important modifications that could further improve performance. Here is a summary of the modifications sorted both between and within sections in rough order of importance

Pre-Encoder Bias

Testing the autoencoder on toy problems with a bias, we found that it would fail to produce the “bounce plots” we described previously unless we added a learned bias term to both the decoder output and the encoder input. We constrain the pre-encoder bias to equal the negative of the post-decoder bias and initialize it to the geometric median of the dataset. These investigations were motivated by the observations by Hobbhahn .

Decoder Weights Not Tied

It is common to tie the encoder and decoder weights of single hidden layer autoencoders . However, we find that in our trained models the learned encoder weights are not the transpose of the decoder weights and are cleverly offset to increase representational capacity. Specifically, we find that similar features which have closely related dictionary vectors have encoder weights that are offset so that they prevent crosstalk between the noisy feature inputs and confusion between the distinct features. For example, in "Bug" 2: Multiple Features for a Single Context we described 3 features handling different types of base64 strings. These all have similar dictionary vectors, but it turns out that the encoder weight vectors, while still similar, are more tilted away to help distinguish them. One way of viewing this is that our autoencoder is learning an amortized, linear approximation to a multi-step, non linear sparse coding algorithm. Allowing the weights of the encoder to be independent from the decoder enables more representational capacity as we empirically observe.

Neuron Resampling

Over the course of training, a subset of autoencoder neurons will have zero activity across a large number of datapoints. We find that “resampling” these dead neurons during training improves the number of likely-interpretable features (i.e., those in the high density cluster, see Feature Density Histograms) and reduces total loss. This resampling may be compatible with the Lottery Ticket Hypothesis and increase the number of chances the network has to find promising feature directions. An interesting nuance around dead neurons involves the ultralow density cluster. We find that if we increase the number of training steps then networks will kill off more of these ultralow density neurons. This reinforces the use of the high density cluster as a useful metric because there can exist neurons that are de facto dead but will not appear to be when looking at the number of dead neurons alone. The number of dead neurons that appear over training appears to depend upon a number of factors including but not limited to: learning rate (too high); batch size (too low); dataset redundancy (too many tokens per context or repeated epochs over the same dataset); number of training steps (too many); optimizer used. Our results here agree with those of Bricken et al. . Better resampling strategies is an active research area of ours. The approach used in this work is as follows:

  1. At training steps 25,000, 50,000, 75,000 and 100,000, identify which neurons have not fired in any of the previous 12,500 training steps.
  2. Compute the loss for the current model on a random subset of 819,200 inputs.
  3. Assign each input vector a probability of being picked that is proportional to the square of the autoencoder’s loss on that input.
  4. For each dead neuron sample an input according to these probabilities. Renormalize the input vector to have unit L2 norm and set this to be the dictionary vector for the dead autoencoder neuron.
  5. For the corresponding encoder vector, renormalize the input vector to equal the average norm of the encoder weights for alive neurons × 0.2. Set the corresponding encoder bias element to zero.
  6. Reset the Adam optimizer parameters for every modified weight and bias term.

This resampling procedure is designed to seed new features to fit inputs where the current autoencoder performs worst. Resetting the encoder norm and bias are crucial to ensuring this resampled neuron will only fire weakly for inputs similar to the one used for its reinitialization. We do this to minimize interference with the rest of the network. This resampling approach outperforms baselines including no resampling and reinitializing the relevant encoder and decoder weights using a default Kaiming Uniform initialization. However, there are likely better resampling methods to be developed – this approach still causes sudden loss spikes, and resampling too frequently causes training to diverge.

Learning Rate Sweep

We performed several training runs using multiple learning rates while also varying the number of training steps and found that lower learning rates, when given sufficient training steps, result in lower total loss and more “real” features discovered (as indicated by the Feature Density Histograms). We also tried annealing our learning rate over the course of training but found that this did not further increase performance.

Interaction Between Adam and Decoder Normalization

Recall that we constrain our dictionary vectors to have unit norm. Our first naive implementation simply reset all vectors to unit norm after each gradient step. This means any gradient updates modifying the length of our vector are removed, creating a discrepancy between the gradient used by the Adam optimizer and the true gradient. We find that instead removing any gradient information parallel to our dictionary vectors before applying the gradient step results in a small but real reduction in total loss.

Advice for Training Sparse Autoencoders: Hyperparameter Selection

The ultimate goal of dictionary learning is to produce features that are interpretable and also accurately represent the underlying model. Quantitatively measuring interpretability is currently difficult and slow, so we frequently look at proxy metrics when testing changes or optimizing hyperparameters. Our methods for optimizing hyperparameters are far from perfect, but we want to share insights that may be useful for other researchers doing similar work. We most frequently look at the following proxy metrics:

We often normalize this by dividing by the difference in loss between the baseline transformer’s performance and its performance after ablating the MLP layer. This gives us a fraction of the MLP’s loss contribution that is explained by our transformer. However, the performance with an ablated MLP may be an especially bad baseline, so this percentage is considered an overestimate. Ad hoc experiments (data not shown) show that similarly high percentages can be reached by training a transformer from scratch with a small MLP. The L^0 norm and Reconstructed Transformer NLL metrics, taken together, display a human-interpretable tradeoff between sparsity and explained behavior: Each line on this plot shows data for a single L1 coefficient and varying autoencoder sizes. The lowest L1 coefficient is excluded to create a reasonable scale.

Activation Visualization

Visualizations were produced using a 100 million token subset of our training dataset where only 10 tokens are taken from every context. We display a window of four tokens on each side of the selected token for visualization.

Feature UMAPs

We construct two UMAP embeddings of learned features from our transformer. We represent each feature as a vector of dimension 512 (the number of neurons), its column in the decoder matrix W_d. The first UMAP embeds the features from A/0 and A/1 jointly into 2 dimensions, and uses hyperparameters n_neighbors=15, metric="cosine", min_dist=0.05. The second UMAP uses the same hyperparameters, but with min_dist=0.01, and also includes the features from A/2. We additionally organize the points in the first UMAP into clusters by applying HDBSCAN with min_cluster_size=3 to a 10-dimensional UMAP embedding of the same features, fit with hyperparameters n_neighbors=15, metric="cosine", min_dist=0.1. The list of features is sorted by a one-dimensional UMAP fit to the unclustered features and the cluster mediods.

Automated Interpretability

Here we provide more details on the implementation of our automated interpretability before explaining importance scoring and providing additional results.

Experimental Setup

In order to get feature explanations Claude 2 is provided with a total of 49 examples: ten examples from the top activations interval; two from the other 12 intervals; five completely random examples; and ten examples where the top activating tokens appear in different contexts.We are explicit in keeping all of these examples separate from the ones used when we test on activation predictions.For example, in the main text we discuss a feature that fires for token "the" in the context of machine learning, the ten examples here would contain the word "the" but across different contexts. We also provide the top and bottom logits and labels for what interval each example came from. In addition, we give eight human demonstrations on held out features that include chain of thought reasoning. Following Bills et al. all of our activations are quantized to be between 0–9 inclusive. Finally, we ask the model to be succinct in its answer and not provide specific examples of tokens it activates for. Using the explanation generated, in a new interaction Claude is asked to predict activations for sixty examples: six from the top activations; two from the other 12 intervals; ten completely random; and twenty top activating tokens out of context. The same eight held out demonstration features show how each token should elicit a predicted activation. All of the examples are shuffled, the logits and interval each came from is removed, and blanks are left where the model should fill in its activation predictions. For the sake of computational efficiency, Claude scores all sixty examples in a single shot, repeating each token followed by its predicted activation. In an ideal setting, each example would be given independently as its own prompt. Note that there are instances where a feature has less than 49 explanation examples and 60 prediction examples because we remove any repeated examples that appear in the feature visualization intervals. However, this occurs for a negligible number of features and we drop any of those with fewer than 20 examples in total. For the sake of comparison to Bills et al. the figure below includes Pearson correlation in addition to Spearman that is otherwise used throughout the text. The distributions and overall conclusions are almost identical to Spearman. We also systematically catalog the feature output weight logits with Claude. We use the same explanation Claude generated to predict activations and provide 100 logits, 50 taken randomly and 50 which are the 10th–60th largest positive logits (the top 10 were used to generate the original explanations and thus held out). Claude was asked to output a binary label for if this logit would plausibly come after the feature fired, given the explanation. Note that the chance performance is 50%. The A/1 features are quite a bit better than the neurons at a median of 0.74 versus 0.53 for the neurons and 0.5 for the randomized transformer.

Randomized Transformer

As a further ablation, we compare our human and automated interpretability approaches to the randomized transformer. It is unsurprising that the logit weight predictions are centered around random chance for the randomized transformer by the very nature of its random weights. Manual interpretability also favors the A/1 features. However, for automated interpretability the randomized features have a higher median score. It turns out that the randomized transformer features are distinctly bimodal, consisting of single token and polysemantic clusters which are separated out in the inset at the bottom of the following figure. Features are labeled as being "single token" if for all 20 examples in the top activation interval, the token with the largest activation is the same. The single token features of the randomized transformer are not only more numerous but also more truly single token, for example, firing for the same token even in the weakest activation intervals. This makes them more trivial to score as evidenced by the high scoring yellow peak (bottom row left side of the figure). Meanwhile, for the not "single token" cluster, the A/1 features score higher while the randomized features in fact have a similar distribution to that of the polysemantic neurons. Note that this bimodal clustering of the randomized transformer features is also supported by the manual human analysis where there is both a cluster at 0, the same score given to the polysemantic neurons in the main text, and a non zero cluster. The non-zero cluster scores worse than the A/1 Features here (unlike for the automated approach) because part of the rubric accounts for the logit interpretability, which scores zero in the shuffled case. The fact that the randomized transformer learns more highly single token features fits with the hypothesis that dictionary learning will learn the features of the dataset rather than the representations of the transformer.

Importance Scoring

Importance scoring is the principled way to correct for the fact that we did not randomly sample all of the examples our model is asked to score. Formally, we assign to all tokens from random examples a weight of 1 and examples from each feature interval a weight of feature_density*interval_probability. feature_density is the fraction of times this feature fires over a large portion of the dataset and interval_probability converts the distribution of non-zero activations into a categorical distribution corresponding to each interval and uses the corresponding probability. We then use these weights in our Spearman correlation as before.The top activating tokens out of context examples inherit the weighting of the top activating examples quantile. The issue with importance scoring is that because our features have densities typically in the range of 1e−3 to 1e−6 (see next Appendix section), almost all of the weight is assigned to the random examples for which features almost never fire. As a result, it is possible for features to score well by almost always predicting zero and in turn favors explanations that are overly restrictive that say what the feature does not fire for, instead of what it does fire for. Conversely, explanations are highly penalized for even a small false positive rate, since the true rate of occurrences is so low. The figure below shows importance scores for features and neurons. Note that many of the features now have scores very close to zero while the neurons are relatively less affected. We hypothesize this is because the neurons, in being more polysemantic, have more non-zero activations that test their explanations on both things it does and doesn't fire for. Empirically, taking an average over features, 88% of their true activations from the random examples are zero versus 54% for the neurons (the medians are ~91% and 58%, respectively).

Explanation Lengths Caveat

Claude can at times fail to wrap its explanation in the <answer></answer> explanation tags resulting in the full chain of thought being used instead. This can be much longer and leak more specific words that the feature fires for. Here we plot the number of characters in each explanation where the second mode to the right highlights these instances. However, not only does this happen infrequently, it also occurs across the features, neurons, and randomized transformer results. In fact, it happens the most often for neurons, occurring 19% of the time versus 15% for the randomized transformer and 13% for the features. Most importantly, it does not result in significantly different scores when we split out the performance of those with long explanations from short ones. To conclude, while automated interpretability is a difficult task for models that we have only begun working on, it has already been very useful for quickly understanding dictionary learning features in a scalable fashion. We encourage readers to explore the visualizations with automated interpretability scores: A/1, A/0, randomized model features, neurons.

Footnotes

  1. For more discussion of this point, see Distributed Representations: Composition and Superposition.[↩]
  2. We'd particularly highlight an exciting exchange between Li et al. and Nanda et al. : Li et al. found an apparent counterexample where features were not represented as directions, which was then resolved by Nanda finding an alternative interpretation in which features were directions.[↩]
  3. While not the focus of this paper, we could also imagine decomposing other portions of the model’s latent state or activations in this way. For instance, we could apply this decomposition to the residual stream (see e.g. ), or to the keys and queries of attention heads, or to their outputs.[↩]
  4. This property is closely related to the desiderata of Causality, Generality, and Purity discussed in Cammarata et al. , and those provide an example of how we might make this property concrete in a specific instance.[↩]
  5. This is similar in spirit to the evidence provided by influence functions.[↩]
  6. For the model discussed in this paper, we trained the autoencoder on 8 billion datapoints.[↩]
  7. We tie the biases applied in the input and output, so the result is equivalent to subtracting a fixed bias from all activations and then using an autoencoder whose only bias is before the encoder activation.[↩]
  8. Note that using an MSE loss avoids the challenges with polysemanticity that we discussed above in Why Not Architectural Approaches?[↩]
  9. Note that this linear structure makes it even more likely that features should be linear. On the one hand, this means that the linear representation hypothesis is more likely to hold for this model. On the other hand, it potentially means that our results are less likely to generalize to multilayer models. Fortunately, others have studied multilayer transformers with sparse autoencoders and found interpretable linear features, which gives us more confidence that what we see in the one-layer model indeed generalizes .[↩]
  10. For example, one neuron in our transformer model responds to a mix of academic citations, English dialogue, HTTP requests, and Korean text. In vision models, there is a classic example of a neuron which responds to cat faces and fronts of cars .[↩]
  11. This kind of split tokenization is common for Unicode characters outside the Latin script and the most common characters from other Unicode blocks.[↩]
  12. For example, in the figure above, there is a newline character ⏎ that our feature fires on but our proxy assigns a low score to because it is outside the Unicode block.[↩]
  13. Why do we believe large activations have larger effects? In the case of a one-layer transformer like the one we consider in this paper, we can make a strong case for this: features have a linear effect on the logits (modulo rescaling by layer norm), and so a larger activation of the feature has a larger effect on the logits. In the case of larger models, this follows from a lot of conjectures and heuristic arguments (e.g. the abundance of linear pathways in the model and the idea of linear features at each layer), and must be true for sufficiently small activations by continuity, but doesn't have a watertight argument.[↩]
  14. (also called “logit attribution”, see similar work e.g. )[↩]
  15. We exclude weights corresponding to extremely rare or never used vocabulary elements. These are perhaps similar to the "anomalous tokens" (e.g., "SolidGoldMagikarp") of Rumbelow & Watkins .[↩]
  16. There are in theory several ways the logit weights could overestimate the model's actual use of a feature:
  17. It could be that these output weights are small enough that, when multiplied by activations, they don't have an appreciable effect on the model’s output.
  18. The feature might only activate in situations where other features make these tokens extremely unlikely, such that the feature in fact has little effect.
  19. It is possible that our approximation of linearizing the layer norm (see Framework ) is poor.
    Based on the subsequent analysis, which confirms the logit weight effects, we do not believe these issues arise in practice.[↩]
  20. Of course, some features might genuinely be neuron aligned. But we'd like to know that at least some of the features dictionary learning discovers were not trivial.[↩]
  21. We also tried looking at the neurons which have the largest contribution to the dictionary vector for the feature. However, we found looking at the most correlated neuron to be more reliable – in earlier experiments, we found rare cases where the correlated method found a seemingly similar neuron, while the dictionary method did not. This may be because neurons can have different scales of activations.[↩]
  22. This makes sense as a superposition strategy: since languages are essentially mutually exclusive, they're natural to put in superposition with each other[↩]
  23. By analogy, this also applies to B/1/1334.[↩]
  24. "Activation correlation" is defined as the feature whose activations across 40,960,000 tokens has the highest Pearson correlation with those of A/1/3450.[↩]
  25. In order to sample uniformly across the spectrum of feature activations, we divide the activation spectrum into 11 "activation intervals" evenly spaced between 0 activation and the maximum activation. We sample uniformly from these intervals.[↩]
  26. It's worth explicitly stating that our automated interpretability setup was designed to ensure that there's no leak of information about activation patterns, except for the explanation. For example, when predicting new activations, the model cannot see any true activations of that feature.[↩]
  27. This is distinct from the evaluation strategy of Bills et al., who calculated their correlation of predicted and true activations on a mixture of maximal dataset examples and random samples. For sparse features, which don't fire on most random samples, this effectively tests the model's ability to distinguish a feature's large activations from zero.[↩]
  28. In instances where Claude predicts a constant score, most often all 0s, a correlation can't be computed and we assign a score of zero which explains the uptick there.[↩]
  29. with respect to the effect it has on the model outputs see e.g. the activation expected value plot in Arabic Feature's Activations Specificity Analysis.[↩]
  30. Naively, simulating a layer with 100k features would be 100,000 times more expensive than sampling a large language model such as Claude 2 or GPT-4 (we'd need to sample the explaining large model once for every feature at every token). At current prices, this would suggest simulating 100k features on a single 4096 token context would cost $12,500–$25,000, and one would presumably need to evaluate over many contexts.[↩]
  31. We generate a model with random weights by randomly shuffling the entries of each weight matrix of the trained transformer used in Run A. This guarantees that the distributions of individual weights match, and differences are due to structure.[↩]
  32. From a purely theoretical lens, attention heads can largely implement "three point functions" (with two inputs, and an output). MLP layers are well positioned to instead implement N-token conjunctions, perhaps the most extreme of which are context features or token-in-context features. Thus, it is perhaps natural that we see many of these.[↩]
  33. Token-in-context features may offer a significant opportunity for simplifying analysis of the model – as Elhage et al. note, it may be possible to understand these features as two-dimensional family of features parameterized by a context and a token.[↩]
  34. Toy Models considered correlated features (see in particular organization of correlated features and collapsing of correlated features), but only features which were correlated in whether they were active (and not their value if active), and had nothing analogous to the similar "output actions" described here. Nonetheless, Toy Models' experiments may be a useful intuition pump, especially in noticing the distinction between similar features in superposition vs features collapsing into a single broader feature.[↩]
  35. For each pair of features, we compute the cosine similarity between their activations on the subset of tokens for which one of them fires. We repeat this, restricting to the subset on which the other fires, and take the greater of the two. We draw a connection between the features if this measure exceeds ~0.4. This threshold was chosen to balance producing a small enough graph to visualize while also showing some of the richness of feature splitting. We omit the ultralow density features from this analysis.[↩]
  36. The features fire on the token " P" of words where it appears as the first token, such as [ P][attern].[↩]
  37. In this instance we found the refined P features by manual inspection rather than by cosine similarity.[↩]
  38. Our initial clue that A/1/1544 might fire on base64 strings encoding ASCII text was the token ICAgICAg which this feature particularly responds to, and corresponds to six spaces in a row.[↩]
  39. Determining when a dataset example encodes ASCII text is somewhat subtle because base64 can only be decoded to ASCII in groups of four characters, since four base64 characters encode triples of ASCII characters. Thus, we select substrings which – when decoded with the python base64 library – contain the maximal number of printable ASCII characters.[↩]
  40. In what sense does universality suggest features are "real"? One basic observation is that they suggest the features we're finding are not just artifacts of the dictionary learning process – or at least that if they come from the dictionary learning process, it's in some consistent way. But there are also several deeper ways in which it's suggestive. It means that, whatever the source of the features, we can talk about features as replicable, reliable, recurring units of analysis. It's also just a surprising observation that one would expect if a strong version of the features in superposition hypothesis was true and models were literally representing some finite, discrete set of features in superposition.[↩]
  41. In fact, we found some features so universal that we began to take it for granted as a basic tool in our workflow of evaluating dictionary learning runs. For example, the base64 feature – which we previously observed in SoLU models – was so consistently universal that its presence was a useful debugging heuristic.[↩]
  42. The feature is bimodal, monosemantic in the larger of the modes, and fires on 0.02% of tokens. This means that at least 1 in 10,000 tokens in the Pile dataset are abbreviations for PLoS journals in citations! This is an example of how inspecting features can reveal properties of the dataset, in this case the strong bias of the Pile towards scientific content.[↩]
  43. Suppose feature f_i has logit weights v_{ik} for k \in \{1,\ldots,n_{\text{vocab}}\}. At a given token t_j, we compute the activation of the feature f_i(t_j) and multiply it by the logit weight v_{it_{j+1}} of the token t_{j+1} that comes next to get an attribution score of f_i(t_j)v_{it_{j+1}}. The attribution vector is given by stacking the attribution scores for a random sampling of datapoints. This approximates the classic attribution method of multiplying the gradient by the activation, differing in that we ignore the denominators of the softmax and the layer norm.[↩]
  44. The "finite state automata"-esque feature assemblies are also different from circuits in that the model didn't learn them to work together. Rather, in the course of learning to autoregressively model text, it learned features that interact via the token stream because of patterns in the real datasets. In contrast, a language model trained with reinforcement learning might have systems like this – circuits whose feature components interact via generated tokens – which co-evolved and adapted to work together during RL training.[↩]
  45. The right mode in this example may actually be split into two modes, one around 10^{-5} and another around 10^{-3}. We are still investigating the nature of this split.[↩]
  46. We are explicit in keeping all of these examples separate from the ones used when we test on activation predictions.[↩]
  47. The top activating tokens out of context examples inherit the weighting of the top activating examples quantile.[↩]

References

  1. Feature Visualization [link]
    Olah, C., Mordvintsev, A. and Schubert, L., 2017. Distill. DOI: 10.23915/distill.00007
  2. Linear algebraic structure of word senses, with applications to polysemy
    Arora, S., Li, Y., Liang, Y., Ma, T. and Risteski, A., 2018. Transactions of the Association for Computational Linguistics, Vol 6, pp. 483–495. MIT Press.
  3. Decoding The Thought Vector [link]
    Goh, G., 2016.
  4. Zoom In: An Introduction to Circuits
    Olah, C., Cammarata, N., Schubert, L., Goh, G., Petrov, M. and Carter, S., 2020. Distill. DOI: 10.23915/distill.00024.001
  5. Toy Models of Superposition
    Elhage, N., Hume, T., Olsson, C., Schiefer, N., Henighan, T., Kravec, S., Hatfield-Dodds, Z., Lasenby, R., Drain, D., Chen, C., Grosse, R., McCandlish, S., Kaplan, J., Amodei, D., Wattenberg, M. and Olah, C., 2022. Transformer Circuits Thread.
  6. Sparse overcomplete word vector representations
    Faruqui, M., Tsvetkov, Y., Yogatama, D., Dyer, C. and Smith, N., 2015. arXiv preprint arXiv:1506.02004.
  7. Spine: Sparse interpretable neural embeddings
    Subramanian, A., Pruthi, D., Jhamtani, H., Berg-Kirkpatrick, T. and Hovy, E., 2018. Proceedings of the AAAI Conference on Artificial Intelligence, Vol 32(1).
  8. Word embedding visualization via dictionary learning
    Zhang, J., Chen, Y., Cheung, B. and Olshausen, B.A., 2019. arXiv preprint arXiv:1910.03833.
  9. Word2Sense: sparse interpretable word embeddings
    Panigrahi, A., Simhadri, H.V. and Bhattacharyya, C., 2019. Proceedings of the 57th Annual Meeting of the Association for Computational Linguistics, pp. 5692–5705.
  10. Transformer visualization via dictionary learning: contextualized embedding as a linear superposition of transformer factors
    Yun, Z., Chen, Y., Olshausen, B.A. and LeCun, Y., 2021. arXiv preprint arXiv:2103.15949.
  11. [Interim research report] Taking features out of superposition with sparse autoencoders [link]
    Sharkey, L., Braun, D. and Millidge, B., 2022.
  12. [Replication] Conjecture's Sparse Coding in Toy Models [link]
    Cunningham, H. and Smith, L., 2023.
  13. [Research Update] Sparse Autoencoder features are bimodal [link]
    Huben, R., 2023.
  14. (tentatively) Found 600+ Monosemantic Features in a Small LM Using Sparse Autoencoders [link]
    Smith, L., 2023.
  15. Really Strong Features Found in Residual Stream [link]
    Smith, L., 2023.
  16. AutoInterpretation Finds Sparse Coding Beats Alternatives [link]
    Cunningham, H., 2023.
  17. Sparse Autoencoders Find Highly Interpretable Model Directions [PDF]
    Cunningham, H., Ewart, A., Smith, L., Huben, R. and Sharkey, L., 2023. arXiv preprint arXiv:2309.08600.
  18. A Mathematical Framework for Transformer Circuits [HTML]
    Elhage, N., Nanda, N., Olsson, C., Henighan, T., Joseph, N., Mann, B., Askell, A., Bai, Y., Chen, A., Conerly, T., DasSarma, N., Drain, D., Ganguli, D., Hatfield-Dodds, Z., Hernandez, D., Jones, A., Kernion, J., Lovitt, L., Ndousse, K., Amodei, D., Brown, T., Clark, J., Kaplan, J., McCandlish, S. and Olah, C., 2021. Transformer Circuits Thread.
  19. The Pile: An 800GB Dataset of Diverse Text for Language Modeling
    Gao, L., Biderman, S., Black, S., Golding, L., Hoppe, T., Foster, C., Phang, J., He, H., Thite, A., Nabeshima, N., Presser, S. and Leahy, C., 2020.
  20. Linguistic regularities in continuous space word representations [PDF]
    Mikolov, T., Yih, W. and Zweig, G., 2013. Proceedings of the 2013 conference of the north american chapter of the association for computational linguistics: Human language technologies, pp. 746–751.
  21. Linguistic regularities in sparse and explicit word representations
    Levy, O. and Goldberg, Y., 2014. Proceedings of the eighteenth conference on computational natural language learning, pp. 171–180.
  22. Unsupervised representation learning with deep convolutional generative adversarial networks
    Radford, A., Metz, L. and Chintala, S., 2015. arXiv preprint arXiv:1511.06434.
  23. Visualizing and understanding recurrent networks [PDF]
    Karpathy, A., Johnson, J. and Fei-Fei, L., 2015. arXiv preprint arXiv:1506.02078.
  24. Learning to generate reviews and discovering sentiment [PDF]
    Radford, A., Jozefowicz, R. and Sutskever, I., 2017. arXiv preprint arXiv:1704.01444.
  25. Curve Detectors [link]
    Cammarata, N., Goh, G., Carter, S., Schubert, L., Petrov, M. and Olah, C., 2020. Distill.
  26. Object detectors emerge in deep scene cnns [PDF]
    Zhou, B., Khosla, A., Lapedriza, A., Oliva, A. and Torralba, A., 2014. arXiv preprint arXiv:1412.6856.
  27. Network Dissection: Quantifying Interpretability of Deep Visual Representations [PDF]
    Bau, D., Zhou, B., Khosla, A., Oliva, A. and Torralba, A., 2017. Computer Vision and Pattern Recognition.
  28. Understanding the role of individual units in a deep neural network
    Bau, D., Zhu, J., Strobelt, H., Lapedriza, A., Zhou, B. and Torralba, A., 2020. Proceedings of the National Academy of Sciences, Vol 117(48), pp. 30071–30078. National Acad Sciences.
  29. On the importance of single directions for generalization [PDF]
    Morcos, A.S., Barrett, D.G., Rabinowitz, N.C. and Botvinick, M., 2018. arXiv preprint arXiv:1803.06959.
  30. On Interpretability and Feature Representations: An Analysis of the Sentiment Neuron
    Donnelly, J. and Roegiest, A., 2019. European Conference on Information Retrieval, pp. 795–802.
  31. Emergent Linear Representations in World Models of Self-Supervised Sequence Models
    Nanda, N., Lee, A. and Wattenberg, M., 2023. arXiv preprint arXiv:2309.00941.
  32. Discovering latent knowledge in language models without supervision
    Burns, C., Ye, H., Klein, D. and Steinhardt, J., 2022. arXiv preprint arXiv:2212.03827.
  33. Acquisition of chess knowledge in alphazero
    McGrath, T., Kapishnikov, A., Toma{\v{s}}ev, N., Pearce, A., Wattenberg, M., Hassabis, D., Kim, B., Paquet, U. and Kramnik, V., 2022. Proceedings of the National Academy of Sciences, Vol 119(47), pp. e2206625119. National Acad Sciences.
  34. Emergent world representations: Exploring a sequence model trained on a synthetic task
    Li, K., Hopkins, A.K., Bau, D., Viégas, F., Pfister, H. and Wattenberg, M., 2022. arXiv preprint arXiv:2210.13382.
  35. Engineering monosemanticity in toy models
    Jermyn, A.S., Schiefer, N. and Hubinger, E., 2022. arXiv preprint arXiv:2211.09169.
  36. Polysemanticity and capacity in neural networks
    Scherlis, A., Sachan, K., Jermyn, A.S., Benton, J. and Shlegeris, B., 2022. arXiv preprint arXiv:2210.01892.
  37. Sparse coding with an overcomplete basis set: A strategy employed by V1?
    Olshausen, B.A. and Field, D.J., 1997. Vision research, Vol 37(23), pp. 3311–3325. Elsevier.
  38. Softmax Linear Units
    Elhage, N., Hume, T., Olsson, C., Nanda, N., Henighan, T., Johnston, S., ElShowk, S., Joseph, N., DasSarma, N., Mann, B., Hernandez, D., Askell, A., Ndousse, K., Jones, A., Drain, D., Chen, A., Bai, Y., Ganguli, D., Lovitt, L., Hatfield-Dodds, Z., Kernion, J., Conerly, T., Kravec, S., Fort, S., Kadavath, S., Jacobson, J., Tran-Johnson, E., Kaplan, J., Clark, J., Brown, T., McCandlish, S., Amodei, D. and Olah, C., 2022. Transformer Circuits Thread.
  39. Sparse and redundant representations: from theory to applications in signal and image processing
    Elad, M., 2010. Vol 2(1). Springer.
  40. Method of optimal directions for frame design
    Engan, K., Aase, S.O. and Husoy, J.H., 1999. 1999 IEEE International Conference on Acoustics, Speech, and Signal Processing. Proceedings. ICASSP99 (Cat. No. 99CH36258), Vol 5, pp. 2443–2446.
  41. K-SVD: An algorithm for designing overcomplete dictionaries for sparse representation
    Aharon, M., Elad, M. and Bruckstein, A., 2006. IEEE Transactions on signal processing, Vol 54(11), pp. 4311–4322. IEEE.
  42. Attribution Patching: Activation Patching At Industrial Scale [link]
    Nanda, N., 2023.
  43. SolidGoldMagikarp (plus, prompt generation) [link]
    Rumbelow, J. and Watkins, M., 2023.
  44. Distributed Representations: Composition & Superposition [HTML]
    Olah, C., 2023.
  45. Language models can explain neurons in language models [HTML]
    Bills, S., Cammarata, N., Mossing, D., Tillman, H., Gao, L., Goh, G., Sutskever, I., Leike, J., Wu, J. and Saunders, W., 2023.
  46. Natural language descriptions of deep visual features
    Hernandez, E., Schwettmann, S., Bau, D., Bagashvili, T., Torralba, A. and Andreas, J., 2021. International Conference on Learning Representations.
  47. An Overview of Early Vision in InceptionV1
    Olah, C., Cammarata, N., Schubert, L., Goh, G., Petrov, M. and Carter, S., 2020. Distill. DOI: 10.23915/distill.00024.002
  48. Multimodal Neurons in Artificial Neural Networks
    Goh, G., Cammarata, N., Voss, C., Carter, S., Petrov, M., Schubert, L., Radford, A. and Olah, C., 2021. Distill. DOI: 10.23915/distill.00030
  49. Finding Neurons in a Haystack: Case Studies with Sparse Probing
    Gurnee, W., Nanda, N., Pauly, M., Harvey, K., Troitskii, D. and Bertsimas, D., 2023. arXiv preprint arXiv:2305.01610.
  50. Visualizing and measuring the geometry of BERT
    Coenen, A., Reif, E., Yuan, A., Kim, B., Pearce, A., Viégas, F. and Wattenberg, M., 2019. Advances in Neural Information Processing Systems, Vol 32.
  51. Transformer Feed-Forward Layers Build Predictions by Promoting Concepts in the Vocabulary Space
    Geva, M., Caciularu, A., Wang, K.R. and Goldberg, Y., 2022. arXiv preprint arXiv:2203.14680.
  52. High-Low Frequency Detectors
    Schubert, L., Voss, C., Cammarata, N., Goh, G. and Olah, C., 2021. Distill. DOI: 10.23915/distill.00024.005
  53. Convergent learning: Do different neural networks learn the same representations?
    Li, Y., Yosinski, J., Clune, J., Lipson, H., Hopcroft, J.E. and others, 2015. FE@ NIPS, pp. 196–212.
  54. Why does unsupervised pre-training help deep learning? [link]
    Erhan, D., Courville, A., Bengio, Y. and Vincent, P., 2010. Proceedings of the thirteenth international conference on artificial intelligence and statistics, pp. 201–208.
  55. Visualizing Representations: Deep Learning and Human Beings [link]
    Olah, C., 2015.
  56. SVCCA: Singular Vector Canonical Correlation Analysis for Deep Learning Dynamics and Interpretability [PDF]
    Raghu, M., Gilmer, J., Yosinski, J. and Sohl-Dickstein, J., 2017. Advances in Neural Information Processing Systems 30, pp. 6078–6087. Curran Associates, Inc.
  57. Superposition, Memorization, and Double Descent
    Henighan, T.A.C., 2023. Transformer Circuits Thread.
  58. Mechanistic anomaly detection and ELK [link]
    Christiano, P., 2022.
  59. Dropout can create a privileged basis in the ReLU output model [link]
    lsgos, 2023.
  60. More findings on Memorization and double descent [link]
    Hobbhahn, M., 2023.
  61. Disentangling by factorising
    Kim, H. and Mnih, A., 2018. International Conference on Machine Learning, pp. 2649–2658.
  62. Infogan: Interpretable representation learning by information maximizing generative adversarial nets
    Chen, X., Duan, Y., Houthooft, R., Schulman, J., Sutskever, I. and Abbeel, P., 2016. Advances in neural information processing systems, Vol 29.
  63. k-Sparse Autoencoders [link]
    Makhzani, A. and Frey, B.J., 2013. CoRR, Vol abs/1312.5663.
  64. Representation learning: A review and new perspectives
    Bengio, Y., Courville, A. and Vincent, P., 2013. IEEE transactions on pattern analysis and machine intelligence, Vol 35(8), pp. 1798–1828. IEEE.
  65. Toward transparent ai: A survey on interpreting the inner structures of deep neural networks
    Räuker, T., Ho, A., Casper, S. and Hadfield-Menell, D., 2023. 2023 IEEE Conference on Secure and Trustworthy Machine Learning (SaTML), pp. 464–483.
  66. Promises and pitfalls of black-box concept learning models
    Mahinpei, A., Clark, J., Lage, I., Doshi-Velez, F. and Pan, W., 2021. arXiv preprint arXiv:2106.13314.
  67. Local vs. Distributed Coding
    Thorpe, S.J., 1989. Intellectica, Vol 8, pp. 3–40.
  68. Scaling laws for neural language models
    Kaplan, J., McCandlish, S., Henighan, T., Brown, T.B., Chess, B., Child, R., Gray, S., Radford, A., Wu, J. and Amodei, D., 2020. arXiv preprint arXiv:2001.08361.
  69. Sparse-Coding Variational Auto-Encoders
    Barello, G., Charles, A.S. and Pillow, J.W., 2018. bioRxiv.
  70. On incorporating inductive biases into VAEs
    Miao, N., Mathieu, E., Siddharth, N., Teh, Y.W. and Rainforth, T., 2021. arXiv preprint arXiv:2106.13746.
  71. Beyond ℓ₁ sparse coding in V1
    Rentzeperis, I., Calatroni, L., Perrinet, L. and Prandi, D., 2023. arXiv preprint arXiv:2301.10002.
  72. Emergence of Sparse Representations from Noise
    Bricken, T., Schaeffer, R., Olshausen, B. and Kreiman, G., 2023.
  73. Adam: A method for stochastic optimization
    Kingma, D.P. and Ba, J., 2014. arXiv preprint arXiv:1412.6980.
  74. Delving deep into rectifiers: Surpassing human-level performance on imagenet classification
    He, K., Zhang, X., Ren, S. and Sun, J., 2015. Proceedings of the IEEE international conference on computer vision, pp. 1026–1034.
  75. The lottery ticket hypothesis: Finding sparse, trainable neural networks
    Frankle, J. and Carbin, M., 2018. arXiv preprint arXiv:1803.03635.