Committee

Here at MIT Technology Review we’ve been writing about the gene-editing technology CRISPR since 2013, calling it the biggest biotech breakthrough of the century. Yet so far, there’s been only one gene-editing drug approved. It’s been used commercially on only about 40 patients, all with sickle-cell disease. It’s becoming clear that the impact of CRISPR isn’t as big as we all hoped. In fact, there’s a pall of discouragement over the entire field—with some journalists saying the gene-editing revolution has “lost its mojo.” So what will it take for CRISPR to help more people? A new startup says the answer could be an “umbrella approach” to testing and commercializing treatments. Aurora Therapeutics, which has $16 million from Menlo Ventures and counts CRISPR co-inventor Jennifer Doudna as an advisor, essentially hopes to win approval for gene-editing drugs that can be slightly adjusted, or personalized, without requiring costly new trials or approvals for every new version. The need to change regulations around gene-editing treatments was endorsed in November by the head of the US Food and Drug Administration, Martin Makary, who said the agency would open a “new” regulatory pathway for “bespoke, personalized therapies” that can’t easily be tested in conventional ways.  Aurora’s first target, the rare inherited disease phenylketonuria, also known as PKU, is a case in point. People with PKU lack a working version of an enzyme needed to use up the amino acid phenylalanine, a component of pretty much all meat and protein. If the amino acid builds up, it causes brain damage. So patients usually go on an onerous “diet for life” of special formula drinks and vegetables. In theory, gene editing can fix PKU. In mice, scientists have already restored the gene for the enzyme by rewriting DNA in liver cells, which both make the enzyme and are some of the easiest to reach with a gene-editing drug. The problem is that in human patients, many different mutations can affect the critical gene. According to Cory Harding, a researcher at Oregon Health Sciences University, scientists know about 1,600 different DNA mutations that cause PKU. There’s no way anyone will develop 1,600 different gene-editing drugs. Instead, Aurora’s goal is to eventually win approval for a single gene editor that, with minor adjustments, could be used to correct several of the most common mutations, including one that’s responsible for about 10% of the estimated 20,000 PKU cases in the US. “We can’t have a separate clinical trial for each mutation,” says Edward Kaye, the CEO of Aurora. “The way the FDA approves gene editing has to change, and I think they’ve been very understanding that is the case.” A gene editor is a special protein that can zero in on a specific location in the genome and change it. To prepare one, Aurora will put genetic code for the editor into a nanoparticle along with a targeting molecule. In total, it will involve about 5,000 gene letters. But only 20 of them need to change in order to redirect the treatment to repair a different mutation. “Over 99% of the drug stays the same,” says Johnny Hu, a partner at Menlo Ventures, which put up the funding for the startup. The new company came together after Hu met over pizza with Fyodor Urnov, an outspoken gene-editing scientist at the University of California, Berkeley, who is Aurora’s cofounder and sits on its board. In 2022, Urnov had written a New York Times editorial bemoaning the “chasm” between what editing technology can do and the “legal, financial, and organizational” realities preventing researchers from curing people. “I went to Fyodor and said, ‘Hey, we’re getting all these great results in the clinic with CRISPR, but why hasn’t it scaled?” says Hu. Part of the reason is that most gene-editing companies are chasing the same few conditions, such as sickle-cell, where (as luck would have it) a single edit works for all patients. But that leaves around 400 million people who have 7,000 other inherited conditions without much hope to get their DNA fixed, Urnov estimated in his editorial. Then, last May, came the dramatic demonstration of the first fully “personalized” gene-editing treatment. A team in Philadelphia, assisted by Urnov and others, succeeded in correcting the DNA of a baby, named KJ Muldoon, who had an entirely unique mutation that caused a metabolic disease. Though it didn’t target PKU, the project showed that gene editing could theoretically fix some inherited diseases “on demand.”  It also underscored a big problem. Treating a single child required a large team and cost millions in time, effort, and materials—all to create a drug that would never be used again.  That’s exactly the sort of situation the new “umbrella” trials are supposed to address. Kiran Musunuru, who co-led the team at the University of Pennsylvania, says he’s been in discussions with the FDA to open a study of bespoke gene editors this year focusing on diseases of the type Baby KJ had, called urea cycle disorders. Each time a new patient appears, he says, they’ll try to quickly put together a variant of their gene-editing drug that’s tuned to fix that child’s particular genetic problem. Musunuru, who isn’t involved with Aurora, does not think the company’s plans for PKU count as fully personalized editors. “These corporate PKU efforts have nothing whatsoever to do with Baby KJ,” he says. He says his center continues to focus on mutations “so ultra-rare that we don’t see any scenario where a for-profit gene-editing company would find that indication to be commercially viable.” Instead, what’s occurring in PKU, says Musunuru, is that researchers have realized they can assemble “a bunch” of the most frequent mutations “into a large enough group of patients to make a platform PKU therapy commercially viable.”  While that would still leave out many patients with extra-rare gene errors, Musunuru says any gene-editing treatment at all would still be “a big improvement over the status quo, which  is zero genetic therapies for PKU.”

