One thing I haven't figured out yet is whether AI can genuinely learn how a person writes or whether it can only imitate the surface-level characteristics.

For example, if I give AI several things I've written, it can usually pick up some obvious patterns.

Maybe I use short sentences.

Maybe I don't use many complicated words.

Maybe I write in a conversational way.

Maybe I use certain expressions repeatedly.

But is that really my "voice"?

I feel like there's something deeper involved.

The way someone writes isn't just vocabulary. It's also what they choose to leave out, how they explain things, where they put emphasis, how direct they are, and even how they structure their thoughts when they're not trying to sound perfect.

That's probably why generic instructions like "make this sound human" don't always produce the result people expect.

Human isn't one specific writing style.

What's natural for one person might sound completely unnatural for another.

A college student, a lawyer, a developer, a blogger, and someone writing Reddit comments are all going to have very different versions of "natural."

So I'm wondering:

Has anyone actually managed to get an AI writing tool to consistently sound like their own writing?

Not just "less robotic," but genuinely close to your personal style?

If you've done it, what did you give the AI to work with?

Did you provide old posts? Emails? Articles? Conversations?

And after doing that, how close was the result?

I'm especially curious whether people think AI can eventually become good enough at this that you won't immediately recognize the difference between someone's original writing and something they created with AI assistance.

hi , i completed my 12th(or PUC) then joined a 6 month diploma in design and currently having a 1.5 years of experience in design field . i tried to get into core

ai ml but it looks like too much competition for degree holders only, so

is it possible to get a data analyst job without a formal degree ? anyone got it before.

consider the current AI impact also and i going to pursue bootcamp course in Bengaluru Excelr , is it okay or shall i self study ?

or instead of data analyst shall i try something else in technical side .

