Kyle Goldberg

Hallucinations Aren’t the Real Problem. Misplaced Trust Is. Everyone talks about hallucinations in LLMs like they’re a bug. But here’s the real issue: We don’t yet know when to trust the model. Hallucinations are predictable in open-ended generation. The danger is when: - Users assume factuality - Systems lack fallback mechanisms - There's no validation or confidence estimation Instead of just asking “How do we reduce hallucination?”, we should ask: 👉 “How do we design systems where AI knows when not to speak?” That means adding: - Confidence thresholds - Refusal-to-answer capabilities - Grounding in verified knowledge Trust isn’t just about output quality. It’s about building user expectations and system behavior that align. #AItrust #LLMdesign #ResponsibleAI #GenAI #AIsafety

5

1 Comment

90% of people use AI wrong. Not because AI is bad. Because their prompts are vague. Instead of: "Clean this CSV and make it usable." That prompt could mean 100 different things. So AI guesses. And you get generic output. Try this: "In data.csv: Remove rows where email is empty. Deduplicate on email, keeping the most recent entry. Standardize phone numbers to +1-XXX-XXX-XXXX. Export as cleaned_data.csv." Same task. 10x better result. The difference? Specificity. Here's my rule of thumb: If your prompt could apply to many different tasks, it's too vague. A good prompt can only produce one kind of output. My day to day is: Spend a lot of time drafting precise prompts Set agents up to succeed. The result: agents deliver what I actually need on the first try. Here are 3 things that make any prompt specific: 1. Name the inputs (files, columns, formats) 2. Number the steps (so nothing gets skipped) 3. Define the output (format, filename, length) Vague in, vague out. Specific in, useful out. Share and idea that works for you in prompting so others that see this post can benefit.

11

4 Comments

I spent 3 months building a free AI research platform nobody asked for. researchnu.com — no login, no paywall, no limits. As a graduate researcher I was tired of stitching together Google Patents, PubMed, NIH, arXiv, ClinicalTrials across a dozen tabs. And watching people announce startup ideas that were already patented or published three years ago. So I built ResearchNu. One query. 26 sources and counting. 7 agents. Free. What's under the hood: — LangGraph pipeline: Corrective RAG + Self-RAG — Google Patents, Y Combinator, PubMed, NIH, USPTO, FRED and 20 more — Custom MCP server so Claude, GPT and Gemini can query it directly — Full MLOps: Docker, K8s, AWS, Nginx, SSL — built and deployed from scratch Latency is 20-30s and the UI is Streamlit — both honest weak spots, both on the roadmap amongst adding more sources(waiting on the API keys) and constantly improving the pipeline to make for better usage. Full write-up: https://lnkd.in/ecgcPvtC Open source: https://lnkd.in/efPy8YgP Have also attached the architecture below for a better breakdown. #AgenticAI #LLM #MLOps #MachineLearning #BuildInPublic #OpenSource #Research

122

38 Comments

Data is not just tables. It’s table + code. Code is hard to maintain. With convoluted pipeline, it’s hard to get the basic metrics right over time. The right approach is make the pipeline end to end tracable, visualized, and in one place. Yes, I’m talking about Statsig ‘s metric catalog. That’s probably one of the most under appreciated products, even within our own company. But I believe it’s the key thing for good data sustainably.

14

I went down an ML rabbit hole this week and realized something simple: most model pain isn’t about fancy math—it’s about asking the right question. 🧠 Here’s the plain-English version with everyday examples: 1) Start with the decision, not the model What will someone do with the score—approve, route, review, or wait? Example: Like a barista: is this order made now, sent to a senior barista, or put on hold? That choice sets your target, metric, and speed needs. 2) Baselines before brilliance Try the simplest thing first (a rule, majority class, or linear model). Example: Before buying a race car, see if a bike gets you there on time. If the “smart” model can’t beat the simple one in business terms, you’re just revving the engine. 3) Pick metrics that fit the moment Rare positives? Use precision/recall and PR curves (ROC can look great while you miss the few cases that matter). Real trade-offs? Turn results into $ cost / $ benefit and choose thresholds by net value—not vibes. Example: A club bouncer can be strict (high precision) or lenient (high recall). Which costs you more: letting in the wrong person or turning away the right one? 4) Slice it like you mean it Overall AUC can flatter you. Slices tell the truth. Example: A restaurant’s 4.5⭐ average hides that Tuesdays are great and Fridays are chaos. Check by region, channel, season, edge cases. 5) Avoid self-sabotage Leakage: like grading with the answer key—don’t use future info. Shift: seasons change; train/test across time and watch drift. Calibration: if the model says 0.8, it should be ~80% likely—fix it if not. Example: Your weather app promising “80% rain” should be right ~8/10 days. 6) Make failure cheap Add a human review lane, rate-limit risky actions, and log why the model decided. Example: Training wheels for your model—fast to move, safe to stop. 7) Monitoring > mythologizing Track data quality, drift, latency, and outcomes. Close the loop so the model learns from reality. Example: Like a car dashboard—fuel, speed, engine light. You don’t guess; you watch. Model Checklist ✅ Define the goal & one success metric ✅ Gather data → quick scan (duplicates, missing, outliers) ✅ Clean data & pick key features ✅ Split into train / test ✅ Build a simple baseline → try a simple model → pick the best ✅ Choose a threshold that reflects cost/benefit ✅ Check key slices (new vs. returning, mobile vs. web) ✅ Add human-review path + decision logs ✅ Deploy with monitoring (quality & drift) and a rollback plan #MachineLearning #DataScience #MLOps #LearningInPublic #AI

