Papers
Topics
Authors
Recent
Search
2000 character limit reached

EMO: Pretraining Mixture of Experts for Emergent Modularity

Published 7 May 2026 in cs.CL | (2605.06663v1)

Abstract: LLMs are typically deployed as monolithic systems, requiring the full model even when applications need only a narrow subset of capabilities, e.g., code, math, or domain-specific knowledge. Mixture-of-Experts (MoEs) seemingly offer a potential alternative by activating only a subset of experts per input, but in practice, restricting inference to a subset of experts for a given domain leads to severe performance degradation. This limits their practicality in memory-constrained settings, especially as models grow larger and sparser. We introduce EMO, an MoE designed for modularity-the independent use and composition of expert subsets-without requiring human-defined priors. Our key idea is to encourage tokens from similar domains to rely on similar experts. Since tokens within a document often share a domain, EMO restricts them to select experts from a shared pool, while allowing different documents to use different pools. This simple constraint enables coherent expert groupings to emerge during pretraining using document boundaries alone. We pretrain a 1B-active, 14B-total EMO on 1T tokens. As a full model, it matches standard MoE performance. Crucially, it enables selective expert use: retaining only 25% (12.5%) of experts incurs just a 1% (3%) absolute drop, whereas standard MoEs break under the same setting. We further find that expert subsets in EMO specialize at semantic levels (e.g., domains such as math or code), in contrast to the low-level syntactic specialization observed in standard MoEs. Altogether, our results demonstrate a path toward modular, memory-efficient deployment of large, sparse models and open new opportunities for composable architectures.

Authors (3)

Summary

  • The paper introduces a pretraining regime (EMO) that enforces document-level expert selection to induce emergent semantic modularity.
  • The methodology groups tokens by document to allow experts to specialize in semantic areas such as math, code, and technical domains.
  • Empirical results demonstrate minimal performance loss under expert pruning, enabling efficient, composable inference in large Mixture-of-Experts.

Emergent Modularity in Pretraining Mixture-of-Experts with EMO

Motivation and Problem Statement

Pretrained LLMs have advanced using large-scale dense architectures, resulting in monolithic computation and deployment. Recent scaling trends have popularized Mixture-of-Experts (MoE) architectures, where only a learned subset of experts is activated per input. These models in principle offer modularity and efficiency for domain-specific inference. However, typical MoEs do not natively support meaningful modularity: activating only a relevant subset of experts for a specific domain leads to severe performance collapse due to the lack of coherent specialization among experts. As models grow increasingly sparse and large, the inability to support selective inference limits their practical deployment, especially in memory- or latency-constrained scenarios.

EMO Architecture and Methodology

EMO introduces a pretraining regime for MoEs that explicitly encourages emergent modularity without hand-crafted domain labels or human priors. The method leverages a simple yet effective constraint: all tokens within the same document are restricted to selecting experts from a shared pool; this pool varies across documents. Since documents naturally aggregate semantically related content, this constraint provides a weak, unsupervised signal that steers expert assignment toward high-level semantic grouping. During pretraining, EMO relies solely on document boundaries to enforce this expert pool restriction.

EMO scales to a 14B total parameter configuration with a 1B active parameter MoE, trained on 1T tokens. Modular grouping emerges implicitly: experts specialize at the semantic level (e.g., math, code, technical domains), a property not observed in standard MoEs, which generally specialize on low-level syntactic features.

Empirical Results

EMO exhibits several key empirical advantages over standard MoEs:

  • Modular Retention: When activating only 25% (12.5%) of the expert pool, EMO experiences a negligible 1% (3%) absolute drop in performance, preserving utility. Standard MoEs exhibit catastrophic degradation in equivalent settings.
  • Domain Specialization: Experts in EMO self-organize to semantic groupings (e.g., math, code), supporting the selection and composition of functionalities. This is in contrast to standard MoEs, where expert specialization remains shallow.
  • Full Model Parity: With all experts active, EMO attains parity with standard MoEs on conventional benchmarks.

These results validate EMO’s approach to achieving true modularity and composability in LLMs without manual architecture design or supervision.

Theoretical and Practical Implications