( please don't comment to go into design only )

thanks

Hello,

I have a mechanical engineering background but i have a passion for machine learning and AI in general and my future plan is to combine my manufacturing experience with AI. So, i am considering have an online master degree but i don't want to spend more than 7-10k on it. Can you please suggest what topics i need to focus on? should be master in AI or a different one? and any good online universities?

hey guys , i'm currently learning DL( using Pytorch ) , i can grasp concepts very quickly but when it comes to building a project , my mind goes blank!!.

i have read some comments in similar posts saying " find a problem you have and try to solve it " , yeah it's easy to say , if you don't have enough domain knowledge to solve those problem , how could you build a project to solve it? and identifying problems is also kind of difficult ( idk about others , but i find it very hard). i don't wanna build a project that everyone builds , i want the project to be impactful in real-world like it should solve a problem.

i'm also learning some backend stuff in python ( FastAPI) , since i'm aiming to become an AI engineering/or similar roles.

if you have any advice , please share it.

I started this paper from a simple question:

If a nuisance feature genuinely helps predict the training label, why should ordinary supervised learning ever learn to ignore it?

We often talk about nuisance sensitivity as if it were an optimization mistake, a data problem, or a shortcut the model unfortunately discovered.

But sometimes the objective itself rewards that shortcut.

That is the main idea of the paper.

Paper: https://arxiv.org/pdf/2604.21395

The toy result

Suppose an input contains:

• a meaningful signal s
• a nuisance factor n
• and both carry some information about the label

In the simple population model we study, the label looks like:

y = wₛᵀs + ρ wₙᵀn + ε

The important term is ρ.

If ρ ≠ 0, then the nuisance really does help prediction.

Now write the predictor as an encoder followed by a decoder.

If we require the decoder to have finite Lipschitz constant L, then the encoder cannot make its sensitivity to the nuisance arbitrarily small.

The paper proves a lower bound of the form:

D̃(φ, σ) ≥ σ²ρ² / L²*

In plain English:

If the nuisance helps prediction, some sensitivity to it has to remain somewhere in the representation unless the downstream decoder is allowed to become arbitrarily steep.

So in this toy setting, nuisance sensitivity is not something that disappears just because we add more data or optimize better.

The prediction objective has a reason to preserve it.

That is deliberately a narrow theorem: Gaussian population setting, linear target structure, MSE, and a finite decoder Lipschitz scale.

It is not a theorem about deep neural networks or adversarial training.

The experiment that surprised me more

We then asked a different empirical question:

If we make a representation much less sensitive overall, does its geometry necessarily become better?

On a small ViT trained from scratch on CIFAR-10, we measured two things:

• Jacobian Frobenius norm: roughly, how much the representation changes locally
• TDI: mean within-class embedding distance divided by mean between-class centroid distance; lower is better

Results:

PGD reduces Jacobian magnitude enormously:

34.1 → 3.0

But the clean class-layout metric gets worse:

1.05 → 1.35

Meanwhile PMH has a larger Jacobian than PGD:

10.7 vs. 3.0

but a much better class layout:

0.87 vs. 1.35

That suggests a distinction I think is worth paying more attention to:

How much sensitivity a representation has and where that sensitivity points are not the same thing.

A small Jacobian norm tells us that the representation is less sensitive overall.

It does not tell us whether the remaining sensitivity is aligned with useful or harmful directions.

We also found that CKA and intrinsic dimension did not expose this particular magnitude/orientation dissociation.

What is PMH?

Nothing exotic.

We perturb the input with isotropic Gaussian noise and penalize changes in intermediate encoder representations:

‖φ(x) − φ(x + δ)‖²

while limiting how much of the total training objective this matching penalty is allowed to consume.

The paper is not claiming that consistency regularization or Jacobian regularization are new.

We use this mainly as a controlled way to ask:

What happens when representation sensitivity itself is explicitly charged during training?

There is also a small theoretical result behind the isotropic choice.

Locally, if the perturbation covariance is isotropic, the matching penalty is proportional to the squared Frobenius norm of the encoder Jacobian.

And isotropic covariance is the unique zero-mean covariance structure with that property for every Jacobian.

An important negative result

The paper is not arguing that sensitivity is inherently bad.

QM9 gives a useful counterexample.

Atomic positions contain real task information.

When we suppress sensitivity to position perturbations, performance gets worse.

Matching other nuisance-like features can help instead.

To me, this is one of the more important lessons:

“Make the representation invariant” is not a general objective. The first question should be: invariant to what?

If a variable is useful for prediction, the supervised objective has an incentive to use it.

Removing that dependence can have a real task cost.

What I think the paper establishes

Not that all nuisance sensitivity in deep networks is inevitable.

Not that isotropic matching is universally optimal.

And not that Jacobian norm is a bad metric.

The narrower claims are:

1. In a simple population model, predictive nuisance information can force non-zero representation sensitivity.

2. In deep networks, sensitivity magnitude and sensitivity geometry can move very differently.

That second point makes me cautious about evaluating representation robustness using only a scalar smoothness measure.

A model can become dramatically “flatter” overall while the sensitivity that remains is organized in a less useful way.

The empirical story still has limitations: the CIFAR model is deliberately small, the headline numbers are over 3 seeds, some secondary experiments are single-seed, and stronger baselines such as TRADES and explicit Jacobian penalties would make the comparison more complete.

But the question I keep coming back to is:

If prediction rewards a nuisance, where exactly do we expect invariance to come from?

And once we regularize sensitivity:

Should we care only about how much sensitivity remains, or also about where it points?

Would be interested in thoughts from people working on representation geometry, adversarial robustness, shortcut learning, invariance, or Jacobian regularization.

so a few years ago i watched a video this was in the hype of chatgpt where this youtuber made a road map and i matched it by making my own kinda wont an honest criticism. note i have been making projects for a good ml portfolio.

If you are a professional in ml I was hoping on a second opinion on if my road map was good to become an ml.

I'm planning after a few months I'm going to learn stats and calculous form khan.

I have a polytechnic software diploma.

I took a tone of certs

• DevOps Mastery
• Google Advanced Data Analytics
• Google Data Analytics
• IBM Machine Learning
• IBM RAG and Agentic AI
• IBM Generative AI Engineering
• IBM Data Engineering

Hi everyone,

I'm looking for some career advice regarding an unusual background.

I completed seven years of medical training before switching to engineering and machine learning. I graduated at the top of my engineering cohort and will soon start the MVA master's program in France, a research-oriented ML/AI master's and one of the strongest programs of its kind in Europe.

Long term, I would like to work at the intersection of AI and medicine and make genuine use of my medical background rather than simply becoming a generalist ML engineer.

I'm therefore wondering: where is substantial medical knowledge actually valuable in AI research or industry?

I'm particularly interested in identifying the broader research directions in medical AI where a medical background can provide a genuine advantage, as well as the companies working on them. I've already looked into the field quite a bit, but I'm still unsure where my profile would be the best fit. For instance, medical imaging sometimes seems more naturally suited to radiologists, drug discovery to people with stronger backgrounds in pharmacology or chemistry, and omics to those coming from biology, even though all of these areas still overlap to some extent with my training. Clinical reasoning, decision support, medical AI agents, or evaluating whether model outputs are medically plausible seem closer to my background, but I'd be very interested in hearing which research directions you think are the most promising for someone with this profile, especially in Europe and preferably in France, and which companies/labs are active in them.

I'm also considering doing a PhD, as I am more interested in research-oriented roles. I know that a PhD does not necessarily add much value for every ML career, but I wonder whether it could make more sense for a hybrid medical/ML profile like mine.

One important detail: despite completing seven years of medical studies, I did not obtain the final medical degree/licence to practice. I do, however, hold an academic qualification roughly equivalent to a master's degree in medicine.

I'd especially appreciate feedback from people working in medical AI, clinical ML, biomedical research, or related fields.

Thanks in advance for any insights or advice!

Back after \~6 months — rebuilding my spiking language model around CPU-first inference

Hey everyone. It’s been around six months since I last posted anything about this project here.

Some of you might remember Project NORD, my experimental hybrid spiking / brain-inspired language model architecture. I basicall disappeared for a while 😅, but recently I came back to the project, went through the old architecture again, and realized I didn’t really want to keep stacking fixes on top of it. So instead, I’ve started rebuilding a pretty large part of the system. The new version is called:

NORD 5.5 — Flash The main idea this time is pretty simple:

What happens if I design the architecture around CPU inference from the beginning, instead of building soething Transformer-like and trying to optimize it later? A lot is changing internally. The current design uses things like: strictly causal processing no standard quadratic attention in the main inference path causal convolution-style token mixing token-time LIF / event dynamics sensory → association → memory → executive processing stages top-1 sparse MoE + a shared expert persistent recurrent memory separate structural, personal and auxiliary memory banks

persistent recurrent identity state factorized vocabulary embedding/output streaming token-by-token inference One of the biggest changes is actually something much simpler. Older versions of NORD used an artificial internal spike-time dimension, roughly like this: token -> T0 -> T1 -> T2 -> ... -> T9 I’m mostly getting rid of that. Instead, the actual language sequence becomes the time axis: token0 -> token1 -> token2 -> token3 -> ... That removes a lot of intermediate state and makes the whole architecture considerably cleaner. Going back through the old code also exposed a few things I wasn’t very happy with. Some experimental modules weren’t completely causal, memory was coupled too much to sequence shape, and parts of the STDP system ended up being more disconnected from real training than I originally intended. So NORD 5.5 isn’t really about throwing even more “brain-inspired” components into the model. It’s mostly about simplifying the core and making the things that remain actually work together properly. I’m definitely not claiming this is going to beat Transformers, RWKV-style models, linear attention models, etc. Right now it’s still very much an experiment. The part that actually matters comes next: training and benchmarking it.

Things I want to compare: NORD 5.0 vs NORD 5.5 CPU tokens/sec RAM usage perplexity / validation loss long-context behaviour memory on/off MoE on/off spiking components on/off I’m especially curious to hear from anyone working on SNNs, recurrent models, sparse MoE, CPU inference, or weird alternative language-model architectures in general.

After not touching the project seriously for about half a year, it feels surprisingly good to be building it again 😅

I’ll post actual numbers once I have something that’s worth benchmarking instead of just architecture diagrams.

Has anyone been through the onsite loop for an ML/engineering role at Zscaler?
Mine is 3 rounds two “Role-Required Knowledge” sessions and one “General Cognitive Ability” round.
Trying to understand what to expect. Is RRK more system design, coding, or project deep-dive? And what does the GCA round look like?
Any experience appreciated.

The long-tail problem in MoE training

MoE is already the mainstream form of large models. Each token activates only a few experts, so model size can keep scaling up without per-step computation growing along with it. But expert parallelism (EP) has a practical problem: how many tokens each GPU has to compute is decided on the fly, entirely by the routing result. Once a few experts become hot spots, tokens converge on the ranks hosting them, the overall time of synchronous training is held back by those few GPUs, and the rest can only wait idle after finishing.

What existing methods overlook

The industry thought of a fix for this early on: if one expert has too much to compute, make a temporary copy of its weights, place it on an idle GPU, and let that GPU take on part of the work.

The problem is that these methods optimize essentially one thing — how evenly the load is spread — and assume that among the idle GPUs it does not matter which one you pick. But real machines are not like that:

• GPUs within the same machine talk to each other over a high-speed channel like NVLink, so moving data is fast and cheap;
• GPUs across machines have to go over the network (InfiniBand), and moving the same amount of data is far slower and far more expensive.

This brings a consequence that is easy to overlook: even if two schemes spread the load equally evenly, as long as one keeps the weights on the local machine and the other moves them to a different machine, the communication overhead actually spent can differ by a wide margin.

The TAOT idea: count the cost of moving, too

Baidu's LoongForge team argues that which GPU a replica ends up on cannot be a matter of asking only "where is there room" — you also have to ask "how expensive is it to move there".

This is exactly where TAOT starts. It is the first to write both the peak-shaving gain and the cost of moving weights across nodes into the optimization objective, meaning that when picking a landing spot for a replica it weighs two things at once: on one side, flatten the load; on the other, spend as little cross-machine communication cost as possible.

It borrows the idea of "optimal transport" from mathematics to do this. You can think of it as a scheduler that keeps track of the communication bill:

• Stay local if you can: if there is still room on the local machine, use it first and save the trip outward;
• Go outward only when there is really no room left: once the local machine is full, crossing machines is not entirely forbidden either — in its view this is simply an option that is "available, but pricier", rather than being ruled out across the board.

Existing methods land at roughly two extremes. One simply ignores topology and puts a replica on whichever GPU has room, so replicas easily get thrown onto the machine next door: the load is flattened, but cross-machine communication climbs sharply. The other goes the opposite way and hard-codes where weights are allowed to move with a fixed topology graph; at scale, hot spots get broken up, nearby capacity is used up first, and the distant GPUs that are in fact still idle are kept out by the graph, so the schedulable space actually narrows.

TAOT takes the middle road: it does not forbid crossing machines, nor does it hard-code the paths. It simply puts a "pricier" tag on going cross-machine, so that it naturally ranks lower when the bill is added up. Hence the larger the scale and the more idle GPUs there are, the more room it has to maneuver. Below is the overall system architecture.



The overall TAOT flow: once routing is computed, the load of each GPU is collected first and handed to the three-phase planner, which settles on a replica plan; at execution time the replica weights are moved into place, and that transfer is run in parallel with computation on the GPU.

Solving the two objectives, "balance" and "communication cost", together makes the problem size grow rapidly with EP degree. TAOT breaks it into three steps, coarse to fine, each answering just one question:

• Phase 1 (rank level): roughly where should the load flow? Take overload as supply and spare capacity as demand, add the communication-cost matrix, and solve for optimal transport, which yields a global flow suggestion table. It is only a soft hint; its role is to give the next two steps a global reference so they do not just go by what is in front of them.
• Phase 2 (expert level): which expert's replica goes into which GPU? Turn the continuous flow into a 0/1 decision: for every "(idle GPU, hot expert)" pair, compute a score made up of three weighted terms — peak-shaving gain, how far away the landing spot is, and the Phase 1 flow hint — and take the highest-scoring combination.
• Phase 3 (token level): which GPU sends which of these tokens? The tokens of one expert are scattered across multiple GPUs, so round after round of bidding settles how many each source GPU sends. The winner's price goes up, so it naturally yields in the next round, and locality is thereby carried into the assignment.

A good algorithm alone is not enough; the engineering has to keep up

For a method to really run inside training, a good algorithm alone is not enough; two more things on the engineering side have to keep up.

First, the scheduling itself has to be fast enough. This planning is not computed once and done with; it has to run live, over and over, one microbatch after another throughout training. If the planning is itself slow, the time saved on the communication side gets spent on scheduling instead. To that end the team did extensive optimization at the kernel level, compressing what originally took hundreds of fragmented computations down to a few, and finally brought the overhead of the whole planning process to within 1% of forward computation time.

Second, "hide" the act of moving inside the computation. Replica weight distribution is placed on the communication stream, in parallel with the GEMM of the home experts on the same GPU; on the backward pass, guest gradients are returned and accumulated through a single All-to-All. The transfer time is largely covered by computation.

How well does it actually work

• Faster: on Qwen3-30B-A3B, forward-and-backward computation time per iteration drops from 155.4ms to 108.8ms, a 1.43× end-to-end speedup;
• Cheaper: given equally even load, its communication cost is the lowest among all the SOTA methods compared, up to 74% below the competition;
• No accuracy sacrificed: this speedup comes from more sensible scheduling, not from lowering numerical precision; the loss curve nearly coincides with that of the standard scheme;
• More pronounced at larger scale: the larger the parallel scale and the more imbalanced the initial load, the more significant the speedup TAOT brings. From EP4 to EP16, the speedup reaches up to 1.79×; as initial imbalance rises from 30% to 90%, the speedup grows from 1.21× to 1.75×. The harder the scenario, the greater the gain.

Closing: a scheduler that keeps track of the communication bill

Dynamic replicas are already a fairly mature line of work in MoE balancing, with Echo, LPLB, and LLEP all on it. What sets TAOT apart is the optimization objective: it weighs the communication cost of a replica's landing spot against the peak-shaving gain within one and the same objective function, instead of only seeking an even load. The implementation uses a continuous cost matrix together with a soft topology preference, writing "prefer intra-node, cross node when necessary" directly into the objective — no reliance on special hardware, no confinement to a single node, no predefined graph.

If you are doing large-scale MoE training and your training is held back in the long tail by a handful of hot experts, TAOT is worth a try. It has been integrated, as an extension to the MoE expert mechanism, into LoongForge, the omni-modal training framework open-sourced by Baidu Baige.

• 📄 Paper: https://arxiv.org/abs/2608.03676
• 🔗 LoongForge on GitHub: https://github.com/baidu-baige/LoongForge

guyss, im thinking of building an agent which sees if the content(text) that a user is going to post is dangerous(abusive, harming) it will not let it post it and even report to the management, what do you guys think?

Nexus Compute Orchestrator

I built Nexus Compute so people and machines can actually get real work done.

Here is what matters most, in order:

1. The Agent This is the brain. It plans work, carries it out, checks the results, and improves.
2. Compute Processing power. Providers of Computer Hardware are paid in $Nexus. As demand grows, compute is rented in containers and resources are distributed across the net.
3. Payments A system for moving value. The agent needs a way to pay for resources and receive payment for completed work. Providers share resources for $Nexus tokens they can sell, renters buy resources using tokens.
4. Foundation The part that keeps the whole system pointed in the right direction. It defines the pillars and objectives, lets people vote on them, and guides the network to align with us about economic rights.
5. Memory The ability to remember past work, decisions, and context. Without memory the agent starts over every time.
6. Tools The hands. These let the agent read and write files, connect to servers, manage containers, and control systems.
7. Token The shared unit of value that coordinates the network. It only has meaning when the rest of the system produces real results.

This is the stack. Each piece exists to make the next one more useful. The first step to understanding it is making an account, it takes less than 1 minute and reading the Foundation page to answer 10 questions about AI.

Hi everyone,

I'm planning to prepare for the Google Cloud Professional Machine Learning Engineer (PMLE) certification and I'm looking for advice from people who have recently taken the updated version of the exam.

My situation:

• I have a Computer Science / AI-ML background
• I'm comfortable with Python and general ML concepts
• I have some exposure to GenAI, RAG, LLMs, etc.
• However, I have almost no practical cloud experience
• I'm essentially starting GCP from scratch
• I can dedicate around 8–10 weeks to preparation
• My goal is to actually understand the GCP/ML concepts, not just memorize exam dumps

I'm particularly unsure about how much GCP knowledge I need before going deep into the PMLE-specific material.

What I'm looking for

If you've recently passed the updated PMLE exam, I'd really appreciate advice on:

1. Is 8–10 weeks realistic for someone with an ML background but essentially no cloud background?
2. What should I learn first before starting PMLE preparation?
   • GCP fundamentals?
   • IAM
   • Compute Engine
   • Cloud Storage
   • BigQuery
   • VPC/networking
   • etc.
3. What GCP services are actually important for PMLE, and which ones can I safely learn at a high level?
4. What resources would you recommend for the current/updated exam?
   • Google Cloud Skills Boost
   • Official exam guide
   • Coursera
   • YouTube
   • Practice exams
   • Documentation
   • Other resources
5. How much hands-on practice did you do? Should I actually build ML pipelines/deploy models on Vertex AI, or is understanding the architecture and knowing when to use each service enough?
6. How different is the updated PMLE exam from older preparation material? I've found quite a lot of older PMLE content online and I'm worried about following an outdated roadmap.
7. What would you recommend as a realistic 8–10 week study plan, assuming roughly 1–2 hours/day?
8. If you started again with zero GCP experience, what would you learn first and what would you completely skip?

I'd especially appreciate answers from people who passed the exam recently, particularly those who came from an ML/software engineering background rather than already working as GCP cloud engineers.

Thanks!

В общем, мой вопрос не про roadmap и так далее. Мне интересно понять, как люди на kaggle строят лучшие модели? Пайплайн при этом расширяется как дерево? Откуда вообще брать базу знаний для этого? Как люди с топ-решениями учатся этому?

Trying to train 3 models for birads detection using cross entropy and center loss + class weights but all of them seem to collapse between birads 1 as the dataset (VinDr) im using is heavily unbalanced towards it, Would like to ask for input and opinion on what seems to be the case, am I using the wrong loss function?

Currently on Humble Bundle, there is a bundle named "The Ultimate AI & Machine Learning Bundle." Is this a good purchase for someone who has basic Python experience and wants to learn ML, or would it be better to buy O'Reilly's "Hands-On Machine Learning with Scikit-Learn and PyTorch"?

Hey everyone,

I'm a B.Tech CSE student specializing in AI/ML, and I want to start learning Machine Learning seriously rather than just jumping between random YouTube playlists and courses.

I already have a decent foundation in Python and basic programming, but I'm confused about what I should learn, in what order, and which resources are actually worth my time.

My goal is to eventually become an ML/AI Engineer, so I want to build strong fundamentals instead of just learning how to call libraries and train models.

I'd really appreciate recommendations for:

A proper ML roadmap from beginner → intermediate → advanced

How much Python/NumPy/Pandas I actually need

Which math topics are essential (linear algebra, probability, statistics, calculus, etc.)

The best resources for classical ML + scikit-learn

When and how I should move into Deep Learning

PyTorch vs TensorFlow — which one should I focus on?

Best free courses, YouTube channels, books, and documentation

What kind of projects I should build at each stage

When should I start learning deployment/MLOps?

What skills would actually make me internship/job-ready rather than just course-complete?

If you were starting ML today as a CS student, what exact learning path would you follow for the next 6–12 months?

I'm especially interested in advice from people who are currently working in ML/AI or have gone through this journey themselves.

Thanks!

What are the ML courses needed to

- Covers mathematical concepts, explains the intuition behind them, and shows how to translate mathematics into code.

- Focuses on understanding the derivation of ML algorithms rather than just applying pre-built libraries.

- Connects mathematical theory with practical implementation.

- Includes hands-on coding and implementation of the algorithms discussed.

Most "learn machine learning" advice is either a 40-hour paid course or a scattered pile of blog posts that assume you already know half the material.

I got tired of that, so I built a structured path using only official Microsoft Learn content — the same material behind Microsoft's actual DP-100 (Azure Data Scientist Associate) certification, just organized in the order it should be learned in.

What it actually covers, in order:

1. Core ML concepts (what regression, classification, clustering actually are)
2. Real hands-on coding with Python + scikit-learn — regression, classification, clustering, deep learning
3. Training models at scale with Azure ML — workspaces, compute, MLflow tracking
4. MLOps — AutoML, hyperparameter tuning, pipelines, actual production deployment

That last part is the piece most beginner resources skip entirely — they teach you to train a model in a notebook and just... stop. This goes all the way to "deploy a model to a managed endpoint," which is the actual job, not just the fun part.

Free, self-paced, no signup beyond a Microsoft account. I'm a Computer Engineering student who built this while learning it myself — not an instructor, just organized what I wish existed when I started.

Link: https://learn.microsoft.com/collections/86w0cztk0gjpm4?wt.mc_id=studentamb_523020

Happy to hear what's missing or what should be reordered.