8

Common misconceptions about LLMs — and the realities that matter for practitioners and leaders: – Misconception 1: LLMs understand language like humans. Reality: They don’t “understand” concepts. They predict token sequences based on patterns in training data. This distinction matters when designing prompts and systems. – Misconception 2: More parameters always mean better performance. Reality: Data quality and architecture often matter more than size. Smaller models like Phi-3 (3.8B params) can outperform much larger ones on reasoning tasks. – Misconception 3: LLMs are just autocomplete on steroids. Reality: Scaling transformers + massive datasets creates emergent abilities like reasoning, translation, and code generation — far beyond autocomplete. – Misconception 4: LLMs remember everything. Reality: They don’t have perfect recall. Knowledge is distributed and lossy. Always validate outputs and consider retrieval-augmented generation (RAG). – Misconception 5: Fine-tuning always makes models better. Reality: Fine-tuning can improve one task but harm others due to catastrophic forgetting. Try prompt engineering or RAG before fine-tuning. – Misconception 6: LLMs are deterministic. Reality: They’re probabilistic. Same input can yield different outputs. This is useful for creativity but needs guardrails in production. – Misconception 7: Bigger context windows are always better. Reality: Beyond a point, models suffer “lost in the middle” effects. Smart chunking, summarization, and retrieval often beat brute force context. – Misconception 8: LLMs replace all traditional ML. Reality: For high-throughput, low-latency tasks like spam filtering, traditional models still outperform and cost less. – Misconception 9: Prompt engineering is just trial and error. Reality: It’s systematic. Techniques like chain-of-thought prompting, role assignment, and structured outputs consistently improve results. – Misconception 10: LLMs will replace software developers. Reality: They are powerful assistants but lack system-level judgment, design thinking, and business context. They’re productivity multipliers, not replacements. The bigger lesson: LLMs are not “magic boxes.” They are powerful probabilistic systems with strengths, blind spots, and tradeoffs. To use them effectively, you need to combine: – Solid prompt engineering – Retrieval systems for factual grounding – Monitoring and alignment techniques – A clear understanding of cost vs performance tradeoffs LLMs are not the end of software development or machine learning. They are the next layer — and success depends on using them wisely. #AI #LLM #GenerativeAI #MachineLearning #DataScience #ResponsibleAI #ArtificialIntelligence

6

Hermes Agent is not just another AI agent. It represents a fundamental shift in how we think about intelligence in software systems. For a while, most agents followed a familiar pattern: a central controller orchestrating tools, workflows, and responses. Efficient? Yes. Intelligent? Not quite. Hermes flips this model. Instead of building around a control plane, it builds around the agent’s own loop: → Think → Act → Evaluate → Learn → Improve This seemingly simple shift changes everything. What stands out is its focus on self-improvement and procedural memory. Hermes doesn’t just execute tasks—it reflects on them. It learns what worked, what failed, and converts those learnings into reusable “skills.” Over time, it builds its own playbook. A few things that make this approach powerful: • Persistent memory → It doesn’t forget after each session • Adaptive skills → Workflows evolve instead of staying static • Model-agnostic design → Flexibility to switch models without rewriting systems • Decoupled interface → Always-on agents accessible from anywhere In many ways, Hermes feels less like an API-driven system and more like an operating system for agents. But let’s be clear — this is still early. Self-evaluation isn’t perfect. Skill management can get messy. And what we call “learning” today is still far from true reinforcement learning. Yet, the direction is undeniable. We are moving from: Agents that execute tasks to Agents that improve how they execute tasks And that’s where things start getting really interesting. If you’re building in the AI/agent space, this is a paradigm worth paying attention to. #AI #AgenticAI #LLM #ArtificialIntelligence #Innovation #TechTrends

6

We made it: 92% recall without SMOTE resampling 🥳 I've been revisiting an old ML project where I predict loan defaults with a random forest model and quickly fell into the rabbit hole of imbalanced data. With a default rate of only 16%, my model was missing over 75% of defaults. Womp womp. I decided to restructure my process to the following: 1. hyperparameter tuning to optimize on average precision (AP), balancing recall and precision 2. penalize misclassifying defaulters using class_weight="balanced" 3. cross-validation using StratifiedKFold() to ensure that all folds have a representative proportion of class labels 4. threshold optimization prioritizing F2 score, which places a higher weight on recall while still considering precision Surprisingly, this resulted in a 92% recall, a huge improvement from the previous 25%! The precision is only 19%, but this is a known tradeoff with imbalanced data and one that I chose to make to prioritize recall. I was still curious to see if SMOTE resampling would offer an improvement. Interestingly, this led to a worse recall (85% from 92%) and no change in F2-score. While I was initially surprised, Soledad Galli recently shared a computational study in which she found most oversampling methods to be ineffective in improving random forests. In the end, careful consideration of the model architecture and chosen performance metrics were superior to SMOTE. 😎

131

38 Comments