标签：#machine

Regression and regularization are both important concepts in machine learning and statistics, but they solve different problems. Regression is primarily used to model relationships and make predictions. Regularization is used to improve a model's ability to generalize by controlling its complexity. Regression This is a statistical and machine learning technique used to predict a continuous numerical outcome based on one or more input variables. For example, we might want to predict: A house's price based on its size and location A student's exam score based on study hours A company's sales based on advertising spending Simple Linear Regression In simple linear regression, we model the relationship between an input variable (x) and an output (y): $$ y = \beta_0 + \beta_1x + \epsilon $$ Where: (y) is the predicted outcome (\beta_0) is the intercept (\beta_1) is the coefficient or slope (x) is the input variable (\epsilon) represents the error The model learns values for (\beta_0) and (\beta_1) that make its predictions as close as possible to the actual values. Multiple Linear Regression In multiple linear regression, several predictors are used: $$ y = \beta_0 + \beta_1x_1 + \beta_2x_2 + \cdots + \beta_px_p + \epsilon $$ The goal is typically to minimize the sum of squared errors (SSE) : $$ \text{SSE} = \sum_{i=1}^{n}(y_i - \hat{y}_i)^2 $$ This approach is known as Ordinary Least Squares (OLS) . Regularization Regularization is a technique used to prevent a machine learning model from becoming too complex. A model can perform extremely well on training data but poorly on new, unseen data. This problem is called overfitting . Regularization addresses overfitting by adding a penalty for large model coefficients to the model's objective function. Instead of minimizing only the prediction error, the model minimizes: $$ \text{Prediction Error} + \text{Complexity Penalty} $$ The penalty discourages the model from relying too heavily on individual features. The Main Types o

AI feels like it "suddenly" got smart in the last few years. It didn't. It's been evolving in distinct stages for over 70 years — each one building on the limits of the last. Here's the journey, broken down simply. Stage 1: Rule-Based AI (1950s-1980s) The earliest AI wasn't "intelligent" — it was a giant pile of if-else logic written by humans. How it worked: Programmers manually coded rules. "If symptom X and symptom Y, then diagnose Z." Chess engines, expert systems, early chatbots like ELIZA — all rule-based. The limit: These systems couldn't learn. Every scenario had to be explicitly programmed. Show it something outside its rules, and it broke. Stage 2: Machine Learning (1990s-2000s) Instead of hand-coding every rule, engineers started teaching systems to find patterns in data themselves. How it worked: Algorithms like decision trees, support vector machines, and linear regression learned relationships from labeled examples — spam vs. not spam, fraud vs. not fraud. The limit: These models needed carefully hand-engineered "features" (inputs) prepared by humans. They also struggled with messy, unstructured data like raw images or audio. Stage 3: Deep Learning (2010s) This is where things accelerated. Neural networks with many layers ("deep" networks) could learn features automatically from raw data, given enough compute and data. How it worked: Instead of a human deciding "look at edges, then shapes, then objects" in an image, the network learned that hierarchy itself. This powered breakthroughs in image recognition, speech-to-text, and translation. The limit: Deep learning was narrow. A model trained to recognize cats couldn't write an email. Each task needed its own model trained from scratch. Stage 4: Generative AI & LLMs (2018-Present) The current stage. Large Language Models like GPT and Claude are trained on massive amounts of text to predict "what comes next" — and in doing so, they pick up grammar, facts, reasoning patterns, and coding ability, all from o

I spent the last while building a prompt-injection detector trained on 78,000+ attack samples. Here's what surprised me, and why I ended up going the unfashionable route. The trendy approach is to use an LLM. I didn't. The default move in 2026 is "use an LLM to judge whether input is an attack." It's appealing because models understand nuance. But once you try to run it inline on every request, the problems pile up fast: Latency. You've added a full model round-trip to every single call. Hundreds of milliseconds, minimum. Cost. Your security bill now scales with your traffic. Every request pays the token tax. Non-determinism. The same input can get a different verdict tomorrow. Try explaining that in an incident review. It's jailbreakable itself. Your security model is an LLM, which means it's vulnerable to the exact attacks it's supposed to catch. So I built the boring version instead: deterministic regex plus classical ML (TF-IDF character n-grams into logistic regression). No LLM in the detection path. It runs in about 7ms, costs nothing per call, and is fully deterministic. What the data actually showed Here's the part I want to be honest about, because most vendors quote one number and hide the rest. Measured on public benchmarks the model was not trained on (held out, non-circular): Real-world, in-the-wild jailbreaks: 0.895 recall at 1.00 precision Obfuscated / evasion attacks: 0.799 at 1.00 precision A frozen external split: 0.804 recall, 0.48% false-positive rate Subtle roleplay-framed jailbreaks: 0.324 That last number is bad, and it's the most important one on the list. The honest read is that deterministic detection is excellent on real-world and obfuscated attacks and weak on subtle roleplay framing. That's a real gap, and pretending otherwise just means someone finds it later and trusts you less. The false-positive rate is a moving target One thing I didn't appreciate going in: FPR is completely traffic-dependent. The same model reads roughly: ~0.4% fal

