Quantization Robustness to Input Degradations for Object Detection
Paper
β’
2508.19600
β’
Published
AI & ML interests
None defined yet.
Recent Activity
View all activity
AllanK24Β
authored
a
paper
7 days ago
Post
318
Over 40 percent of AI-generated code contains security vulnerabilities. We recently worked on a LoRA to write secure code by default using automated Semgrep analysis and GRPO, achieving 97 percent reduction in vulnerabilities without requiring security-specific prompts.
Technical Approach:
Automated security training pipeline combining Semgrep vulnerability detection with preference learning. Generate multiple solutions with varying security awareness, automatically analyze for vulnerabilities, create preference pairs based on security scores, train using GRPO with multi-factor scoring.
Scoring System (100 points total):
- Functionality: 40 points - Does the code work correctly
- Security patterns: 40 points - Uses secure coding practices
- Low vulnerabilities: 20 points - Semgrep score below threshold
This balanced scoring prevents reward hacking where models generate empty functions to avoid vulnerabilities.
Real Transformation Examples:
Database query before:
query = f"SELECT * FROM products WHERE name = '{name}'"
Database query after:
query = "SELECT * FROM products WHERE name = ?"
db.execute(query, (name,))
Password hashing before:
password_hash = hashlib.md5(password).hexdigest()
Password hashing after:
salt = bcrypt.gensalt(rounds=12)
password_hash = bcrypt.hashpw(password.encode('utf-8'), salt)
Model: codelion/Qwen2.5-Coder-0.5B-Instruct-security-grpo-lora
Notebook: https://github.com/codelion/ellora/blob/main/Ellora_Recipe_5_Secure_Code_Generation_LoRA.ipynb
Repository: https://github.com/codelion/ellora
Technical Approach:
Automated security training pipeline combining Semgrep vulnerability detection with preference learning. Generate multiple solutions with varying security awareness, automatically analyze for vulnerabilities, create preference pairs based on security scores, train using GRPO with multi-factor scoring.
Scoring System (100 points total):
- Functionality: 40 points - Does the code work correctly
- Security patterns: 40 points - Uses secure coding practices
- Low vulnerabilities: 20 points - Semgrep score below threshold
This balanced scoring prevents reward hacking where models generate empty functions to avoid vulnerabilities.
Real Transformation Examples:
Database query before:
query = f"SELECT * FROM products WHERE name = '{name}'"
Database query after:
query = "SELECT * FROM products WHERE name = ?"
db.execute(query, (name,))
Password hashing before:
password_hash = hashlib.md5(password).hexdigest()
Password hashing after:
salt = bcrypt.gensalt(rounds=12)
password_hash = bcrypt.hashpw(password.encode('utf-8'), salt)
Model: codelion/Qwen2.5-Coder-0.5B-Instruct-security-grpo-lora
Notebook: https://github.com/codelion/ellora/blob/main/Ellora_Recipe_5_Secure_Code_Generation_LoRA.ipynb
Repository: https://github.com/codelion/ellora
Post
6060
I recently worked on a LoRA that improves tool use in LLM. Thought the approach might interest folks here.
The issue I have had when trying to use some of the local LLMs with coding agents is this:
Me: "Find all API endpoints with authentication in this codebase"
LLM: "You should look for @app .route decorators and check if they have auth middleware..."
But I often want it to search the files and show me but the LLM doesn't trigger a tool use call.
To fine-tune it for tool use I combined two data sources:
1. Magpie scenarios - 5000+ diverse tasks (bug hunting, refactoring, security audits)
2. Real execution - Ran these on actual repos (FastAPI, Django, React) to get authentic tool responses
This ensures the model learns both breadth (many scenarios) and depth (real tool behavior).
Tools We Taught:
-
-
-
-
-
-
Improvements:
- Tool calling accuracy: 12% β 80%
- Correct parameters: 8% β 87%
- Multi-step tasks: 3% β 78%
- End-to-end completion: 5% β 80%
- Tools per task: 0.2 β 3.8
The LoRA really improves on intential tool call as an example consider the query: "Find ValueError in payment module"
The response proceeds as follows:
1. Calls
2. Gets 4 matches across 3 files
3. Calls
4. Analyzes context
5. Reports: "Found 3 ValueError instances: payment/processor.py:47 for invalid amount, payment/validator.py:23 for unsupported currency..."
Resources:
- Colab notebook https://colab.research.google.com/github/codelion/ellora/blob/main/Ellora_Recipe_3_Enhanced_Tool_Calling_and_Code_Understanding.ipynb
- Model - codelion/Llama-3.2-1B-Instruct-tool-calling-lora
- GitHub - https://github.com/codelion/ellora
The issue I have had when trying to use some of the local LLMs with coding agents is this:
Me: "Find all API endpoints with authentication in this codebase"
LLM: "You should look for @app .route decorators and check if they have auth middleware..."
But I often want it to search the files and show me but the LLM doesn't trigger a tool use call.
To fine-tune it for tool use I combined two data sources:
1. Magpie scenarios - 5000+ diverse tasks (bug hunting, refactoring, security audits)
2. Real execution - Ran these on actual repos (FastAPI, Django, React) to get authentic tool responses
This ensures the model learns both breadth (many scenarios) and depth (real tool behavior).
Tools We Taught:
-
read_file - Actually read file contents-
search_files - Regex/pattern search across codebases-
find_definition - Locate classes/functions-
analyze_imports - Dependency tracking-
list_directory - Explore structure-
run_tests - Execute test suitesImprovements:
- Tool calling accuracy: 12% β 80%
- Correct parameters: 8% β 87%
- Multi-step tasks: 3% β 78%
- End-to-end completion: 5% β 80%
- Tools per task: 0.2 β 3.8
The LoRA really improves on intential tool call as an example consider the query: "Find ValueError in payment module"
The response proceeds as follows:
1. Calls
search_files with pattern "ValueError"2. Gets 4 matches across 3 files
3. Calls
read_file on each match4. Analyzes context
5. Reports: "Found 3 ValueError instances: payment/processor.py:47 for invalid amount, payment/validator.py:23 for unsupported currency..."
Resources:
- Colab notebook https://colab.research.google.com/github/codelion/ellora/blob/main/Ellora_Recipe_3_Enhanced_Tool_Calling_and_Code_Understanding.ipynb
- Model - codelion/Llama-3.2-1B-Instruct-tool-calling-lora
- GitHub - https://github.com/codelion/ellora
Post
5147
I wanted to share a technique that's been working really well for recovering performance after INT4 quantization.
Typically, quantizing the LLM to INT4 (unlike say INT8) for inference can incur some accuracy loss. Instead of accepting the quality loss, we used the FP16 model as a teacher to train a tiny LoRA adapter (rank=16) for the quantized model. The cool part: the model generates its own training data using the Magpie technique so no external datasets needed. This is critical because we want to remain as much as possible in the distribution of the model's natural responses.
Last year Apple's foundational models paper (https://arxiv.org/pdf/2407.21075) had proposed a similar technique and found "By using accuracy-recovery LoRA adapters with only rank 16, Alpaca win rate can be improved by 7-18%, GMS8K accuracy is boosted by 5-10%." (page 47).
We saw similar results on Qwen3-0.6B:
Perplexity: 2.40 β 2.09 (only 5.7% degradation from FP16 baseline)
Memory: Only 0.28GB vs 1.0GB for FP16 (75% reduction)
Speed: 3.0x faster inference than FP16
Quality: Generates correct, optimized code solutions
- Pre-trained adapter: codelion/Qwen3-0.6B-accuracy-recovery-lora
- GitHub repo: https://github.com/codelion/ellora
Happy to answer questions about the implementation or help anyone trying to replicate this. The key insight is that quantization errors are systematic and learnable - a small adapter can bridge the gap without negating the benefits of quantization.
Has anyone else experimented with self-distillation for quantization recovery? Would love to hear about different approaches!
Typically, quantizing the LLM to INT4 (unlike say INT8) for inference can incur some accuracy loss. Instead of accepting the quality loss, we used the FP16 model as a teacher to train a tiny LoRA adapter (rank=16) for the quantized model. The cool part: the model generates its own training data using the Magpie technique so no external datasets needed. This is critical because we want to remain as much as possible in the distribution of the model's natural responses.
Last year Apple's foundational models paper (https://arxiv.org/pdf/2407.21075) had proposed a similar technique and found "By using accuracy-recovery LoRA adapters with only rank 16, Alpaca win rate can be improved by 7-18%, GMS8K accuracy is boosted by 5-10%." (page 47).
We saw similar results on Qwen3-0.6B:
Perplexity: 2.40 β 2.09 (only 5.7% degradation from FP16 baseline)
Memory: Only 0.28GB vs 1.0GB for FP16 (75% reduction)
Speed: 3.0x faster inference than FP16
Quality: Generates correct, optimized code solutions
- Pre-trained adapter: codelion/Qwen3-0.6B-accuracy-recovery-lora
- GitHub repo: https://github.com/codelion/ellora
Happy to answer questions about the implementation or help anyone trying to replicate this. The key insight is that quantization errors are systematic and learnable - a small adapter can bridge the gap without negating the benefits of quantization.
Has anyone else experimented with self-distillation for quantization recovery? Would love to hear about different approaches!
Post
4920
I recently added a recipe in ellora to improve reasoning capabilities to Gemma-3-1B using self-supervised learning. Model now shows step-by-step thinking in <think> tags before answering.
Logic puzzle accuracy: 61% β 84%. 3 hours training on single GPU. π§
Used GRPO where model generates multiple responses and learns to prefer better reasoning. Works surprisingly well for making smaller models more transparent.
π Colab: https://colab.research.google.com/github/codelion/ellora/blob/main/Ellora_Recipe_2_Reasoning_LoRA_with_Self-Rewarding_GRPO.ipynb
π€ Model: codelion/gemma-3-1b-it-reasoning-grpo-lora
π» Code: https://github.com/codelion/ellora
Logic puzzle accuracy: 61% β 84%. 3 hours training on single GPU. π§
Used GRPO where model generates multiple responses and learns to prefer better reasoning. Works surprisingly well for making smaller models more transparent.
π Colab: https://colab.research.google.com/github/codelion/ellora/blob/main/Ellora_Recipe_2_Reasoning_LoRA_with_Self-Rewarding_GRPO.ipynb
π€ Model: codelion/gemma-3-1b-it-reasoning-grpo-lora
π» Code: https://github.com/codelion/ellora
- 1 reply
Post
4685
Released 17 production-ready adaptive text classifiers that learn from just 100 examples per class and continuously improve without retraining.
These models achieve 93% average accuracy across enterprise use cases like email routing, fraud detection, document classification, and support ticket categorization. Built on ModernBERT with prototype memory and elastic weight consolidation.
Key benefits: 90% cost reduction vs API solutions, 90-120ms local inference, dynamic class addition, and zero vendor lock-in.
All models available under adaptive-classifier organization. Install with pip install adaptive-classifier.
Full technical details: https://huggingface.co/blog/codelion/enterprise-ready-classifiers
Code: https://github.com/codelion/adaptive-classifier
These models achieve 93% average accuracy across enterprise use cases like email routing, fraud detection, document classification, and support ticket categorization. Built on ModernBERT with prototype memory and elastic weight consolidation.
Key benefits: 90% cost reduction vs API solutions, 90-120ms local inference, dynamic class addition, and zero vendor lock-in.
All models available under adaptive-classifier organization. Install with pip install adaptive-classifier.
Full technical details: https://huggingface.co/blog/codelion/enterprise-ready-classifiers
Code: https://github.com/codelion/adaptive-classifier
- 2 replies
Post
3651
𧬠We just published our comprehensive analysis of OpenEvolve - an open-source evolutionary coding agent that automatically optimizes algorithms using LLMs!
Our key findings from 29 experiments across 10 models:
- Gemini Flash 2.5 achieved 2.04x speedup across 30 benchmark tasks
- Open models like Gemma 3 27B (1.63x) and Qwen3-Coder 480B (1.41x) rivaled proprietary models
- The system discovered entirely new algorithms - not just code optimizations!
- One task evolved from DFS to BFS to Union-Find approaches
- Specialized coding models outperformed much larger general models 200 iterations beat 100 iterations by 24%
- Ensembles surprisingly failed due to conflicting optimization strategies
Most fascinating: watching models evolve code step-by-step, like transforming matrix operations from basic eigendecomposition to vectorized one-liners with 32x speedup.
Our systematic experimental approach reveals that open-source evolutionary coding is becoming seriously competitive with proprietary solutions. We tested everything from temperature settings to evolution strategies to find optimal configurations.
This research shows automated code optimization is ready for real-world applications. The methodology we developed can guide anyone building evolutionary coding systems.
Full paper with code examples, detailed methodology, and all experimental results: https://huggingface.co/blog/driaforall/towards-open-evolutionary-agents
What optimization challenges could benefit from evolutionary approaches in your work?
Our key findings from 29 experiments across 10 models:
- Gemini Flash 2.5 achieved 2.04x speedup across 30 benchmark tasks
- Open models like Gemma 3 27B (1.63x) and Qwen3-Coder 480B (1.41x) rivaled proprietary models
- The system discovered entirely new algorithms - not just code optimizations!
- One task evolved from DFS to BFS to Union-Find approaches
- Specialized coding models outperformed much larger general models 200 iterations beat 100 iterations by 24%
- Ensembles surprisingly failed due to conflicting optimization strategies
Most fascinating: watching models evolve code step-by-step, like transforming matrix operations from basic eigendecomposition to vectorized one-liners with 32x speedup.
Our systematic experimental approach reveals that open-source evolutionary coding is becoming seriously competitive with proprietary solutions. We tested everything from temperature settings to evolution strategies to find optimal configurations.
This research shows automated code optimization is ready for real-world applications. The methodology we developed can guide anyone building evolutionary coding systems.
Full paper with code examples, detailed methodology, and all experimental results: https://huggingface.co/blog/driaforall/towards-open-evolutionary-agents
What optimization challenges could benefit from evolutionary approaches in your work?
Post
3451
Extended the ICM paper to show cross-model capability transfer - used Qwen3's mathematical reasoning to improve Gemma3 without any human supervision.
Key results:
Qwen3-0.6B: 63.2 β 66.0 on MATH-500 (+4%)
Gemma3-1B: 41.0 β 45.6 on MATH-500 (+11%)
The method extracts coherent reasoning patterns from one model via Internal Coherence Maximization, converts them to DPO training data, and uses that to improve a completely different model architecture.
This goes beyond the original ICM paper which only improved models using their own labels. We're showing you can transfer capabilities between any models - imagine extracting capabilities from strong models to improve your local ones.
Models available:
codelion/Qwen3-0.6B-ICM-DPO
codelion/gemma-3-1b-it-ICM-DPO
Complete collection with code and datasets:
codelion/internal-coherence-maximization-687a1bd1c1f5f1d6f76e9b3b
Full methodology and results:
https://huggingface.co/blog/codelion/internal-coherence-maximization
Planning to extend this to code generation next. The approach could enable community-driven capability sharing between different model families without expensive annotation.
Key results:
Qwen3-0.6B: 63.2 β 66.0 on MATH-500 (+4%)
Gemma3-1B: 41.0 β 45.6 on MATH-500 (+11%)
The method extracts coherent reasoning patterns from one model via Internal Coherence Maximization, converts them to DPO training data, and uses that to improve a completely different model architecture.
This goes beyond the original ICM paper which only improved models using their own labels. We're showing you can transfer capabilities between any models - imagine extracting capabilities from strong models to improve your local ones.
Models available:
codelion/Qwen3-0.6B-ICM-DPO
codelion/gemma-3-1b-it-ICM-DPO
Complete collection with code and datasets:
codelion/internal-coherence-maximization-687a1bd1c1f5f1d6f76e9b3b
Full methodology and results:
https://huggingface.co/blog/codelion/internal-coherence-maximization
Planning to extend this to code generation next. The approach could enable community-driven capability sharing between different model families without expensive annotation.
Post
3312
Implemented Test-Time Diffusion Deep Researcher (TTD-DR) in OptiLLM! π
Just shipped a game-changing feature that turns any LLM into a powerful research agent. TTD-DR applies diffusion-inspired techniques to iteratively refine research reports while grounding them in real web sources.
How it works:
β’ Generates initial draft
β’ Identifies knowledge gaps
β’ Searches web for missing info
β’ Iteratively refines through "denoising" steps
β’ Produces comprehensive reports with 15-30+ sources
The magic? It works with ANY model so you can choose your favorite open-source models on HF!
Key results:
- 47 complex research queries tested
- Every report backed by real web sources
- Quality rivals human research analysts
- No more hallucinations on current events!
Try it:
pip install optillm
Then use "deep_research-your-model-name" as the model identifier
- Implementation: https://github.com/codelion/optillm/tree/main/optillm/plugins/deep_research
- Paper: https://arxiv.org/abs/2507.16075v1
- Sample reports: https://github.com/codelion/optillm/tree/main/optillm/plugins/deep_research/sample_reports
Special thanks to the TTD-DR paper authors for this brilliant approach!
#research #llm #opensource #inference
Just shipped a game-changing feature that turns any LLM into a powerful research agent. TTD-DR applies diffusion-inspired techniques to iteratively refine research reports while grounding them in real web sources.
How it works:
β’ Generates initial draft
β’ Identifies knowledge gaps
β’ Searches web for missing info
β’ Iteratively refines through "denoising" steps
β’ Produces comprehensive reports with 15-30+ sources
The magic? It works with ANY model so you can choose your favorite open-source models on HF!
Key results:
- 47 complex research queries tested
- Every report backed by real web sources
- Quality rivals human research analysts
- No more hallucinations on current events!
Try it:
pip install optillm
Then use "deep_research-your-model-name" as the model identifier
- Implementation: https://github.com/codelion/optillm/tree/main/optillm/plugins/deep_research
- Paper: https://arxiv.org/abs/2507.16075v1
- Sample reports: https://github.com/codelion/optillm/tree/main/optillm/plugins/deep_research/sample_reports
Special thanks to the TTD-DR paper authors for this brilliant approach!
#research #llm #opensource #inference
Post
1577
New research: Understanding how different LLMs approach reasoning through "thought anchors"
I just published a comparative study analyzing the reasoning patterns of Qwen3-0.6B vs DeepSeek-R1-Distill-1.5B using thought anchors - critical sentences that significantly impact task success probability.
Key findings:
- DeepSeek-R1: Uses concentrated reasoning with fewer, high-impact steps (0.408 avg impact)
- Qwen3: Employs distributed reasoning spreading impact across multiple steps (0.278 avg impact)
- Different risk-reward profiles: DeepSeek more consistent (82.7% positive steps), Qwen3 more exploratory (71.6% positive)
This reveals different cognitive architectures rather than simple performance differences. The models optimize for different reasoning strategies - consistency vs exploration.
Both datasets are now available on HF:
- Qwen3 thought anchors: codelion/Qwen3-0.6B-pts-thought-anchors
- DeepSeek-R1 thought anchors: codelion/DeepSeek-R1-Distill-Qwen-1.5B-pts-thought-anchors
Built using our open-source PTS library for mechanistic interpretability analysis. All methodology is fully reproducible.
Full article: https://huggingface.co/blog/codelion/understanding-model-reasoning-thought-anchors
What reasoning patterns have you noticed in your model experiments? Would love to hear about other architectures showing similar cognitive diversity!
I just published a comparative study analyzing the reasoning patterns of Qwen3-0.6B vs DeepSeek-R1-Distill-1.5B using thought anchors - critical sentences that significantly impact task success probability.
Key findings:
- DeepSeek-R1: Uses concentrated reasoning with fewer, high-impact steps (0.408 avg impact)
- Qwen3: Employs distributed reasoning spreading impact across multiple steps (0.278 avg impact)
- Different risk-reward profiles: DeepSeek more consistent (82.7% positive steps), Qwen3 more exploratory (71.6% positive)
This reveals different cognitive architectures rather than simple performance differences. The models optimize for different reasoning strategies - consistency vs exploration.
Both datasets are now available on HF:
- Qwen3 thought anchors: codelion/Qwen3-0.6B-pts-thought-anchors
- DeepSeek-R1 thought anchors: codelion/DeepSeek-R1-Distill-Qwen-1.5B-pts-thought-anchors
Built using our open-source PTS library for mechanistic interpretability analysis. All methodology is fully reproducible.
Full article: https://huggingface.co/blog/codelion/understanding-model-reasoning-thought-anchors
What reasoning patterns have you noticed in your model experiments? Would love to hear about other architectures showing similar cognitive diversity!
Post
460
New SOTA for 26-circle packing problem! ypwang61 achieved 2.635977 sum of radii using OpenEvolve evolutionary optimization framework.
Progress: AlphaEvolve originally reported 2.635 in their paper, OpenEvolve made improvements, and now we have this new record at 2.635977.
The solution uses multi-stage optimization with specialized pattern initialization and enhanced penalty functions. Circle packing is a notoriously hard optimization problem where these small improvements actually represent significant algorithmic advances.
Great example of how evolutionary algorithms can push boundaries in computational geometry optimization. The implementation and results are shared openly on GitHub.
Link: https://github.com/codelion/openevolve/issues/156
Progress: AlphaEvolve originally reported 2.635 in their paper, OpenEvolve made improvements, and now we have this new record at 2.635977.
The solution uses multi-stage optimization with specialized pattern initialization and enhanced penalty functions. Circle packing is a notoriously hard optimization problem where these small improvements actually represent significant algorithmic advances.
Great example of how evolutionary algorithms can push boundaries in computational geometry optimization. The implementation and results are shared openly on GitHub.
Link: https://github.com/codelion/openevolve/issues/156
Post
2385
π Just published: "OpenEvolve: Open-Source Evolutionary Code Optimization with Real-World GPU Kernel Discovery"
We built the first open-source implementation of Google's AlphaEvolve system and used it to automatically discover GPU kernel optimizations that outperform human engineers!
Key results:
- 21.8% average decode speed improvement on Apple Silicon
- 36.7% improvement on long-context transformer attention
- Discovered novel vectorization patterns and 2-pass softmax algorithm
The system evolved a Metal kernel for Qwen3's Grouped Query Attention from a basic 3-pass implementation into something with sophisticated Apple Silicon optimizations that would take experts months to discover manually. The evolved kernel automatically found the optimal vec<T,8> operations for 128-dim attention heads and fused softmax computation with value accumulation.
Really excited about the potential here - imagine evolutionary algorithms automatically discovering optimizations across all our AI infrastructure. What would you want to optimize with this approach?
Full write-up: https://huggingface.co/blog/codelion/openevolve-gpu-kernel-discovery
GitHub: https://github.com/codelion/openevolve
#AI #MachineLearning #GPU #OpenSource #Evolution #CodeOptimization #TransformerOptimization
We built the first open-source implementation of Google's AlphaEvolve system and used it to automatically discover GPU kernel optimizations that outperform human engineers!
Key results:
- 21.8% average decode speed improvement on Apple Silicon
- 36.7% improvement on long-context transformer attention
- Discovered novel vectorization patterns and 2-pass softmax algorithm
The system evolved a Metal kernel for Qwen3's Grouped Query Attention from a basic 3-pass implementation into something with sophisticated Apple Silicon optimizations that would take experts months to discover manually. The evolved kernel automatically found the optimal vec<T,8> operations for 128-dim attention heads and fused softmax computation with value accumulation.
Really excited about the potential here - imagine evolutionary algorithms automatically discovering optimizations across all our AI infrastructure. What would you want to optimize with this approach?
Full write-up: https://huggingface.co/blog/codelion/openevolve-gpu-kernel-discovery
GitHub: https://github.com/codelion/openevolve
#AI #MachineLearning #GPU #OpenSource #Evolution #CodeOptimization #TransformerOptimization
- 1 reply
Post
2552
Adaptive Classifier: Dynamic Text Classification with Strategic Learning
New text classification system that learns continuously without catastrophic forgetting. Achieved 22.2% robustness improvement on adversarial datasets while maintaining clean data performance.
π― THE PROBLEM
Traditional classifiers require complete retraining when adding new classes. Expensive and time-consuming, especially with adversarial users trying to game the system.
π KEY INNOVATIONS
β’ Hybrid memory-neural architecture (prototype-based + neural adaptation)
β’ Strategic classification using game theory to predict and defend against manipulation
β’ Elastic Weight Consolidation prevents catastrophic forgetting
π RESULTS
Tested on AI-Secure/adv_glue dataset:
β’ Clean data: 80.0% β 82.2% (+2.2%)
β’ Manipulated data: 60.0% β 82.2% (+22.2%)
β’ Zero performance drop under adversarial attacks
π¬ APPLICATIONS
β’ Hallucination detection: 80.7% recall for RAG safety
β’ LLM routing: 26.6% cost optimization improvement
β’ Content moderation: Robust against gaming attempts
βοΈ USAGE
pip install adaptive-classifier
from adaptive_classifier import AdaptiveClassifier
classifier = AdaptiveClassifier("bert-base-uncased")
classifier.add_examples(texts, labels)
predictions = classifier.predict("New text")
π RESOURCES
Blog: https://huggingface.co/blog/codelion/adaptive-classifier
Code: https://github.com/codelion/adaptive-classifier
Models:
adaptive-classifier
Available models: llm-hallucination-detector, llm-config-optimizer, llm-router
Works with any HuggingFace transformer. Fully open source and production-ready!
New text classification system that learns continuously without catastrophic forgetting. Achieved 22.2% robustness improvement on adversarial datasets while maintaining clean data performance.
π― THE PROBLEM
Traditional classifiers require complete retraining when adding new classes. Expensive and time-consuming, especially with adversarial users trying to game the system.
π KEY INNOVATIONS
β’ Hybrid memory-neural architecture (prototype-based + neural adaptation)
β’ Strategic classification using game theory to predict and defend against manipulation
β’ Elastic Weight Consolidation prevents catastrophic forgetting
π RESULTS
Tested on AI-Secure/adv_glue dataset:
β’ Clean data: 80.0% β 82.2% (+2.2%)
β’ Manipulated data: 60.0% β 82.2% (+22.2%)
β’ Zero performance drop under adversarial attacks
π¬ APPLICATIONS
β’ Hallucination detection: 80.7% recall for RAG safety
β’ LLM routing: 26.6% cost optimization improvement
β’ Content moderation: Robust against gaming attempts
βοΈ USAGE
pip install adaptive-classifier
from adaptive_classifier import AdaptiveClassifier
classifier = AdaptiveClassifier("bert-base-uncased")
classifier.add_examples(texts, labels)
predictions = classifier.predict("New text")
π RESOURCES
Blog: https://huggingface.co/blog/codelion/adaptive-classifier
Code: https://github.com/codelion/adaptive-classifier
Models:
adaptive-classifier
Available models: llm-hallucination-detector, llm-config-optimizer, llm-router
Works with any HuggingFace transformer. Fully open source and production-ready!
Post
1630
DeepThink Plugin: Bringing Gemini 2.5's Parallel Reasoning to Open Models
Just released an open-source plugin that implements Google's "Deep Think" reasoning approach for models like DeepSeek R1, Qwen3, and other open models.
Google's recent Gemini 2.5 report introduced Deep Think - a technique where models generate multiple hypotheses in parallel and critique them before arriving at final answers. It achieves SOTA results on math olympiads and competitive coding benchmarks.
Our implementation works by modifying the inference pipeline to explore multiple solution paths simultaneously, then synthesizing the best approach. Instead of single-pass generation, models run an internal debate before responding.
Key features:
- Works with any model that supports structured reasoning patterns
- Implements parallel thinking during response generation
- Particularly effective for complex reasoning tasks, math, and coding problems
- Increases inference time but significantly improves answer quality
The plugin won the Cerebras & OpenRouter Qwen 3 Hackathon, validating that this approach works well beyond Google's proprietary implementation.
GitHub: https://github.com/codelion/optillm/tree/main/optillm/plugins/deepthink
Demo: https://www.youtube.com/watch?v=b06kD1oWBA4
The goal is democratizing advanced reasoning capabilities that were previously locked behind APIs. Perfect for researchers and practitioners working with local deployments who want enhanced reasoning without dependency on proprietary services.
Performance notes: Currently about 2-3x slower inference but much better results on complex problems. Working on adaptive triggering to only activate when problems benefit from parallel reasoning.
Would love feedback from the HF community and collaborations on optimizing the approach further. Open to PRs and always interested in making open models more capable.
Just released an open-source plugin that implements Google's "Deep Think" reasoning approach for models like DeepSeek R1, Qwen3, and other open models.
Google's recent Gemini 2.5 report introduced Deep Think - a technique where models generate multiple hypotheses in parallel and critique them before arriving at final answers. It achieves SOTA results on math olympiads and competitive coding benchmarks.
Our implementation works by modifying the inference pipeline to explore multiple solution paths simultaneously, then synthesizing the best approach. Instead of single-pass generation, models run an internal debate before responding.
Key features:
- Works with any model that supports structured reasoning patterns
- Implements parallel thinking during response generation
- Particularly effective for complex reasoning tasks, math, and coding problems
- Increases inference time but significantly improves answer quality
The plugin won the Cerebras & OpenRouter Qwen 3 Hackathon, validating that this approach works well beyond Google's proprietary implementation.
GitHub: https://github.com/codelion/optillm/tree/main/optillm/plugins/deepthink
Demo: https://www.youtube.com/watch?v=b06kD1oWBA4
The goal is democratizing advanced reasoning capabilities that were previously locked behind APIs. Perfect for researchers and practitioners working with local deployments who want enhanced reasoning without dependency on proprietary services.
Performance notes: Currently about 2-3x slower inference but much better results on complex problems. Working on adaptive triggering to only activate when problems benefit from parallel reasoning.
Would love feedback from the HF community and collaborations on optimizing the approach further. Open to PRs and always interested in making open models more capable.
Post
2051
New Research: Theoretical Foundations for In-Context Learning in Transformers
I'm excited to share our latest theoretical work that formally proves an interesting property of large language models: base transformer models can approximate fine-tuned capabilities using only inference-time techniques like in-context learning.
The core question we investigated: Can specialized behaviors typically acquired through expensive supervised fine-tuning be elicited from base models without any parameter updates?
Our theoretical contribution: We provide a formal proof, grounded in the Turing completeness of transformers, showing that this is indeed possible under certain assumptions. The work establishes mathematical bounds on the minimal dataset sizes needed for approximation.
Key theoretical results:
- For text generation tasks: O(mV/Ρ²) examples suffice (where m = number of contexts, V = vocabulary size, Ρ = error tolerance)
- For linear classification: O(d/Ξ΅) examples (where d = input dimension)
- Extensions to finite context scenarios with practical bounds
This work helps explain why techniques like few-shot prompting, retrieval-augmented generation, and in-context learning work so effectively in practice. It bridges formal computer science theory with empirical observations about modern language models.
While the assumptions are idealized (unbounded computational resources, full dataset access), the results provide mathematical foundations for understanding inference-time adaptation strategies that are increasingly important in AI deployment.
Paper: Eliciting Fine-Tuned Transformer Capabilities via Inference-Time Techniques (2506.08060)
I'm excited to share our latest theoretical work that formally proves an interesting property of large language models: base transformer models can approximate fine-tuned capabilities using only inference-time techniques like in-context learning.
The core question we investigated: Can specialized behaviors typically acquired through expensive supervised fine-tuning be elicited from base models without any parameter updates?
Our theoretical contribution: We provide a formal proof, grounded in the Turing completeness of transformers, showing that this is indeed possible under certain assumptions. The work establishes mathematical bounds on the minimal dataset sizes needed for approximation.
Key theoretical results:
- For text generation tasks: O(mV/Ρ²) examples suffice (where m = number of contexts, V = vocabulary size, Ρ = error tolerance)
- For linear classification: O(d/Ξ΅) examples (where d = input dimension)
- Extensions to finite context scenarios with practical bounds
This work helps explain why techniques like few-shot prompting, retrieval-augmented generation, and in-context learning work so effectively in practice. It bridges formal computer science theory with empirical observations about modern language models.
While the assumptions are idealized (unbounded computational resources, full dataset access), the results provide mathematical foundations for understanding inference-time adaptation strategies that are increasingly important in AI deployment.
Paper: Eliciting Fine-Tuned Transformer Capabilities via Inference-Time Techniques (2506.08060)
- 1 reply
Post
4501
Excited to onboard FeatherlessAI on Hugging Face as an Inference Provider - they bring a fleet of 6,700+ LLMs on-demand on the Hugging Face Hub π€―
Starting today, you'd be able to access all those LLMs (OpenAI compatible) on HF model pages and via OpenAI client libraries too! π₯
Go, play with it today: https://huggingface.co/blog/inference-providers-featherless
P.S. They're also bringing on more GPUs to support all your concurrent requests!
Starting today, you'd be able to access all those LLMs (OpenAI compatible) on HF model pages and via OpenAI client libraries too! π₯
Go, play with it today: https://huggingface.co/blog/inference-providers-featherless
P.S. They're also bringing on more GPUs to support all your concurrent requests!
- 1 reply
codelionΒ
authored
2
papers
3 months ago
Post
3472
π§ We just implemented Andrej Karpathy's "third paradigm" for LLM learning!
System Prompt Learning (SPL) enables LLMs to automatically learn problem-solving strategies from experience, rather than relying on static prompts.
π How it works:
Your LLM builds a database of effective strategies, selects the best ones for each problem, and refines them over time based on success rates.
π Results across math benchmarks:
Arena Hard: 29% β 37.6% (+8.6%)
AIME24: 23.33% β 30% (+6.67%)
OptILLMBench: 61% β 65% (+4%)
The best part? All strategies are human-readable and the system gets progressively better at problem types you use frequently.
β¨ Key benefits:
π Cumulative learning over time
π Transparent, inspectable strategies
π Works with any OpenAI-compatible API
β‘ Simple integration: just add "spl-" prefix to your model
Built as an open-source plugin in optillm. After 500 queries, our system developed 129 strategies and refined 97 of them!
This feels like a genuine step toward AI that learns from experience while staying completely interpretable.
π GitHub: https://github.com/codelion/optillm/tree/main/optillm/plugins/spl
π Full article: https://huggingface.co/blog/codelion/system-prompt-learning
π¦ Original Karpathy tweet: https://x.com/karpathy/status/1921368644069765486
Have you experimented with advanced system prompting? What strategies would you want your LLM to learn?
System Prompt Learning (SPL) enables LLMs to automatically learn problem-solving strategies from experience, rather than relying on static prompts.
π How it works:
Your LLM builds a database of effective strategies, selects the best ones for each problem, and refines them over time based on success rates.
π Results across math benchmarks:
Arena Hard: 29% β 37.6% (+8.6%)
AIME24: 23.33% β 30% (+6.67%)
OptILLMBench: 61% β 65% (+4%)
The best part? All strategies are human-readable and the system gets progressively better at problem types you use frequently.
β¨ Key benefits:
π Cumulative learning over time
π Transparent, inspectable strategies
π Works with any OpenAI-compatible API
β‘ Simple integration: just add "spl-" prefix to your model
Built as an open-source plugin in optillm. After 500 queries, our system developed 129 strategies and refined 97 of them!
This feels like a genuine step toward AI that learns from experience while staying completely interpretable.
π GitHub: https://github.com/codelion/optillm/tree/main/optillm/plugins/spl
π Full article: https://huggingface.co/blog/codelion/system-prompt-learning
π¦ Original Karpathy tweet: https://x.com/karpathy/status/1921368644069765486
Have you experimented with advanced system prompting? What strategies would you want your LLM to learn?
Post
2363
Introducing AutoThink: Adaptive reasoning for LLMs that improves performance by 43% on reasoning benchmarks!
Instead of using fixed thinking budgets, AutoThink:
- Classifies query complexity (HIGH/LOW) using adaptive classification
- Dynamically allocates thinking tokens based on complexity
- Uses steering vectors derived from Pivotal Token Search to guide reasoning patterns
Results on DeepSeek-R1-Distill-Qwen-1.5B:
- GPQA-Diamond: 31.06% vs 21.72% baseline (+9.34 points)
- MMLU-Pro: 26.38% vs 25.58% baseline (+0.8 points)
- Uses fewer tokens than baseline approaches
Works with any local reasoning model - DeepSeek, Qwen, Llama, custom models. The technique combines our research on Pivotal Token Search (PTS) implementation and adaptive classification frameworks.
Paper: AutoThink: efficient inference for reasoning LLMs
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5253327
Code and examples:
https://github.com/codelion/optillm/tree/main/optillm/autothink
PTS implementation and technical details:
https://github.com/codelion/pts
https://huggingface.co/blog/codelion/pts
Adaptive classifier framework:
https://github.com/codelion/adaptive-classifier
Would love to hear your thoughts on adaptive resource allocation for LLM reasoning! Have you experimented with similar approaches?
Instead of using fixed thinking budgets, AutoThink:
- Classifies query complexity (HIGH/LOW) using adaptive classification
- Dynamically allocates thinking tokens based on complexity
- Uses steering vectors derived from Pivotal Token Search to guide reasoning patterns
Results on DeepSeek-R1-Distill-Qwen-1.5B:
- GPQA-Diamond: 31.06% vs 21.72% baseline (+9.34 points)
- MMLU-Pro: 26.38% vs 25.58% baseline (+0.8 points)
- Uses fewer tokens than baseline approaches
Works with any local reasoning model - DeepSeek, Qwen, Llama, custom models. The technique combines our research on Pivotal Token Search (PTS) implementation and adaptive classification frameworks.
Paper: AutoThink: efficient inference for reasoning LLMs
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5253327
Code and examples:
https://github.com/codelion/optillm/tree/main/optillm/autothink
PTS implementation and technical details:
https://github.com/codelion/pts
https://huggingface.co/blog/codelion/pts
Adaptive classifier framework:
https://github.com/codelion/adaptive-classifier
Would love to hear your thoughts on adaptive resource allocation for LLM reasoning! Have you experimented with similar approaches?
-
- 5 replies