The findings demonstrate that weak, document-level grouping constraints are sufficient for emergent high-level specialization in large MoEs. This suggests that domain-specialized computation and modular deployment can be induced naturally during unsupervised pretraining, not requiring explicit annotation. For practical deployment, EMO enables sub-expert selection: only relevant experts can be loaded for inference, offering substantial memory and computational savings. The semantic modularity also opens the possibility for composable inference: different expert pools can be dynamically assembled and reused for downstream tasks.

Future Directions

The results invite further research in several directions:

  • Granular Modular Control: Extending document-level grouping to finer- or coarser-grained controls (e.g., sections, topics, or user-defined domains)
  • Fully Composable Architectures: Using EMO as a foundation to explore plug-and-play architectures, enabling the dynamic combination of expert capabilities at inference time
  • Transfer and Continual Learning: Investigating how modular experts adapt or are reused across sequential or continual learning setups
  • Cross-modal Extension: Generalizing modular MoE principles to multi-modal architectures

Conclusion

EMO presents a pretraining method for MoEs that achieves semantically meaningful emergent modularity without supervision or domain priors. The architecture supports robust, modular inference with minimal performance degradation under expert pruning, outperforming standard MoEs in selective expert usage scenarios. These properties make EMO a compelling direction for scalable and efficient large model inference, composability, and memory/resource-constrained deployment. The emergent grouping behavior highlights new avenues for modular and adaptive neural architectures in NLP and beyond.

Whiteboard

There was an error generating the whiteboard.

Explain it Like I'm 14

Overview: What this paper is about

This paper introduces a new kind of LLM called Emo. It’s built using a “Mixture of Experts” (MoE) design, which is like having many small specialist models (“experts”) inside one big model. The main goal is to make the model more modular, meaning you can use only the parts you need—like just the “math experts” or just the “code experts”—without the whole model, and still get good performance.

Key questions the paper asks

  • Can we train a big model so that its parts naturally organize by topic (like math, code, or general language) without humans labeling the data?
  • If we only use the relevant parts for a given task, can we keep most of the quality while using much less memory and compute?
  • Do these parts (experts) learn meaningful, high-level skills instead of just low-level patterns?

How it works (in simple terms)

Think of the model as a school:

  • Each “expert” is like a teacher who specializes in something (math, coding, etc.).
  • When the model reads text, a “gating” system decides which teachers to consult for each piece of text.
  • Normally, MoE models pick different teachers for every tiny piece (token) of text. That can make it hard to run only a small group of teachers later without losing a lot of quality.

Emo’s key idea is simple: keep related words in the same document using the same small group of teachers.

  • A “token” is just a chunk of text (like part of a word).
  • A “document” is a single piece of text that’s usually about one topic (like a news article, a math problem, or a coding snippet).
  • Emo tells all the tokens in the same document to pick experts from the same shared pool. Different documents can pick different pools.
  • No human tells the model which document is “math” or “code.” The model figures out the groupings on its own during training, just by using document boundaries.

Why this helps:

  • Documents usually stick to one topic. By having the same experts handle a whole document, those experts get really good at that topic.
  • Over time, experts form natural groups around real topics (like math or coding), not just surface patterns (like punctuation or spacing).

Training scale (in brief):

  • The team trained Emo on a huge amount of text (about 1 trillion tokens).
  • The whole model has about 14 billion parameters, but only about 1 billion are used at a time (“active”), which is the MoE efficiency trick.

Main findings and why they matter

Here are the core results, explained simply:

  • As a full model, Emo performs as well as standard MoE models.
  • Emo stays strong even when you only use a small fraction of its experts:
    • Using just 25% of the experts causes only about a 1% drop in performance.
    • Using just 12.5% of the experts causes only about a 3% drop.
    • In contrast, standard MoE models fail badly under the same conditions.
  • Emo’s experts learn meaningful topics (like math or code). Standard MoE experts often focus on low-level patterns (like punctuation), which is less useful for modular use.
  • This means Emo can be deployed in a memory-efficient way: you can load only the experts you need for a task, which saves memory and computing power.

Why this is important

Emo shows a path to building large AI models that are:

  • Modular: You can mix and match parts depending on the task (e.g., run “math experts” for math homework, “code experts” for programming help).
  • Efficient: You don’t need to load the entire model to get good results, which is helpful for phones, laptops, or servers with limited memory.
  • Composable: In the future, we could assemble custom sets of experts for different applications, making AI more flexible and easier to deploy.

