c/artificial-intelligence

I'm an 18-year-old independent student from Tunisia. I built and I'm leading an open, from-scratch machine-translation pipeline and parallel corpus for Tunisian Darija. Sharing it for feedback. Why: Tunisian Darija, written in Arabizi (Latin letters + numerals like 3/7/9/5 for Arabic phonemes), has almost no open NLP resources. Existing Arabic tools route it through MSA and mishandle the orthography. To the best of my knowledge there was no open parallel corpus or from-scratch baseline for it. What I built (all open): - Arabizi-aware SentencePiece BPE tokenizer (3/7/9/5 as protected symbols), shared 16k vocab. - ~15.6M-param encoder–decoder Transformer, from scratch (no pretrained LM): transfer-learned from cleaned Moroccan Darija, then fine-tuned on hand-crafted Tunisian pairs. - Full cleaning / training / eval pipeline. Honest results & limitations: v1 BLEU is 3.89 on a small locked test set low, and I'll be upfront about it. The corpus is ~553 hand-crafted pairs, so data is the bottleneck, not architecture. I treat 3.89 as a first honest baseline to beat as the corpus grows. Where I'm taking it: I'm expanding this into a larger, ethically-collected Darija corpus that I curate and validate consent-documented field collection, every pair provenance-tagged. I'm looking for contributors to help grow it, with every contribution reviewed to keep quality and consent standards. Looking for: technical feedback/critique, and anyone interested in contributing data or collaborating on low-resource / dialectal Arabic MT. Links: github repo: https://github.com/Dhiadev-tn/darija-translator Hugging faces dataset: https://huggingface.co/datasets/Dhiadev-tn/tunisian-darija-english hugging faces model: https://huggingface.co/Dhiadev-tn/darija-translator submitted by /u/Dhiadev-tn [link] [Kommentare]

I am a scientist who just applied machine learning to my research (JEPA/Representation/Geometric branch) and it did wonder! Allowed me to see so many papers that I am still struggling to write up. From what I see, there are clearly a million possibilities not done yet, e.g., industrial data, patterns in nature, etc. Why is the job perspective so pessimistic? We clearly have problems unsolved, and for many, the potential of ML will be proven for sure. We also have money (according to the news), and then why are jobs almost impossible? submitted by /u/nebula7293 [link] [Kommentare]

Hi. I have a question, could this plan and pipeline work?. I will be attending university master's classes on AI (thankfully got accepted a few days ago) and computers in a few months. There will be university lectures on machine learning, computer vision, robotics, video games and AI etc, i wanted to take notes using my laptop instead of the classical approach of pen and paper. i have a 500$ hp laptop (it doesnt have touch screen though so it's screen is not reactive) and chatgpt proposed i install Xournal++ and also get a Huion H640P graphics tablet that i plug to the laptop and i will be writting with the pen/screen of Huion H640P. chatgpt proposed the Huion graphics tablet/pen because it is hard to write and especially draw grapghs/plot on a laptop using the mouse only so a pen would be better. it said i could just plug the Huion pen to the laptop and with it i could write directly on Xournal++. Looking forward to your thoughts. Im tired of the usual pen and paper approach to taking notes. i want to make the process digital and since i have this good laptop why not use it? after all i bought it 2 years ago solely for university and work use. submitted by /u/AncientGearAI [link] [Kommentare]

Has anyone gotten a response from the eccv travel support program listed on their website? https://eccv.ecva.net/Conferences/2026/DEI Edit: also have anyone applied for this program as an accepted author? I have an independent research paper accepted and am currently looking for funds for paying for the registration fees submitted by /u/tedd235 [link] [Kommentare]