In this tutorial, we demonstrate how we use Ibis to build a portable, in-database feature engineering pipeline that looks and feels like Pandas but executes entirely inside the database. We show how we connect to DuckDB, register data safely inside the backend, and define complex transformations using window functions and aggregations without ever pulling raw data into local memory. By keeping all transformations lazy and backend-agnostic, we demonstrate how to write analytics code once in Python and rely on Ibis to translate it into efficient SQL. Check out the FULL CODES here. Copy CodeCopiedUse a different Browser !pip -q install “ibis-framework[duckdb,examples]” duckdb pyarrow pandas import ibis from ibis import _ print(“Ibis version:”, ibis.__version__) con = ibis.duckdb.connect() ibis.options.interactive = True We install the required libraries and initialize the Ibis environment. We establish a DuckDB connection and enable interactive execution so that all subsequent operations remain lazy and backend-driven. Check out the FULL CODES here. Copy CodeCopiedUse a different Browser try: base_expr = ibis.examples.penguins.fetch(backend=con) except TypeError: base_expr = ibis.examples.penguins.fetch() if “penguins” not in con.list_tables(): try: con.create_table(“penguins”, base_expr, overwrite=True) except Exception: con.create_table(“penguins”, base_expr.execute(), overwrite=True) t = con.table(“penguins”) print(t.schema()) We load the Penguins dataset and explicitly register it inside the DuckDB catalog to ensure it is available for SQL execution. We verify the table schema and confirm that the data now lives inside the database rather than in local memory. Check out the FULL CODES here. Copy CodeCopiedUse a different Browser def penguin_feature_pipeline(penguins): base = penguins.mutate( bill_ratio=_.bill_length_mm / _.bill_depth_mm, is_male=(_.sex == “male”).ifelse(1, 0), ) cleaned = base.filter( _.bill_length_mm.notnull() & _.bill_depth_mm.notnull() & _.body_mass_g.notnull() & _.flipper_length_mm.notnull() & _.species.notnull() & _.island.notnull() & _.year.notnull() ) w_species = ibis.window(group_by=[cleaned.species]) w_island_year = ibis.window( group_by=[cleaned.island], order_by=[cleaned.year], preceding=2, following=0, ) feat = cleaned.mutate( species_avg_mass=cleaned.body_mass_g.mean().over(w_species), species_std_mass=cleaned.body_mass_g.std().over(w_species), mass_z=( cleaned.body_mass_g – cleaned.body_mass_g.mean().over(w_species) ) / cleaned.body_mass_g.std().over(w_species), island_mass_rank=cleaned.body_mass_g.rank().over( ibis.window(group_by=[cleaned.island]) ), rolling_3yr_island_avg_mass=cleaned.body_mass_g.mean().over( w_island_year ), ) return feat.group_by([“species”, “island”, “year”]).agg( n=feat.count(), avg_mass=feat.body_mass_g.mean(), avg_flipper=feat.flipper_length_mm.mean(), avg_bill_ratio=feat.bill_ratio.mean(), avg_mass_z=feat.mass_z.mean(), avg_rolling_3yr_mass=feat.rolling_3yr_island_avg_mass.mean(), pct_male=feat.is_male.mean(), ).order_by([“species”, “island”, “year”]) We define a reusable feature engineering pipeline using pure Ibis expressions. We compute derived features, apply data cleaning, and use window functions and grouped aggregations to build advanced, database-native features while keeping the entire pipeline lazy. Check out the FULL CODES here. Copy CodeCopiedUse a different Browser features = penguin_feature_pipeline(t) print(con.compile(features)) try: df = features.to_pandas() except Exception: df = features.execute() display(df.head()) We invoke the feature pipeline and compile it into DuckDB SQL to validate that all transformations are pushed down to the database. We then run the pipeline and return only the final aggregated results for inspection. Check out the FULL CODES here. Copy CodeCopiedUse a different Browser con.create_table(“penguin_features”, features, overwrite=True) feat_tbl = con.table(“penguin_features”) try: preview = feat_tbl.limit(10).to_pandas() except Exception: preview = feat_tbl.limit(10).execute() display(preview) out_path = “/content/penguin_features.parquet” con.raw_sql(f”COPY penguin_features TO ‘{out_path}’ (FORMAT PARQUET);”) print(out_path) We materialize the engineered features as a table directly inside DuckDB and query it lazily for verification. We also export the results to a Parquet file, demonstrating how we can hand off database-computed features to downstream analytics or machine learning workflows. In conclusion, we constructed, compiled, and executed an advanced feature engineering workflow fully inside DuckDB using Ibis. We demonstrated how to inspect the generated SQL, materialized results directly in the database, and exported them for downstream use while preserving portability across analytical backends. This approach reinforces the core idea behind Ibis: we keep computation close to the data, minimize unnecessary data movement, and maintain a single, reusable Python codebase that scales from local experimentation to production databases. Check out the FULL CODES here. Also, feel free to follow us on Twitter and don’t forget to join our 100k+ ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Check out our latest release of ai2025.dev, a 2025-focused analytics platform that turns model launches, benchmarks, and ecosystem activity into a structured dataset you can filter, compare, and export. The post How to Build Portable, In-Database Feature Engineering Pipelines with Ibis Using Lazy Python APIs and DuckDB Execution appeared first on MarkTechPost.