In short, Emo helps big AI models behave more like a team of specialists that can be called in only when needed—saving resources while keeping quality high.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

Below is a concise list of concrete gaps and open questions that remain unresolved based on the paper’s stated approach and results.

  • Mixed-domain inputs: How does a document-level shared expert pool handle inputs that mix domains within a single sample (e.g., code embedded in natural language) or rapidly shift domains across turns in chat-style interactions?
  • Short prompts and sentences: Does the document-boundary constraint degrade routing for short or single-sentence prompts where “document” context is limited or absent?
  • Pool granularity: What is the optimal granularity for constraining shared expert pools (document vs. section/paragraph vs. window), and how sensitive are results to this choice?
  • Pool size and overlap: How do the size of the shared pool, degree of overlap between pools, and number of experts-per-token affect accuracy, specialization, and stability?
  • Robustness to noisy boundaries: Many web-scale corpora have ill-defined or noisy document boundaries—how robust is the method to mis-segmentation or weakly defined documents?
  • Multi-domain composition: How should two or more expert pools be composed when a single input requires multiple domains; does naive union cause interference or routing instability?
  • Expert selection at deployment: What practical procedures reliably select the minimal expert subset for a new application or task without running the full model first?
  • Routing with missing experts: How is token routing handled when some experts are pruned for memory-constrained deployment (e.g., do routers get retrained, is there graceful fallback, what is the performance/latency impact)?
  • Router dependence and size: To what extent does Emo’s modular deployment require retaining router parameters in memory, and how large are they relative to expert subsets?
  • Stability across seeds: Are emergent semantic specializations consistent across random seeds, training runs, and data permutations, or are they brittle?
  • Interpretability and validation: Beyond qualitative observations, what quantitative, reproducible metrics establish that expert pools capture semantic (not merely syntactic) specialization?
  • Scaling behavior: Do the observed modularity and subset performance hold for substantially larger/sparser MoEs or for different active-to-total parameter ratios?
  • Task coverage and generality: Are the reported subset-retention results consistent across diverse benchmarks (e.g., reasoning, long-context, code, math, factual QA, safety), or are gains concentrated in specific task families?
  • Non-English and multilingual settings: Does document-level specialization translate to multilingual corpora where domains, scripts, and code-switching coexist?
  • Continual learning and fine-tuning: How do expert pools evolve under domain-specific fine-tuning, instruction tuning, or RLHF, and do subsets remain stable and reusable afterward?
  • Catastrophic interference: Does constraining tokens to shared pools increase intra-pool interference, causing degradation for minority tasks within a domain?
  • Load balancing and expert collapse: Does the shared-pool constraint exacerbate expert underutilization or overconcentration, and how effective are balancing losses under this regime?
  • Data distribution sensitivity: How sensitive is emergent modularity to the composition and domain balance of the pretraining corpus (e.g., heavy code/math skew vs. general web text)?
  • Theoretical underpinnings: Under what conditions (data distributions, gating dynamics, regularization) should document-level constraints lead to semantic modularity rather than low-level specialization?
  • Latency and throughput: Beyond memory savings, what are the real-world latency/throughput effects of subset deployment, including kernel launch overheads and routing costs?
  • Security and privacy: Can expert-usage patterns leak sensitive information (fingerprinting tasks, domains, or users), and how can this be mitigated in modular deployments?
  • Bias localization: Do domain-specific biases or toxic behaviors concentrate within certain experts/pools, and what auditing/mitigation strategies are needed for modular models?
  • Comparison to alternative modularity methods: How does Emo compare, in compute and quality, to adapters, prompt-tuning, product-key memories, or other sparse modular architectures?
  • Automatic pool discovery: Can the model or a post-hoc tool automatically discover and label expert pools that best serve a new domain or dataset without extensive evaluation?
  • Hierarchical or dynamic pooling: Would hierarchical pools (document→section→token) or adaptive pool resizing during training/inference provide better trade-offs?
  • Robustness to adversarial triggers: Are routing and pool assignments stable under adversarially crafted inputs that mimic domain cues to force suboptimal experts?
  • Fault tolerance: How does performance degrade when individual experts fail or are intentionally removed; can redundancy be introduced to preserve reliability?
  • Transfer to encoder–decoder or multimodal models: Do the benefits of document-level constrained MoEs extend beyond decoder-only LLMs to other architectures and modalities?
  • Training cost–benefit analysis: What is the additional training cost of enforcing document-level constraints relative to the memory/accuracy benefits at deployment time?
  • Pruning and compression interplay: How do expert-pruning, quantization, or low-rank adaptations interact with Emo’s pool specialization and routing behavior?