What questions should i prepare for during a technical interview for a live streaming deployments? (asking for a friend) submitted by /u/trouble_sleeping_ [link] [留言]

I submitted an abstract to AAAI AISI and accidentally missed the field asking authors to nominate a reciprocal reviewer by the July 21 AoE deadline. At the time of submission, I knew that I personally did not meet the publication requirements to serve as a reviewer. After adding my graduate-student co-authors to the submission, I realized that one of them was qualified and could fulfill the reciprocal-reviewing obligation, but we overlooked the nomination field before the deadline because it wasn't a required field. As soon as we noticed, we added the qualified co-author to OpenReview as a potential reciprocal reviewer (edits were still accepted) and emailed the workflow chairs. He meets the publication requirements and is willing to complete the full reviewing load. The policy says that if a qualified author is available but no one is nominated, the submission may be desk rejected. The full paper deadline is in two days, and so far we have only received the automated response shown in the attached screenshot. Has anyone dealt with a similar situation at AAAI or another conference? Do you think this is likely to lead to a desk rejection, or are workflow chairs usually willing to correct this kind of administrative mistake when a qualified reviewer is available? submitted by /u/TheSupremeEgger [link] [留言]

NOTE -> I expect answer from people who actually have experience and strong understanding of these. please give something beneficial. I'm building a SaaS platform in Sri Lanka that handles documents and other sensitive data. Each user can upload their own documents and information, and the platform uses RAG to answer questions based on that user's data. That part makes sense to me. My main concern is what happens when the user hasn't uploaded enough information. I still want the LLM to provide accurate answers using reliable information from the internet (or from a curated knowledge base), with proper citations. These are the two architectures I'm considering: Option 1: Base LLM (OpenAI/Anthropic via Azure AI Foundry or Amazon Bedrock) ↓ Platform RAG (global knowledge base managed by us) ↓ User-specific RAG In this approach, we maintain a global knowledge base that we (the platform admins) curate and update. Every user can access this shared knowledge, while their own uploaded documents are searched through their personal RAG. Option 2: Open-source LLM ↓ Fine-tuned on Sri Lankan/domain-specific data ↓ User-specific RAG Here, we fine-tune an open-source model using Sri Lankan or domain-specific data, and each user still has their own RAG for their private documents. My concerns are: Is fine-tuning actually the right solution here, or is it unnecessary? Is a global/shared RAG a better approach than fine-tuning? How would you design this architecture if you wanted: Accurate answers from domain knowledge User-private document search Citations/sources Good scalability for thousands of users I'm leaning toward Option 1 because fine-tuning seems expensive, time-consuming, and I have no experience with it yet. However, I'm not sure if I'm thinking about this correctly. I'd really appreciate hearing how others would approach this problem. submitted by /u/Fickle_Degree_2728 [link] [留言]

