c/artificial-intelligence

Please post your personal projects, startups, product placements, collaboration needs, blogs etc. Please mention the payment and pricing requirements for products and services. Please do not post link shorteners, link aggregator websites , or auto-subscribe links. -- Any abuse of trust will lead to bans. Encourage others who create new posts for questions to post here instead! Thread will stay alive until next one so keep posting after the date in the title. -- Meta: This is an experiment. If the community doesnt like this, we will cancel it. This is to encourage those in the community to promote their work by not spamming the main threads. submitted by /u/AutoModerator [link] [Kommentare]

https://www.gnosyslabs.com/case-studies/safety-classifier-sparse-labels Gnosys is an autonomous model engineer: it improves prompts and classifiers when ground truth is too sparse for conventional optimization. On ToxicChat, a public safety benchmark, under realistic label scarcity, it improved a classifier past both the team's starting point and GEPA (a standard prompt optimizer), across two runs of our current method. This note describes what we did, what we found, and where the method underperformed. Results We report harm caught: the share of harmful messages flagged, holding the false positive rate fixed at 5% (one in twenty) for every method, so a difference reflects additional harm caught at the same cost rather than a change of threshold. Both runs below are scored on a held-out set the system never saw. Headline run (3,000) Prior run (1,000) Gnosys 0.777 0.909 Starting classifier 0.731 0.788 GEPA 0.702 0.848 In both runs, Gnosys improved on both the starting classifier and GEPA. In the headline run GEPA not only trailed Gnosys but fell below the starting classifier (0.731 to 0.702); in the prior run it improved on the starting point. This inconsistency is the central difficulty under sparse labels: optimization sometimes helps and sometimes harms, and without trustworthy measurement there is no way to tell which has happened. The comparison is intentionally conservative: both approaches use the same underlying optimizer. The only difference is that Gnosys engineers the objective the optimizer works against. The problem Teams running high-stakes AI classifiers, in content moderation, fraud, claims review, and risk scoring, share one constraint: the ground truth they need is a human judgment that is expensive, slow, and sometimes never arrives. They can verify only a small set of examples while decisions accumulate on everything else. Tuning the model against the few labels on hand is where the difficulty concentrates. Here "few" is literal: about 200 verified labels, of which roughly 8 were actual harm, against several thousand unlabeled messages. With that little verified signal, an optimizer fits the noise in those examples rather than the underlying pattern, and the direction it moves depends on which handful of labels it happened to receive. How Gnosys is different GEPA improves whatever evaluation signal it is given. That is its job, it does it well, and Gnosys uses it. But Gnosys goes further. As an autonomous model engineer it judges whether the available signal is trustworthy enough to optimize against, engineers a better objective from the sparse labels when it is not, and rewrites the prompts and classifier against that objective. Prompt optimization is one step in the loop. Gnosys automates the entire engineering cycle. Rather than trusting a handful of labels directly, Gnosys fuses the small verified set with the large unlabeled pool into a calibrated estimate of quality, with per-slice calibration and an explicit check that flags when the signal is not trustworthy enough to act on. In both runs, optimizing against that calibrated objective improved on both the starting classifier and GEPA using the same labels. The evidence, slice by slice The figures below are computed against the held-out test labels, full ground truth a deployment would not have. They are point estimates on small positive subsets, so we report the count alongside each, and they are not estimates the system produced from the sparse labels. Because a single aggregate can hide a regression within a category of interest, we report every slice, including losses. All figures compare Gnosys against GEPA on the headline run. By message length (a complete split of the test set): Length Harmful examples vs. GEPA Short (under ~80 characters) 81 −18.5 pts Medium 51 +21.6 pts Long / multi-step (200+ characters) 106 +20.8 pts By harmful-content category (a safety team's working slices): Category Harmful examples vs. GEPA Violence-related 21 +23.8 pts Jailbreak attempts (independently verified) 49 +8.2 pts Sexual content 63 −7.9 pts The gains concentrated where judging the content requires the most reasoning: violent intent, deliberate jailbreaks, and longer multi-step messages, where thin labels leave a standard model guessing. Two slices moved the other way, for different reasons. Short messages, the largest slice, were not a model failure: Gnosys ranks short-form harm at least as well as GEPA. The lower recall is the operating point doing its job. Under a single false positive budget the aggregate-optimal threshold pools alarms where harm is densest, which is longer messages. Setting a budget per segment lifts short-message recall to about 0.90 but lowers the aggregate from 0.78 to 0.71. Sexual content was a genuine limitation: on this small slice (63 harmful of 77 messages) the model ranked worse, and a slice-local threshold would not recover it. These regressions suggest clear directions for future optimization, and are precisely the kinds of slice-level failures the system is designed to expose before deployment. (Hate speech and coding-related had only 3 and 6 harmful examples on this run, too few to estimate, so we exclude them.) Where it goes We chose safety because ToxicChat is a clean, external, high-stakes benchmark, but the method is not safety-specific. The same constraint, optimizing a model when the truth you would optimize against is scarce, expensive, or delayed, recurs in fraud detection, claims adjudication, compliance review, credit and risk scoring, support routing, and recommendation. Across these domains the job is the same: engineer a trustworthy objective, improve the model against it, validate the result, and repeat. That is what Gnosys automates. Methodology. Results are on ToxicChat, a public safety benchmark, scored on held-out data the system never saw, with the false positive rate held fixed at 5%. The calibration and test sets are disjoint, and exact-duplicate messages are removed across splits so calibration data cannot leak into evaluation. Both three-way results are single-seed and among the earliest runs of the current system: the headline run on a 3,000-message held-out set (0.731 / 0.702 / 0.777) and a separate run on a 1,000-message split (0.788 / 0.848 / 0.909). Multi-seed trials to attach confidence intervals are in progress. Slice-level numbers compare Gnosys against GEPA on the headline run and include every slice with enough positives to estimate; counts are shown because at these sizes the figures are directional. submitted by /u/Kody--- [link] [Kommentare]