Practical Applications

Practical Applications of Emo: Pretraining Mixture of Experts for Emergent Modularity

Below, we summarize actionable, real-world applications that follow from the paper’s findings and method (document-level shared expert pools leading to semantic expert specialization and selective expert use with minimal performance loss). We group them into immediate and long-term opportunities, and indicate sectors, potential tools/products, and key assumptions/dependencies.

Immediate Applications

Industry

  • Cost- and memory-efficient domain-specific serving (software, finance, legal, customer support)
    • Deploy only the relevant expert subset (e.g., code, math, finance) to cut inference memory and cost while maintaining quality (as shown: 25% experts ≈ ~1% absolute drop; 12.5% ≈ ~3%).
    • Tools/products/workflows: expert-subset serving endpoints; “expert packager” to export/load subsets; Hugging Face + MoE runtimes (e.g., Tutel, DeepSpeed-MoE, Megablocks).
    • Assumptions/dependencies: robust domain routing or upfront domain labeling; Emo weights and router available; compatible inference kernels; shared layers still fit device memory.
  • Edge and on-prem deployments with strict footprints (healthcare, finance, manufacturing, retail)
    • Run targeted experts on laptops, private clusters, kiosks, or edge devices where security and latency matter.
    • Tools/products/workflows: quantized expert subsets; Triton/FasterTransformer kernels; on-prem MoE gateway.
    • Assumptions/dependencies: quantization support for experts; device memory constraints; local PII governance.
  • Per-tenant “expert packs” for SaaS multi-tenancy (enterprise software)
    • Isolate tenant/domain capabilities by shipping tenant-specific expert bundles to reduce cross-tenant data exposure and costs.
    • Tools/products/workflows: tenant-aware model registry; expert lifecycle manager; policy engine to permit/deny experts.
    • Assumptions/dependencies: tenancy isolation at runtime; access control on expert loading; audit logging.
  • Faster and safer fine-tuning via expert-local adaptation (enterprise knowledge bases, vertical AI)
    • Fine-tune only relevant experts to incorporate proprietary knowledge, reducing training time and catastrophic forgetting risk.
    • Tools/products/workflows: expert-scoped LoRA/adapters; differential updates to expert packs; CI/CD for experts.
    • Assumptions/dependencies: stable expert-domain mapping; router robustness post-fine-tuning; evaluation guardrails.
  • Capability throttling and safety-by-omission (security, education tech)
    • Disable high-risk experts (e.g., shell/code execution, harmful content) for compliance or exam settings.
    • Tools/products/workflows: capability flags mapped to experts; policy-based expert gating.
    • Assumptions/dependencies: reliable alignment between experts and capabilities; tests to detect routing bypass; transparent documentation.
  • Expert-level A/B tests and canaries (MLOps)
    • Roll out/roll back new expert versions independently; measure impact by domain.
    • Tools/products/workflows: expert versioning; traffic splitting at domain/router level; observability dashboards.
    • Assumptions/dependencies: router stability across expert versions; telemetry linking outputs to expert usage.
  • Elastic autoscaling by domain mix (cloud infrastructure)
    • Dynamically load/unload expert subsets to match workload domain distributions, reducing GPU memory pressure.
    • Tools/products/workflows: autoscaler aware of expert pools; hot-swapping experts; cache/prefetch by demand.
    • Assumptions/dependencies: fast expert load times; container/orchestrator integration; workload predictability.

Academia

  • Mechanistic interpretability of semantic experts
    • Analyze emergent domain-level specialization vs syntactic specialization in standard MoEs; use the visualization tooling.
    • Tools/products/workflows: probing, neuron/attention attribution per expert; expert-activation datasets; open Emo checkpoints.
    • Assumptions/dependencies: instrumentation hooks; consistent domain labels; replicable routing behavior.
  • Benchmarking modularity and composability
    • Establish standardized evaluations for expert reusability, pruning tolerance, and compositional generalization.
    • Tools/products/workflows: modularity benchmarks; expert-pruning suites; compositional tasks.
    • Assumptions/dependencies: shared corpora with domain boundaries; common metrics; community adoption.