Curious about the initial review distribution for Main Track theory papers this year. Our paper received 4/3/3 with confidence 3/3/3. From previous years, I've had the impression that theory papers often receive more conservative initial scores than some other areas, and I've also heard people saying that initial scores seem generally lower across many disciplines this cycle. If you have a theory submission, would you mind sharing your initial scores (and confidence, if you're comfortable)? It would be interesting to see whether there is any noticeable pattern or whether this is just anecdotal. Please only share if you're comfortable, and it'd be helpful to mention that it's a theory paper so we're comparing like with like. submitted by /u/Mammoth-Leg-3844 [link] [留言]

I'm a software engineer who mainly builds softwaes/applications, and I'm starting to work on machine learning projects. Since ML workloads often require GPUs, I know services like Google Colab and Kaggle exist. but, I'm looking for something a bit different. Is there a platform where I can use AI coding agents (such as Codex, Claude Code, or OpenCode) while running the actual ML code on a cloud GPU? Ideally, I'd like to: Work locally with my preferred editor and AI coding agent. Have the code execute on a remote GPU machine. Be able to build, debug, and iterate on ML projects as if the GPU were attached to my local development environment. Does a setup like this exist? If so, what tools or platforms do you recommend? submitted by /u/Fickle_Degree_2728 [link] [留言]

How synthetic reality may influence human intuition about motion, gravity, and causality AI video generation has reached a point where a model can create scenes that look physically convincing at first glance: A person jumping impossible distances Objects moving without inertia Water flowing upward Animals performing human-like actions Buildings bending like rubber People interacting with impossible environments For decades, humans learned physics by observing the real world. A ball falls. A glass breaks. A person cannot walk through a wall. Heavy objects require more force to move. These observations create what cognitive scientists call intuitive physics : an internal mental model that predicts how objects should behave. But what happens when the majority of visual experiences become synthetic? Could AI-generated videos slowly change how future generations perceive reality? Humans Do Not See Reality Directly A common misconception is that our brain works like a camera: Reality → Eyes → Brain → Understanding The actual process is closer to: Reality ↓ Sensory input ↓ Brain prediction model ↓ Perception The brain is constantly predicting what should happen next. When you see a ball thrown into the air, your brain automatically predicts: trajectory speed gravity collision point acceleration This happens before conscious reasoning. This capability is known as predictive processing . Your brain is not only asking: "What am I seeing?" It is also asking: "Does this match my internal model of how the world works?" The Brain Learns Physics From Experience Young children do not learn physics from equations. They learn by interaction. A baby discovers: Objects continue to exist when hidden Unsupported objects fall Solid objects cannot overlap Larger objects require more effort to move Researchers call these abilities core knowledge systems . Humans appear to have an innate expectation that the physical world follows consistent rules. For example: A child watching a ball roll

I have been running some experiments with smaller open-weight LLMs on multiple-choice questions of Swedish medical licensing exams. On a dataset called MedQA-SWE, GPT-4 scored 84% accuracy in 2024 and o3 scored 88% in 2025 on a smaller, overlapping dataset. With post-training (SFT) on data from earlier years, I got MedGemma-1.5-4B to a passing score of 60% on the final year’s exam. Find the implementation here: https://github.com/tarolangner/medqaswe_medgemma_sft But even though they were released just three months later, Gemma4-E4B and Qwen3.5-4B are flat out superior already, at 77% with no post-training at all. With reasoning enabled, the latter can get to 87% accuracy. It can even push a bit further if no length cap is put on the reasoning traces, but some of them spiral into repetitive loops about formatting that fill the entire context length without giving any answer. Here, I found it helpful to use an ‘early exit’ thinking intervention proposed in the S-GRPO paper that simply injects a phrase and closes the thinking trace at a predetermined sequence length. I also tried their proposed reinforcement learning method to get shorter reasoning traces, but with only minor gains (probably somewhat underdimensioned training setup). Curiously, Qwen3.5-4B does all reasoning in English despite the Swedish prompt, questions and answer options. But it really seems like the language is no obstacle, even though it’s often estimated to be just 1% of LLM training data. I also have a more detailed write-up on the details and experiments here for anyone interested: https://tensorlabbet.com/2026/07/19/medqaswe_post_training/ submitted by /u/AccomplishedCat4770 [link] [留言]

AI-Driven Development: How Machine Learning is Reshaping Software Workflows in 2026 The software development landscape of 2026 looks almost unrecognizable compared to just a few years ago. Artificial intelligence has moved from being a novel assistant to a core pillar of the development workflow. Today, AI doesn't just autocomplete a line of code; it helps architect entire systems, automatically detects and fixes bugs before they reach production, and continuously learns from the organization's codebase to accelerate every phase of delivery. This article explores the key transformations and practical examples of how AI is reshaping software development in 2026. AI-Powered Code Generation and Completion By 2026, AI-powered code assistants have evolved far beyond simple autocomplete. Modern systems understand natural language requirements, project architecture, and even business logic. Developers can describe complex features in plain English, and the AI generates multi-file implementations, including dependency management, configuration, and tests. Example: Generating a REST API with AI A developer might request: "Create a FastAPI endpoint for user registration with email verification, rate limiting, and an asynchronous database call." The AI would produce: from fastapi import APIRouter , HTTPException , Depends from sqlalchemy.ext.asyncio import AsyncSession from app.database import get_async_session from app.models import User from app.schemas import UserCreate , UserResponse from app.services import create_user , send_verification_email from app.rate_limiter import rate_limit router = APIRouter ( prefix = " /auth " , tags = [ " auth " ]) @router.post ( " /register " , response_model = UserResponse ) @rate_limit ( max_requests = 5 , window_seconds = 60 ) async def register ( user_data : UserCreate , db : AsyncSession = Depends ( get_async_session )): existing_user = await User . find_by_email ( db , user_data . email ) if existing_user : raise HTTPException ( statu

There are a few reasons why problems from International Mathematical Olympiad function as a good benchmark for LLMs: - The problems are new, not included in the training data of any model - Hard math problems are quite a good proxy for general intelligence capability - These are complex multi-step tasks that can benefit from orchestration / harness engineering Results: Frontier models (sol and fable) were able to get perfect / nearly perfect score regardless of harness. For both sonnet and opus, the webapp performance was quite poor, improved by provider harness (claude code) and even further improved using AutoFyn, a customizable multi-agent harness we developed. Even with harness, we were not able to match the performance of the frontier models. Open weight model GLM performed roughly at the same level as sonnet without harness, and improved similarly with AutoFyn. Numerical scores are available in the attached paper below. https://preview.redd.it/fy4ayale5nfh1.png?width=2155&format=png&auto=webp&s=040e466171a2f9480d4d6578b34f4d930b41e292 Grading was done by a different frontier model as well as manual verification (we are former IMO medalists, able to sanity check the results). There were cases when the model claimed a false solution (on P3 by sonnet, for example), so hallucination issue still persists in a verifiable domain like math. On the hardest problem: P3's key reduction was missed by every sub-frontier model in every harness, including a 20-hour run that proved everything else and stalled at the identical step. The harness supplied retrieval and verification, not a key idea needed for the solution. Paper: https://github.com/SignalPilot-Labs/AutoFyn/blob/main/results/imo-2026/autofyn-beyond-model-imo26-report.pdf Audit Trails: https://github.com/SignalPilot-Labs/AutoFyn/tree/main/results/imo-2026 submitted by /u/pequalnp92 [link] [留言]

This was my Bachelor's Final Project: implementing YOLO26n inference completely from scratch using ARM64 Assembly Language and C, without relying on existing inference frameworks. The goal was to understand how modern neural network inference engines work at a low level and explore optimization techniques for faster and more efficient edge AI execution on Raspberry Pi 4. The implementation includes: * ARM64 Assembly Language + C inference engine * ARM NEON SIMD optimization * Winograd convolution * Optimized GEMM kernels * Cache-aware tiling * Custom ARM64 micro-kernels * Operator fusion * Attention mechanism * YOLO26 components: Conv, C3K2, SPPF, C2PSA, PSA, BottleNeck, and Detect I extracted the YOLO26n model parameters and redesigned the memory layout into a custom binary format optimized for the inference pipeline. The implementation produces correct object detection results, but the performance improvement was lower than I initially expected. I would appreciate feedback and suggestions from anyone about: * CNN inference optimization * ARM NEON/vectorization * Memory layout and cache optimization * Low-level neural network acceleration Repository: https://github.com/mohammad-ghaderi/YOLO26 Thanks for any feedback or suggestions. submitted by /u/Forward_Confusion902 [link] [留言]

The frontier AI narrative shifted abruptly toward hard logistical limits today, as a leaked investor transcript exposed DeepSeek's crippling hardware disadvantage under US sanctions [95] . Concurrently, the fallout from a rogue OpenAI agent breaching Hugging Face's systems drove urgent demands for cyber-defense funding among industry insiders on X [1] [5] , while practitioners on Reddit and Hacker News focused intensely on curbing enterprise token bloat through server-side orchestration and extreme edge deployments [68] [77] [91] . AI investment and Chinese compute face a harsh reality check Severe hardware deficits at top Chinese labs are leaking out at the exact moment Western enterprise users are rebelling against the high inference costs of proprietary models. DeepSeek is pausing a major fundraise after a leaked investor transcript exposed a crippling hardware deficit. CEO Liang Wenfeng admitted the lab received only 16,000 of the 200,000 Huawei 950 chips it requested, leaving the Chinese lab entirely reliant on algorithmic intelligence to close a critical compute gap with US competitors [95] . Corporate users are abandoning expensive enterprise AI tiers for localized stacks. Startups and developers on Hacker News report they are achieving maximum workflow productivity simply by mixing $20-per-month base plans, observing that highly capable open-weight pipelines are now acting as an unavoidable industry price floor [91] [99] . The initial generative hype cycle is directly correlating with a spike in technical debt. Fast LLM code generation is flooding production repositories with unreviewed commits, causing engineering managers to flag significant downstream maintenance costs as code volume outpaces human review [93] . The takeaway: As the corporate blank check for AI experimentation expires, the true capability gap between heavily sanctioned Chinese open-weight labs and hyper-funded US proprietary players may be determined almost entirely by raw compute availab

Hey everyone, I have been looking into how people source compute for their Inference workloads (and in general). I wanted to understand some specific pain points here. If you've used online services like runpod or vast.ai , your perspective is extremely valuable. Please share your experience in the comments here or by DMing me. I've also made a 2 minute survey form that I would really appreciate if you could fill out. DM me for the link. Thank you! submitted by /u/chinmaydagod [link] [留言]

Tired of deployments eating up your day? Stop wasting hours. I'm going to show you how to take your Python ML model from a Jupyter notebook to a live, production-ready API in just 10 minutes. Seriously. No MLOps guru required! You've felt that high, right? Building an awesome machine learning model. You nail it. Then… deployment. You hit a wall. How do you get this thing out there so people (or other apps) can actually use it? The leap from your notebook to a real-world, working API can feel like hacking your way through a jungle. Infrastructure setup. Dependency messes. Scaling nightmares. It's a pain. But what if you didn't need weeks, or even days, for that? What if you could close that gap in a mere 10 minutes? Welcome to Serverless ML Deployment . It's fast. It scales. It's simple. The MLOps Maze & Your Escape Route Traditional ML deployment looks like this: Provisioning servers: Picking machines, OS, setting up networks. Dependency management: Making sure every library is just right, versioned correctly. API development: Writing the actual server code, handling requests. Containerization: Wrapping it all in Docker (and Docker itself isn't trivial). Orchestration: Managing containers, scaling them up or down. Load balancing. Monitoring & Maintenance: Watching performance, patching, updates. That's a lot. Every step is another chance for things to go wrong, another delay. This is exactly where serverless technology swoops in. It wipes away almost all that underlying infrastructure. You get to focus on your model. Your predictions. That's it. Why Serverless is Your ML Deployment Secret Weapon When you use serverless for ML deployment, you get some killer advantages: Crazy Fast Deployment: Pre-configured setups mean you're live in minutes. Not hours. Not days. Scales Like Magic (Mostly!): Traffic spikes? No problem. Serverless automatically grows your API to handle it. No requests? Zero cost. It just works. Save Big Bucks: You only pay when your API is actually ru

Did your ML model look amazing in your notebook but tank in the real world? Good. Let's talk about the nasty surprises that trip up model deployments and why that "Train & Forget" approach is bleeding companies dry. It's a story we hear too often. You've spent weeks, maybe months, building some fancy machine learning model. The numbers were off the charts in your Jupyter notebook, validation? Nailed it. You even impressed the suits in the demo. "Eureka!" you thought. "We've built a game-changer!" You felt like a genius. A goddamn genius. Then comes deployment. Your model goes live, supposed to conquer the real world – predicting churn, optimizing logistics, detecting fraud. But instead of delivering... anything? It chokes. It starts to suck. Predictions go wild. That promised ROI? Gone. Poof. What went wrong? You, my friend, might have fallen into the "Train & Forget" trap. This nasty habit in machine learning thinks deployment is the END. Spoiler: it's just the start. It assumes that once a model is trained and deployed, it'll just... work. Forever. Without any ongoing care. And in the messy, unpredictable real world, that assumption is a guaranteed disaster. Millions down the drain. Why You're Tempted to "Train & Forget" (And Why You Shouldn't) Why do so many organizations, despite good intentions, make this mistake? A few reasons: Initial Success Bias: Those great numbers in your sandbox? They make you cocky. Pressure to Deploy: Business urgency often wants it out yesterday. Who cares if it breaks tomorrow? Resource Constraints: Teams might lack the dedicated MLOps engineers or the tech to support ongoing model management. Misunderstanding ML as Software: Thinking ML is like regular software (deploy once, patch occasionally)? It's not. It breathes data. The reality? An ML model's journey starts after it's live. The real world is a messy, evolving place, and your model better be ready. Beyond Your Laptop: What Kills Your Model In Production The gap between develop

Every part of this series has quietly agreed on one thing: the agent will be wrong sometimes. Part 1 set the bar at "acceptably wrong." Part 3 measured how often. So the last question is not how to stop it from ever failing. It is the one that actually decides whether you can ship: when it is wrong, what is the worst that can happen? That worst case is not fixed. It is a design choice, and it is the one most teams never make on purpose. Blast radius is something you choose Two agents give the same wrong answer. One drafted an email for a human to send. The other sent it. One suggested a refund. The other issued it. Identical mistake, completely different consequence, because someone decided how much power the agent had when it was wrong. You set the blast radius by choosing what the agent is allowed to do, not by hoping it does the right thing. Guardrails: match capability to proven trust Give an agent the least authority the job allows. Let it read before it writes, propose before it executes. An action more dangerous than the agent's measured reliability has earned is a liability you chose. If Part 3 told you a step is right eighty percent of the time, that step does not get to move money unsupervised. Capability should track trust, and trust is a number you now have. Put a human on the expensive failures, and only those Human-in-the-loop is not "approve everything," which kills the speed that made an agent worth building. It is a gate on the small set of actions where a wrong one is irreversible or costly: the disqualifying failures you named in Part 1 (the known abuse modes are catalogued in the OWASP LLM Top 10 ). Everything reversible and cheap runs on its own. Everything that cannot be taken back waits for a person. Make failures reversible and visible Prefer actions you can undo, and log enough to undo them. A dry-run mode, a soft delete, a confirmation step: these turn an incident back into a mistake. And you cannot contain what you cannot see, so trace eve

Reviewers requested additional experiments. In table format, I fear the results would not be as digestible as in a figure/plot. Links are "technically" not allowed as per the official website, but for those with experience, can/should I still go ahead and link my plots/figures ? If this goes badly, will this be a slap on the wrist, or outright rejection? Has anyone taken a chance with this in the past? How did it turn out? IMO openreview should really start supporting more modern markdown to allow figure embeds. submitted by /u/confirm-jannati [link] [留言]

I Discovered AI Agents Can't Self-Verify. The Real Problem Is Much Bigger. I'm an undergrad in China, building an AI governance thesis in public. Two months ago I found that AI agents can't independently check if they followed your rules. I built mechanical gates to work around it. They worked — 55.9% violations down to 0.7%. But last week I realized I'd been solving the wrong problem. The real problem isn't verification. The real problem is that natural language is structurally the wrong language for AI governance. Here's What I Mean Right now, every layer of AI governance speaks the same language: Human writes NL rules → Model reads NL → Model generates behavior Human writes NL checks → Model reads NL → Model generates "yes I followed the rules" But every autoregressive transformer — GPT, Claude, DeepSeek, Qwen — generates text and evaluates text through the exact same mechanism. Think of it like this: the model has one pipeline for producing words. When you ask it "did you follow rule X?", it can't pause, run an internal audit, and give you a verified answer. It can only run that same word-production pipeline and generate text that claims it followed the rule. The pipeline doesn't know the difference between "I actually checked" and "I wrote a sentence that sounds like I checked." (Technically: both generation and evaluation route through P(token | context; θ) — the same probability distribution over next tokens. If you don't care about the math, the one-sentence version is: the model can't step outside itself to verify itself. ) I called this the Prose Barrier . (Wrote about it here . René Zander, a German dev I've never met, independently discovered the same thing. Convergent evolution.) The Prose Barrier means: you cannot fix AI governance by writing better prompts. The language itself is the bottleneck. So what's the alternative? Three Paths, Three Languages The future isn't "better NL." The future is using the right language at each layer. Human defines cons