This is a write-up on our company blog that I wrote, sharing our perspective into Hamiltonian Neural Networks (Greydanus et al., 2019) from a differential-geometry angle rather than the usual "here's the loss function" treatment. I've been working on HNN and LNN adjacent topics for years now and I found this particular lens made the *why* click in a way the standard framing never did for me, and I've been meaning to put everything in writing for a while now. I just feel like the Noether's Theorem which shows conservations can be mapped to symmetries (and in ML context, generalization) is not getting the attention that it deserves around physics informed neural networks. Also, it's a really beautiful architecture and I just love talking about it at every opportunity. It's math-heavy, but I did my best to sprinkle some tension relievers and interactive visuals here and there and make is as easy as it is to follow. Hopefully, I did a good job. I'd genuinely love to see your thoughts and your feedback submitted by /u/FlameOfIgnis [link] [Kommentare]

https://pymupdf.io/blog/markdown-in-pymupdf-1-28 PyMuPDF 1.28 release, introduces Markdown as a first class document in PyMuPDF. Seems useful for a variety of workflows. You can create PDFs from Markdown text with control over appearance using CSS submitted by /u/Remote-Spirit526 [link] [Kommentare]

Hello, My supervisor is nowhere to be found so I am turning to the internet for my naive questions. submitted by /u/obliviousphoenix2003 [link] [Kommentare]

Following up on the on-demand comparison from a couple weeks back - pulled spot/ interruptible pricing this time since that's where the real savings conversation actually lives for anyone running checkpointed training or batch jobs. Checked: June 2026. Spot/interruptible tier, single GPU. ~ H100 80GB -Spot/Interruptible RunPod :- $1.80-$2.40/hr , Community spot, can terminate without notice. Vast.ai :- $1.47-$2.00/hr (low end seen as low as $1.03/hr in thinner markets) wide range, host-dependent. AWS (P5, spot) :- technically available, $2.50-$3.10/hr extremely limited, frequently unavailable at any price. ~ A100 80GB - Spot/Interruptible RunPod :- community spot as low as $0.20-0.40/hr (high variance) , reliability drops fast at this end. Vast.ai:- $0.67/hr typical, lower with thinner-reliability hosts, marketplace bidding, varies by host score. AWS (P4d, spot) :- ~$1.00-1.50/hr more consistently available than P5 spot. What stood out: The spot discount vs on-demand is real - 40-60% off on H100, sometimes more on A100 - but the spread between providers on spot is much wider than on-demand. You're not comparing apples to apples, you're comparing apples to "whatever fell off the truck this hour." AWS spot for H100 (P5) is more of a theoretical price point than a practical one right now - availability is thin enough that "checked the price" and "could actually get one" are two different questions. Vast.ai's floor prices look incredible until you check host reliability scores. The $0.67/hr A100 and the $1.50/hr A100 are not the same product even though they're listed the same way. This tier only makes sense if your job checkpoints well - anything customer-facing or latency-sensitive, spot isn't worth the risk regardless of price. Not selling anything, just tracking this for my own training runs and figured others here are doing the same math. Anyone actually running production batch jobs on spot right now? Curious what interruption rates you're actually seeing vs what's advertised. submitted by /u/Shot-Calligrapher166 [link] [Kommentare]