Policy

  • Lower-carbon public-sector AI via selective expert loading
    • Reduce energy/emissions by running only needed experts in government or NGO deployments.
    • Tools/products/workflows: emissions dashboards tied to expert usage; procurement guidelines favoring modularity.
    • Assumptions/dependencies: accepted measurement standards; cost–benefit analyses; lifecycle reporting.
  • Capability-scoped models for compliance
    • Distribute models with restricted expert sets to comply with sectoral regulations (e.g., no code-gen in testing environments; privacy-sensitive domains).
    • Tools/products/workflows: compliance audits mapping experts to regulated capabilities; signed manifests of included experts.
    • Assumptions/dependencies: legal recognition of capability scoping; tamper-evident packaging; enforcement mechanisms.

Daily Life

  • On-device “domain packs” for assistants (education, coding, travel)
    • Ship math-only tutors, coding-only IDE copilots, or travel translation packs with small footprints and offline support.
    • Tools/products/workflows: app store–like expert pack downloads; local expert manager; usage-aware caching.
    • Assumptions/dependencies: mobile inference optimizations; battery/performance trade-offs; storage constraints.
  • Privacy-preserving offline features
    • Run sensitive tasks (e.g., budgeting math, journaling) with relevant experts only, keeping data off the cloud.
    • Tools/products/workflows: local routing; encrypted expert storage; offline mode toggles.
    • Assumptions/dependencies: robust on-device security; user consent flows; safe update channels.

Long-Term Applications

Industry

  • Expert marketplace and plug-in ecosystem (software, education, vertical AI)
    • Third parties publish vetted expert packs (e.g., tax law, biotech), composable at inference time.
    • Tools/products/workflows: standardized expert APIs; signing/attestation; revenue sharing; safety certification.
    • Assumptions/dependencies: interoperability standards; secure sandboxing; IP/licensing models.
  • Cross-organization expert sharing without full model exposure (supply chain, partnerships)
    • Partners exchange domain experts while protecting core model IP and data.
    • Tools/products/workflows: encrypted expert distribution; usage metering; policy-compliant routing gateways.
    • Assumptions/dependencies: legal frameworks; confidential computing; provenance tracking.
  • Continual learning via expert addition and retirement
    • Add new experts for emerging domains without retraining the full model; deprecate stale ones.
    • Tools/products/workflows: expert lifecycle orchestration; router rebalancing tools; drift detection by domain.
    • Assumptions/dependencies: stability of gating under distribution shift; scalable pretraining for new experts.
  • Composable multimodal experts (vision, audio, robotics)
    • Integrate modality-specific experts (e.g., OCR, speech, control) with language experts for complex tasks.
    • Tools/products/workflows: multimodal routers; shared embeddings across modalities; real-time scheduling.
    • Assumptions/dependencies: multimodal pretraining; latency-optimized kernels; synchronization across expert types.
  • Agentic systems with step-wise expert selection
    • Controllers pick experts per subtask (plan, code, verify, retrieve), improving reliability and cost.
    • Tools/products/workflows: task graph planners; expert credit assignment; failure recovery policies.
    • Assumptions/dependencies: robust task decomposition; monitoring to prevent expert overreach; strong eval suites.
  • Structural safety and monitoring
    • Monitor, constrain, and audit behavior at expert granularity for high-stakes domains.
    • Tools/products/workflows: per-expert safety evaluations; sandboxed execution; incident response tied to expert IDs.
    • Assumptions/dependencies: comprehensive red teaming; formal capability mapping; regulatory buy-in.

Academia

  • Training curricula that induce modularity
    • Explore curriculum/data organization (e.g., document/domain boundaries) to scale emergent modularity and generalization.
    • Tools/products/workflows: synthetic domain curricula; scaling-law studies; ablations on routing constraints.
    • Assumptions/dependencies: access to large corpora; controlled pretraining budgets; community benchmarks.
  • Theory and verification of modular LLMs
    • Formalize when and why semantic experts emerge; verify routing correctness for safety-critical use.
    • Tools/products/workflows: theoretical frameworks; conformance tests; certified routers.
    • Assumptions/dependencies: tractable abstractions; collaboration between theory and systems communities.
  • Modular educational LMs
    • Instructor-configurable expert sets tailored to syllabus or grade level.
    • Tools/products/workflows: educator dashboards to select experts; content-aligned evaluation.
    • Assumptions/dependencies: curated expert libraries; alignment to standards; classroom validation.