arXiv:2511.06346v2 Announce Type: replace-cross Abstract: Large Language Models (LLMs) perform well on standard reasoning and question-answering benchmarks, yet such evaluations often fail to capture their ability to handle long-tail, expertise-intensive knowledge in real-world professional scenarios. We introduce LPFQA, a long-tail knowledge benchmark derived from authentic professional forum discussions, covering 7 academic and industrial domains with 430 curated tasks grounded in practical expertise. LPFQA evaluates specialized reasoning, domain-specific terminology understanding, and contextual interpretation, and adopts a hierarchical difficulty structure to ensure semantic clarity and uniquely identifiable answers. Experiments on over multiple mainstream LLMs reveal substantial performance gaps, particularly on tasks requiring deep domain reasoning, exposing limitations overlooked by existing benchmarks. Overall, LPFQA provides an authentic and discriminative evaluation framework that complements prior benchmarks and informs future LLM development.

arXiv:2601.04742v1 Announce Type: new Abstract: Large Language Models (LLMs) suffer from hallucinations and factual inaccuracies, especially in complex reasoning and fact verification tasks. Multi-Agent Debate (MAD) systems aim to improve answer accuracy by enabling multiple LLM agents to engage in dialogue, promoting diverse reasoning and mutual verification. However, existing MAD frameworks primarily rely on internal knowledge or static documents, making them vulnerable to hallucinations. While MADKE introduces external evidence to mitigate this, its one-time retrieval mechanism limits adaptability to new arguments or emerging information during the debate. To address these limitations, We propose Tool-MAD, a multi-agent debate framework that enhances factual verification by assigning each agent a distinct external tool, such as a search API or RAG module. Tool-MAD introduces three key innovations: (1) a multi-agent debate framework where agents leverage heterogeneous external tools, encouraging diverse perspectives, (2) an adaptive query formulation mechanism that iteratively refines evidence retrieval based on the flow of the debate, and (3) the integration of Faithfulness and Answer Relevance scores into the final decision process, allowing the Judge agent to quantitatively assess the coherence and question alignment of each response and effectively detect hallucinations. Experimental results on four fact verification benchmarks demonstrate that Tool-MAD consistently outperforms state-of-the-art MAD frameworks, achieving up to 5.5% accuracy improvement. Furthermore, in medically specialized domains, Tool-MAD exhibits strong robustness and adaptability across various tool configurations and domain conditions, confirming its potential for broader real-world fact-checking applications.