Hi everyone. Do the ACL arr may 2026 reviews come out of July 2nd or do they come out on July 7 th?? How much does one need to get into Main or Findings? I am a bit new to this. Thanks a lot folks. submitted by /u/Anshuman3480 [link] [Kommentare]

Attending ICML for the first time (virtually) next week as a 3rd year PhD student in the US. I want to get into industry after finishing and have heard a lot about the benefits of networking at conferences to build industry connections. How do you actually go about doing this? Are there gonna be industry reps at the conference who you just go up to and talk to, send LinkedIn connections, and get to know them? Previously only been to one domain-specific conference and had more students/academic people than industry. TLDR: What's the best way to network at these big AI/ML conferences, especially since I'm gonna be attending virtually, with the goal of working in industry as a RE/RS in a couple of years? Would really appreciate any insights or helpful advice. Thanks! submitted by /u/IronBlowers [link] [Kommentare]

Hi everyone, I'm a final-year Computer Engineering student looking for ideas for my major engineering project. I'm interested in building something that uses Machine Learning or Deep Learning and is technically strong enough for a final-year project. I'd like it to solve a real-world problem rather than being just another basic classification or prediction model. Some areas I'm open to include: - Computer Vision - NLP / LLMs - Healthcare - Cybersecurity - Recommendation Systems - Time Series - Multi-modal AI - AI for Education or Productivity I'm also interested in projects that have a good web or mobile interface and demonstrate practical deployment, not just model training. If you've worked on a project that stood out, won competitions, impressed recruiters, or was enjoyable to build, I'd really appreciate your suggestions. It would also be helpful if you could mention: - Why you recommend it - Expected difficulty - Tech stack - Public datasets (if available) Thanks in advance! I'm looking forward to hearing your ideas and learning from your experiences. submitted by /u/Delicious_Corner_754 [link] [Kommentare]

We just open-sourced MOTHRAG, a multi-hop RAG framework that skips the knowledge graph entirely. We kept hitting the same wall building multi-hop RAG: the systems with the best accuracy (GraphRAG, HippoRAG, RAPTOR) all lean on a knowledge graph built offline, and that’s great numbers, until the moment your data changes! Every single update means re-running a heavy LLM indexing pass to rebuild the graph. If your corpus updates daily (prices, internal filings, support tickets, news), you're paying a constant, brutal re-indexing bill. MOTHRAG uses a graph-free dense index with query-time orchestration (with no graph, no GPU) instead. Every component behind a commodity API. We benchmarked it against the heavy graph-based systems on HotpotQA, 2WikiMultiHopQA, and MuSiQue (Accuracy / F1): Benchmark MOTHRAG (ours) GraphRAG HippoRAG RAPTOR HotpotQA 78.1 68.6 75.5 69.5 2WikiMultiHop 76.3 58.6 71.0 52.1 MuSiQue 50.5 38.5 48.6 28.9 And updates are just embed-and-append, with no need in rebuild, and retraining. Cost is ~$0.03/query on commodity APIs, no GPU anywhere. Against GPU-bound systems that use constrained decoding (NeocorRAG), it's not a clean win. We match them on HotpotQA (78.1 vs 78.3) and 2Wiki (76.3 vs 76.1), but we lose on MuSiQue (50.5 vs 52.6). MuSiQue is our weak spot (retrieval recall bottlenecks there), and we haven't solved it yet. The takeaway for us: for multi-hop over changing data, the graph overhead mostly buys you a rebuild bill, not accuracy. A graph-free index with good query-time orchestration held up. It’s Apache-2.0, standard pip install + API keys to run. Repo link is in the comments. Would love to get feedback from anyone running RAG on frequently changing data in production! submitted by /u/Annual-Commercial563 [link] [Kommentare]