I made a 10MB LoRA adapter for Qwen3.5-4B plus a small orchestration layer. It decides, per query, whether to answer directly, search the web, or retrieve from your own local documents and it refuses to make things up when it can't verify an answer. It runs locally (Apple Silicon / MLX, with a GGUF build for llama.cpp/Ollama). Basically small instruct models are poor at telling users how confident they really are. They can't verbalise it and tend to say they are confident for everyhting. In my past research I tested seven 3-9b models and they all hit a confidence ceiling. But the information is there in the internal activations. The adapter reads the internal signal directly and gates tool use on it. The main elements are that: - it catches its own errors better than the base model's tool calling (d′ improvement of 0.46 (95% CI [0.01, 0.89])). Of the cases the gate flagged that the base model didn't, 87% were genuinely wrong answers. - it is less likely to leak your private queries to public search. A two-signal version routes personal information related questions such as "what did my discharge summary say" to a local retriever instead of a websearch. It cut the rate of private questions sent to public search from 22% to 10% (reduction 0.12, 95% CI [0.02, 0.22]). This is useful for those who are using the LLM for confidential docs. - every answer is traceable. When it retrieves, it cites the specific passage (report.md ¶2), verifies the answer is actually in that passage, and shows a confidence band. Worst case, it says "I couldn't verify that". It is built to say "I don't know," instead of lie. limitations: - Privacy result is n=60; the retrieval/competence dissociation is n=126 hand-authored items. Screened and CI'd, but small. - GGUF reproduces the MLX gate's decisions at --lora-scaled ...:8 (found by sweep — scale 1 does nothing; effective scale ≈ the training scale). Agreement 0.83 on a 24-item probe; disagreements are all conservative-direction (GGUF answers a couple of borderline items MLX would look up), and knowns never false-fire. Faithful on the safety-critical directions, marginally more conservative at the margin. - Serve-time confidence is coarse (grounded / declined / answered) — the distilled gate reads nothing at inference, so finer bands need probe access (offline). - Inherits Qwen3.5-4B's knowledge and biases. The gate governs when to trust the model, not what it knows. The approach isn't Qwen-specific — I started on SmolLM3-3B, and it should extend to other models and larger sizes. Repo (weights + code + model card): https://huggingface.co/synthiumjp/competence-gate-qwen3.5-4b Apache-2.0. It's an open research release. I hope people might find some use for it. Methodology and papers are cited in the model card. Genuinely interested in critique, it's screened work, so if there are any issues it be great to know. submitted by /u/Synthium- [link] [Kommentare]

Built a visual editor that validates tensor shapes, counts params, estimates FLOPs/VRAM while you design. Catches incompatible residuals, mismatched Linear layers, all that before you waste GPU time. 63 ops. Proper shape inference. Exports PyTorch code that actually runs. URL- tensey.vercel.app Github- github.com/aarocy/tensey – MIT licensed. submitted by /u/uselessfuh [link] [Kommentare]

As someone who is not affiliated with any of the big tech companies, I find it particularly difficult to have the confidence or enthusiasm to approach any ML problem with an attitude that my professors probably had at my stage in life. I'm sure I am not the only one having the following thoughts: "My research is currently being done better at companies." "ML problem I set out to solve is already solved and in fact turned into products and sold for millions at companies X, Y, Z. There is no need for further research." "Industry is not interested in theoretical ideas and there is plenty of evidence for that, starting with their hiring practice." "Companies wouldn't have millions of dollars in funding or revenues if their models weren't working." "Research is like Darwinian evolution. Evolution aims to produce the fittest model. After decades of evolution, the fittest model is already in industry, why should I explore other evolutionary dead-ends?" "There may not be a next big thing after LLM. If there were, it would be simply incorporated as a function or a subroutine that LLM simply calls when needed, and the average person would be none the wiser. My contribution would be invisible." Seems like research outside of big tech companies is pointless (unless you are a prof who is making big $$ while doing it). Because whatever they are working on might be lightyears ahead of whatever you are doing, but you wouldn't know because their model is simultaneously closed-source and omnipotent. There are tons of people sharing their resumes on other ML/CS subreddits and occasionally you see that their projects are along the lines of "linear regression for Titanic dataset" or "YOLO for pedestrian detection" and they are wondering out loud why nobody is hiring them. Everyone with more ML experience can see because there is zero need for people with this skillset. But what if my very research also looks the same to people in industry? What if my "deep geometric autoencoding variational neural-former" also looks like some silly Kaggle project because industry can already do that much more efficiently? How do you silence these thoughts? submitted by /u/NeighborhoodFatCat [link] [Kommentare]