arXiv:2601.04638v1 Announce Type: new Abstract: Medical consultations are intrinsically speech-centric. However, most prior works focus on long-text-based interactions, which are cumbersome and patient-unfriendly. Recent advances in speech language models (SpeechLMs) have enabled more natural speech-based interaction, yet the scarcity of medical speech data and the inefficiency of directly fine-tuning on speech data jointly hinder the adoption of SpeechLMs in medical consultation. In this paper, we propose SpeechMedAssist, a SpeechLM natively capable of conducting speech-based multi-turn interactions with patients. By exploiting the architectural properties of SpeechLMs, we decouple the conventional one-stage training into a two-stage paradigm consisting of (1) Knowledge & Capability Injection via Text and (2) Modality Re-alignment with Limited Speech Data, thereby reducing the requirement for medical speech data to only 10k synthesized samples. To evaluate SpeechLMs for medical consultation scenarios, we design a benchmark comprising both single-turn question answering and multi-turn simulated interactions. Experimental results show that our model outperforms all baselines in both effectiveness and robustness in most evaluation settings.

arXiv:2601.04411v1 Announce Type: cross Abstract: Reinforcement learning with verifiable rewards (RLVR) is a simple but powerful paradigm for training LLMs: sample a completion, verify it, and update. In practice, however, the verifier is almost never clean–unit tests probe only limited corner cases; human and synthetic labels are imperfect; and LLM judges (e.g., RLAIF) are noisy and can be exploited–and this problem worsens on harder domains (especially coding) where tests are sparse and increasingly model-generated. We ask a pragmatic question: does the verification noise merely slow down the learning (rate), or can it flip the outcome (fate)? To address this, we develop an analytically tractable multi-armed bandit view of RLVR dynamics, instantiated with GRPO and validated in controlled experiments. Modeling false positives and false negatives and grouping completions into recurring reasoning modes yields a replicator-style (natural-selection) flow on the probability simplex. The dynamics decouples into within-correct-mode competition and a one-dimensional evolution for the mass on incorrect modes, whose drift is determined solely by Youden’s index J=TPR-FPR. This yields a sharp phase transition: when J>0, the incorrect mass is driven toward extinction (learning); when J=0, the process is neutral; and when J0, noise primarily rescales convergence time (“rate, not fate”). Experiments on verifiable programming tasks under synthetic noise reproduce the predicted J=0 boundary. Beyond noise, the framework offers a general lens for analyzing RLVR stability, convergence, and algorithmic interventions.

arXiv:2512.21002v2 Announce Type: replace Abstract: Distilling the capabilities from a large reasoning model (LRM) to a smaller student model often involves training on substantial amounts of reasoning data. However, knowledge distillation (KD) over lengthy sequences with prompt (P), chain-of-thought (CoT), and answer (A) sections makes the process computationally expensive. In this work, we investigate how the allocation of supervision across different sections (P, CoT, A) affects student performance. Our analysis shows that selective KD over only the CoT tokens can be effective when the prompt and answer information is encompassed by it. Building on this insight, we establish a truncation protocol to quantify computation-quality tradeoffs as a function of sequence length. We observe that beyond a specific length, longer training sequences provide marginal returns for downstream performance but require substantially higher memory and FLOPs. To this end, training on only the first $50%$ of tokens of every training sequence can retain, on average, $approx91%$ of full-sequence performance on math benchmarks while reducing training time, memory usage, and FLOPs by about $50%$ each. Codes are available at https://github.com/weiruichen01/distilling-the-essence.