Policy

  • Procurement and certification standards for modular AI
    • Require capability scoping, expert-level audit trails, and energy reporting in public tenders.
    • Tools/products/workflows: certification programs; standardized manifests and SBOMs for experts.
    • Assumptions/dependencies: multi-stakeholder consensus; conformance testing labs.
  • Export controls via expert gating
    • Ship reduced-capability models internationally by excluding sensitive experts.
    • Tools/products/workflows: compliant packaging; tamper-resistant gating; post-deployment verification.
    • Assumptions/dependencies: enforceability; anti-circumvention measures; international agreements.
  • Digital sovereignty with local expert hosting
    • Host only needed experts within national or institutional boundaries to meet data residency laws.
    • Tools/products/workflows: regional expert registries; sovereign routing infrastructure.
    • Assumptions/dependencies: local compute capacity; secure distribution channels.

Daily Life

  • Personalized expert portfolios
    • Users compose assistants from expert sets aligned to their profession/hobbies (e.g., photography, gardening, tax help).
    • Tools/products/workflows: preference-driven expert recommendations; privacy-preserving personalization.
    • Assumptions/dependencies: intuitive UI/UX; on-device storage; consent and transparency.
  • Household and field robotics with task experts
    • Robots combine perception, planning, and instruction-following experts for reliable operation in homes or farms.
    • Tools/products/workflows: low-latency MoE runtimes; safety interlocks; continual adaptation experts.
    • Assumptions/dependencies: real-time inference budgets; robust multimodal integration; safety certification.

Notes on feasibility across applications:

  • The Emo approach relies on document-level expert-pool constraints during pretraining to induce semantic specialization; benefits assume similar domain coherence at inference.
  • Memory/cost reductions depend on how much of the model is in expert layers vs shared layers; savings vary by architecture and runtime support.
  • Stable and interpretable routing is critical for safety, compliance, and maintainability; evaluation and monitoring tooling will be essential for production use.

Glossary

  • absolute drop: An absolute change in a metric measured in percentage points rather than a relative percentage. "absolute drop"
  • composable architectures: Model designs whose components can be combined or recombined to build larger systems. "composable architectures"
  • document boundaries: Delimiters between documents used to constrain training dynamics or routing. "document boundaries alone."
  • domain-specific knowledge: Knowledge targeted to a particular application area (e.g., code, math, or specialized domains). "domain-specific knowledge."
  • Emergent Modularity: Modular organization that arises naturally during training without being explicitly hard-coded. "Emergent Modularity"
  • expert groupings: Clusters of experts that emerge to handle related inputs or domains. "coherent expert groupings"
  • expert subsets: Selected sets of experts used together for a task, domain, or input. "expert subsets"
  • experts: Distinct sub-networks in a Mixture-of-Experts model that process inputs selectively. "experts"
  • human-defined priors: Manually specified assumptions or structure provided before learning. "human-defined priors."
  • inference: The process of running a trained model to produce outputs for given inputs. "restricting inference"
  • memory-constrained settings: Environments where limited memory restricts model size or active computation. "memory-constrained settings"
  • Mixture-of-Experts (MoEs): Neural architectures that contain many experts and activate only a subset per input. "Mixture-of-Experts (MoEs)"
  • monolithic systems: Single large models deployed as a whole, regardless of the specific capability needed. "monolithic systems"
  • pretraining: Large-scale initial training on broad data before downstream use or fine-tuning. "during pretraining"
  • selective expert use: Running only chosen experts at evaluation time to save computation or memory. "selective expert use:"
  • semantic levels: Levels of representation focused on meaning or domain content rather than surface form. "semantic levels"
  • shared pool: A constrained set of experts from which tokens are allowed to select. "shared pool,"
  • sparse models: Models where only part of the parameters are active for a given input, reducing compute. "sparse models"
  • syntactic specialization: Specialization that focuses on surface-form or structural patterns rather than meaning. "syntactic specialization"
  • tokens: Discrete units (often subword segments) that models process as inputs. "tokens"

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Collections

Sign up for free to add this paper to one or more collections.

Tweets

Sign up for free to view the 19 tweets with 864 likes about this paper.