Please post your questions here instead of creating a new thread. Encourage others who create new posts for questions to post here instead! Thread will stay alive until next one so keep posting after the date in the title. Thanks to everyone for answering questions in the previous thread! submitted by /u/AutoModerator [link] [Kommentare]

Been chewing on this for a while and I honestly can't tell if it's genuinely open or if I'm just not googling the right terms, so I'll throw it out here. There's a paper by Roynard that put words to something I'd been vaguely bothered by for a while. He calls it a category error, the idea being that pretty much every memory system applies the same persistence model to everything it stores, usually some kind of decay, no matter what the thing actually is. Which is fine for some throwaway message, but it gets weird when the same treatment gets applied to something you've actually validated and would want to stick around and get corrected if it turns out wrong. So you end up storing very different kinds of information under the same rules, even though how much you should trust them or how long they should live is completely different, and I don't think many people are treating that difference as a real property of the memory. That kind of lines up with the thing that keeps biting me once an agent's been running a while, which is that the system doesn't really have any idea how it came to know something in the first place. Something it actually observed, something it inferred a few steps back, and something it just made up all get written down more or less the same way and come back out later at the same confidence, and because none of it is marked as one kind or another, the agent doesn't really have a way to notice when it's wrong. So something stale or hallucinated can resurface later and it looks basically the same as something solid. Timestamps help a little, but they don't tell you what actually backed a belief, and they don't do much when whatever supported it turns out to be wrong and you'd want the agent to walk that back. What bugs me is that this feels like it should already map onto stuff people worked out decades ago. Belief revision (AGM and everything after it) is basically about updating a set of beliefs without it going inconsistent, but I've never really seen it bolted onto an agent's memory at any serious scale. Truth maintenance systems (JTMS/ATMS) are almost exactly this, since the whole point is tracking justifications and retracting conclusions when their premises disappear, and yet they seem basically absent from the agent stacks I've looked at. Calibration work is more about confidence on outputs than about the support behind things you've already stored as they age. And the smarter retrieval stuff, like HippoRAG or the temporal knowledge graph systems (Zep, Graphiti), makes retrieval better but still kind of treats memory as things to find rather than claims that have a support status attached. The closest thing I've found to what I'm describing is Hindsight, which actually splits memory into separate networks and has real conflict-resolution policies, but even there contradictions get surfaced when you query rather than reconciled up front, and corrections don't really propagate to the beliefs that depended on them. A recent paper gets at the human side of it pretty well, The Missing Knowledge Layer in AI. Their framing is that language sort of collapses uncertainty, so when a model states a guess, an inference, and an actual recollection all at the same surface confidence, the person on the other end can't really tell which one they're reacting to, which felt like the same problem I'm describing just viewed from the user's side instead of from inside the memory. What I actually want, at the end of all this, is a small set of primitives for it. Some reasonably clean way to assert something, say what supports it, note that two things contradict, supersede one with another, retract it when it falls apart, with the epistemic status being an actual property of the thing instead of something I bolt on after the fact. Belief revision and TMS feel like the right ancestors, but neither was really built for noisy, high-volume, LLM-generated memory, so a lot of my time just goes into trying to figure out what the right primitives even are. So for anyone who's actually shipped long-horizon agents, I'm curious whether anyone types their memory by epistemic status (observed, inferred, asserted, retracted) instead of just storing flat text plus embeddings, whether anyone's gotten classical belief revision or a TMS to hold up as the actual live memory layer rather than falling over on scale and noise, and whether handling contradictions at write time is even worth the latency or if most people just eat the inconsistency and sort it out at read time. And honestly, if this is already a solved thing and I'm just reinventing some old formalism with extra steps, I'd genuinely appreciate someone pointing me at it so I can go read. But if it's actually underexplored then I'm a little surprised, because it really looks like one of the things that quietly wrecks agents once they've been running longer than a week. submitted by /u/Bright-Fun-1638 [link] [Kommentare]

Hi everyone, The check in QR code is visible at my profile despite that my card isn’t accepting the payment transaction. What does that even mean? Thanks! submitted by /u/misplacedlion [link] [Kommentare]

arXiv’s next chapter: Updates on our spin out from Cornell University: https://blog.arxiv.org/2026/06/30/arxivs-next-chapter/ submitted by /u/Nunki08 [link] [Kommentare]