I spent the last few months building a new sparse fine-tuning method for MoE models called **USAF**. The goal was simple: if your GPU can run inference on an MoE model, it should also be able to fine-tune it. On my AMD RX 6750 XT (12 GB), I can fine-tune Qwen3-30B-A3B by training sparse expert weights and the router instead of adapters. The project is completely open source under the Apache 2.0 license. I'm not trying to build a business, sell anything, or monetize it in any way—I just wanted to share something I built that I think is genuinely interesting. I'd love to hear your feedback, especially from people working with MoE models. GitHub: https://github.com/tsuyu122/usaf submitted by /u/tsuyu122 [link] [Kommentare]

We run HexGrid Cloud, a platform for deploying open-source models on GPUs, and we're heads-down optimizing our serving/deployment layer. To pressure-test it we're benchmarking real models under real concurrency — and instead of guessing, we'd rather run what you actually want to see. --- Models available for benchmarking: Nemotron-3 Super 120B-A12B (only NVFP4) Nemotron-3 Nano 30B A3B Qwen-3.6 27B Llama 3.3 70B Instruct Gemma-4 31B Devstral-Small-2-24B-Instruct-2512 ?? (you suggest a model to us) We're focused on chat/instruct models for now (that's what most of our users deploy), so pick one from the list above — or suggest another open-weight chat model that fits on a single H200 (141GB). --- Hardware & quant choices: GPU (up to H200 for this round): RTX PRO 6000 · L40S · H100 · H200 Quant: FP8 / AWQ / BF16 Context length: (8K, 32K, 64K, 128K) What you want measured: max throughput? single-stream speed? long-context prefill? --- We'll run the top picks and post full results — tokens/sec, TTFT, TPOT, throughput under concurrency, and cost-per-million-tokens — config and flags included so it's reproducible. Let us know in comments. submitted by /u/Temporary-Owl1725 [link] [Kommentare]

This article contains real world patterns you can use to minimize your API/Agent costs (without major refactoring). Instead of just glazing over routing, it provides a real world example of routing with a pretrained classifier and an actual routing table which works! It also provides a recipe for training your own prompt classification model. Use this for cost reductions of up to 60%. Stop tokenmaxxing. Start tokenminning. submitted by /u/Nice-Dragonfly-4823 [link] [Kommentare]

I've been trying to come up with a solution for keeping extremely long ai sessions coherent. Sometimes there is too much substance to risk compaction. With so much buzz around diffusion going on it got me thinking, what if we treat the context like a progressive render, blurry>sharp. The practical way to make text "blurry" is compression. This is a "diffusion inspired" system which borrows the coarse-to-fine process, not the formal math. It uses semantic compression so the overall structure of the session stays intact. Read the compressed version first to build an outline. Then read progressively less compressed slices until you're reading small verbatim chunks that give full detail. So you're basically using compression as noise on the input side, then progressively building an output. Each slice is compressed to fit within the context window, so the model only ever needs to read the current slice+input+current output. Tell the model what pass it's on, so it knows whether to write an outline or add detail. The thing I'm actually trying to preserve is what you'd call "non-local information". Think of it as stuff that surfaces when looking at the whole session & doesn't survive fragmented retrieval. Retrieval misses it, compaction deletes it. Both miss what only exists in a holistic view. Here is a visual demonstration to get a general idea of the workflow. https://dev-boz.github.io/diffusive-semantic-compression/demo/architecture-demo.html There is substantial overlap with lots of prior art, Recursive Language Models is one of the closest (source and output on disk, process recursively). I wrote most of this before I found RLM and nearly gave up before realising there was still a small part that was novel. As far as I can tell there's no exact match for this particular implementation. Please let me know if I've missed one. The difference to regular masked diffusion is in changing the length of the input rather than just masking. What seems to be new ground is using compression as noise and a position-aware process. I've done some basic testing. Mainly to see if it was at all viable. Just some basic tests using small models like Qwen2.5 7B. The untrained models show that they can do each part (outline, refine, add detail) but they struggle with the full end-to-end process. There 's occasional end-to-end success, but it's nowhere near reliable. On untrained models it also hasn't yet beaten a cheap dense read of the same document. The main bet is whether position-aware training changes that, I haven't been able to test that yet. I've published all the pre-registered failures, parser bugs I found etc. Another note: the goal is preserving structure and nuance, but the tests so far measure planted facts and split-up numeric composition. Mainly because the experiments needed answers you can actually score. The nuance evaluation is being designed but isn't ready yet. The next step is a small model fine tune to test if position aware training can help. If you have the time to look at the idea, it really needs a prior art check from anyone who knows the diffusion-LM/long-context space. And if anyone wanted to help expand the idea or contribute with compute or collaboration for the fine-tune please do. Here is the repo for the proposal. Links to testing repo and prior art inside. https://github.com/dev-boz/diffusive-semantic-compression submitted by /u/Bravo_Oscar_Zulu [link] [Kommentare]

Instead of node --edge--> node, every relationship is a first-class document with its own vector, called a BaryEdge. Stack pairs of BaryEdges recursively and you get "MetaBary" triads that surface structural bridges between concepts that live nowhere near each other in embedding space. Running locally on MongoDB Community + mongot + nomic-embed-text over the full English Wiktionary (6.6M docs). MCP server is live if you want to poke at it. Preprint + benchmark CSVs: https://zenodo.org/records/20186500 The problem I was chasing Flat vector search treats a relationship as a byproduct of two points being close. That throws away information. Two papers can describe the same underlying phenomenon (a flyby anomaly in orbital mechanics, an anomalous residual in stellar dynamics) without ever citing each other and without their embeddings landing anywhere near each other. Nothing in standard RAG surfaces that connection. What I did instead Every relationship gets embedded too: bary_vector = normalize(q·v(CM1) + q·v(CM2) + (1−q)·v(type)) q is connection quality, v(type) is a contextual embedding of what kind of relationship it is. This BaryEdge is now a retrievable document in its own right — not metadata on an edge. Then it recurses: two BaryEdges at the same level get bridged by a third one level below, forming a MetaBary triad. Do that repeatedly and you climb an abstraction triads hierarchy built entirely from algebra — zero additional embedding calls above the base level. It's a forest (every node has at most one parent), so traversal to root is a single $graphLookup, no cycle handling. Does it actually do anything useful? Ran it against SimLex-999 and WordSim-353 as a sanity check (not the main claim, just "is the substrate coherent"). Raw cosine similarity barely correlates with human similarity judgments (ρ ≈ −0.04 on SimLex). Structural metrics — how many BaryEdges two words share, how much their relational neighborhoods overlap — correlate at ρ ≈ 0.32–0.53, p < 10⁻¹⁵. So the graph is encoding something cosine alone doesn't. The part I actually care about is cross-domain bridging. Some probe traces from the live graph: octopus neuroscience ↔ distributed sensor networks, bridged by shared structural-motif vocabulary (neuroarchitecture, smartdust) collagen folding ↔ linguistic syntax, bridged by etymological + structural motif overlap (plicature / hypotaxis-parataxis) grief ↔ depression, not bridged and this is a correctness demonstration, not a missing capability. The DSM-5 added a much-debated "bereavement exclusion" precisely because grief and depression share surface symptoms but are different kinds of state, with different prognosis and treatment radioactive decay ↔ obsolete words falling out of use, bridged at a high abstraction level by register-varied decay verbs (collapsed, decayed, declined, disintegrated) — naming a Poisson-process state-loss pattern that both physics and historical linguistics instantiate, with no single word doing the work That last one is the case flat retrieval structurally cannot produce — there's no embedding axis for "verbs co-occurring with reduction-of-state across unrelated domains." Stack (all local, all free) GitHub: https://github.com/oleksiy-perepelytsya/bary-vector MongoDB Community Edition + mongot for storage/vector search nomic-embed-text, 768-dim Python 3.11+ Full build: ~6.66M documents, 8–14 hrs on a single workstation (8–16GB VRAM) Try it MCP server is public on request (SSE transport) — read-only tools for searching the live graph: find_word, semantic_search, edge_info, leaf_nodes, traverse_up, sample_metabary. If you've got an MCP-capable client you can point it at the graph and run your own probe queries in a few minutes. What I'd actually want feedback on Whether the cross-domain bridges hold up to someone who isn't me poking at them — try a probe query on a domain pair you know well and tell me if the bridge is real or if I'm pattern-matching myself into seeing structure that isn't there. Some bridges can be not obvious on the first look but they are actually the most intriguing ones and worth to be dug for the reason they built, so treat them as points of investigation Whether this is worth comparing directly against GraphRAG/RAPTOR-style hierarchical retrieval (I haven't done that benchmark yet, and I know that's the first thing this sub will ask) Whether anyone's tried something structurally similar and it fell apart at scale for reasons I haven't hit yet Preprint, architecture spec, and the raw SimLex/WordSim CSVs are all here: https://zenodo.org/records/20186500 Happy to drop the MCP endpoint on request if there's interest. submitted by /u/adseipsum [link] [Kommentare]

Today I put out my first flow matching image generation model! This is a toy example trained on a 2024 MPS Macbook Pro using a small sample of images—specifically, the Apple emoji library and their text labels. Because of this, it’s not a massive model (clocking in at ~4.7 million parameters), but it was an incredible learning experience. My original approach (which failed): I initially tried taking the emoji images, converting them to grayscale, and using an extremely basic CNN to expand the gray channels into 64 feature maps. I applied a ReLU activation, repeated this three times, and then coalesced back into a single layer to get the final theta prediction of the velocity field. I coupled this with CLIP word vector embeddings (run across the official Apple emoji descriptions) and a simple time encoding for interpolating between the noise vector field (x_0) and the target image vector field (x_1) to find the state at time t. This approach wasn't expressive enough for the model to actually learn to predict the velocity field, especially since I was using float32 to keep the model lightweight. The Pivot (What worked): To fix this, I switched to using full RGB channels instead of grayscale, implemented residual blocks, and added self/cross-attention. I also increased the feature channels to allow the network to retain more information about the emojis themselves. This worked much better. When predicting a velocity field for emojis, color is an incredibly important heuristic, and having more capacity allowed the text embeddings to form a much more meaningful relationship with the visual features during inference. The model is completely free to play around with here: https://emoji-generator-69.web.app/ submitted by /u/SedateTheApe [link] [Kommentare]

Thinking about getting two months at his website and getting a stronger understanding of machine learning since I am building tools with ai models from hugging face. Have anyone tried it? submitted by /u/TheSmashingChamp [link] [Kommentare]

Hi everyone, I built H64LM, a research project to better understand modern LLMs by implementing one from scratch in PyTorch. Instead of relying on high-level training frameworks, I implemented the core components myself attention, MoE routing, normalization, and the training loop. Features 249M-parameter Transformer Grouped Query Attention (GQA) Sparse Mixture-of-Experts (8 experts, Top-2 routing) with 3 auxiliary routing losses SwiGLU, RoPE, RMSNorm Sliding-window attention Mixed-precision training, gradient accumulation Custom training loop (no Trainer abstractions) Checkpointing and resume support The included checkpoint was trained on a subset of WikiText-103 to validate the pipeline end-to-end, not to be a strong model it's visibly overfit past epoch 10 (best val PPL ~40.5). Known limitations are documented in the README, including batch-size-1-only generation and no true DDP (falls back to DataParallel). GitHub: https://github.com/Haiderkhan64/H64LM Feedback on the implementation or architecture is very welcome. submitted by /u/Loose_Literature6090 [link] [Kommentare]