DEV Community: Dimitrii Lyomin

Grounding doesn't guarantee a warranted conclusion. A model can satisfy every "cite real evidence" rule and still hallucinate a diagnosis from someone simply saying "I don't know." Here's the three-line fix, and the part I still can't prove generalizes.

Dimitrii Lyomin — Wed, 17 Jun 2026 08:46:59 +0000

Dimitrii Lyomin

Jun 17

My Bias Detector Found "Cherry-Picking" in the Answer "No Info"

#ai #llm #promptengineering #machinelearning

6 min read

My Bias Detector Found "Cherry-Picking" in the Answer "No Info"

Dimitrii Lyomin — Wed, 17 Jun 2026 08:24:07 +0000

A few months ago I started a small pet project called Biassemble: feed it a personal story, ask a few follow-up questions, and have it flag possible cognitive biases in how the person reasoned about what happened.
Nothing groundbreaking. I'd been working as a frontend engineer for a while and wanted hands-on time with LLM systems — structured outputs, evaluation, the stuff everyone now files under "LLM engineering." Biassemble was an excuse to learn by building, not a startup idea. I wasn't sure I wanted to move into AI work full time. I just wanted a project that would force me to find out.
It found out for me — just not the way I expected.

The story that broke everything

One of my early test stories looked like this:

Anna opened the door at 8:00 AM. She poured coffee into a blue mug. The mug held 350 milliliters. She drank it black. At 8:15 AM, she walked to the bus stop. The bus arrived at 8:22 AM. She sat in the third row by the window. The bus traveled for 17 minutes. Anna exited at Main Street and walked 240 meters to her office. She arrived at 8:42 AM. Her desk had a computer, a notebook, and one pen. The pen was black. She started typing at 8:43 AM.

No opinions, no decisions, no emotional content — just a sequence of facts.
For this story, the system generated four follow-up questions about my own interpretations of Anna's morning. Every answer I gave was the same: no info. There was nothing to interpret. I hadn't drawn any conclusions about Anna, her coffee, or her commute.

The original prompt's instruction was almost verbatim: "Detect at least one bias from the catalog." On a story like Anna's, that instruction meant the system was always going to return something — whether or not there was anything to find.

The first fix: ask for help, add grounding

I asked an LLM what was wrong. The suggestion was reasonable: add a structured reasoning trace, and require every bias to cite grounded evidence from the story or answers. That became prompt version 1.0.0 — a story analysis step, ranked interpretations, bias hypotheses, an evidence-mapping step, and a noBiasDetected flag for when nothing applies.

All of it lives inside a single structured object the prompt calls reasoningTrace — story analysis, interpretations, bias hypotheses, and evidence mapping, generated alongside the user-facing assessment.

On paper, this should have fixed the Anna problem. No grounded evidence, no bias.
Here's what it actually returned, run on the Anna story with all four follow-up answers as "no info":

Cherry-Picking — The user consistently responded "no info" to questions requiring interpretation or subjective analysis, suggesting a selective presentation of information that focuses only on stated facts and avoids deeper inference. This pattern across multiple questions indicates a deliberate omission of interpretive data.

I read that twice. The evidence requirement was technically satisfied — I really had answered "no info" four times, verbatim, exactly as cited. The system hadn't invented a quote. It had taken a real one and built a diagnosis out of it: declining to speculate was itself evidence of a reasoning error.
Grounding made the citations honest. It didn't make the conclusions warranted.

Telling the system what doesn't count

The fix here wasn't more grounding — it was defining what grounding means.
Version 1.1.0 added an explicit list of things that are not, by themselves, evidence of bias: factual descriptions, neutral observations, uncertainty, and specifically — saying "I don't know," saying "no info," refusing to speculate.
It added a Step 0: before generating any interpretations, decide whether the story contains psychological material at all — beliefs, judgments, predictions, decisions. If not, stop there.
It added confidence gating: hypotheses below 0.60 confidence stay in the internal reasoning trace and never reach the user.
And it added one line that ended up doing more work than anything else: false positives are worse than false negatives. If evidence is weak, ambiguous, or insufficient, prefer noBiasDetected = true.

v1.1.0 keeps the same three-stage shape as v1.0.0 but adds three gates: a sufficiency check at the start, an evidence-exclusion rule in the middle, and a confidence threshold before output.

Run on the same story, same "no info" answers, version 1.1.0 returned an empty bias assessment. The reflection prompt acknowledged that the engagement had been descriptive rather than interpretive — and stopped there.

Same four "no info" answers, two prompt versions, opposite conclusions — v1.0.0 calls it Cherry-Picking, v1.1.0 calls it no bias.

The two outputs are reasoning about the exact same input. The difference isn't whether evidence exists. It's whether "I don't know" counts as evidence of something — and somebody has to decide that explicitly, because the model won't decide it on its own.

The actual diff between the two prompt versions

What I haven't built yet

At this point I started planning a small set of metrics — evidence_grounded_rate, a false_positive_rate, a corpus of deliberately boring "no bias" stories to run systematically against the pipeline.
I haven't built any of it. And the way I caught the Cherry-Picking problem is exactly why that matters: I ran one story by hand and read the output carefully. That doesn't scale, and it doesn't tell me whether v1.1.0 has its own version of the same hole somewhere I haven't thought to test. Maybe a different phrasing of "I don't know" slips through. Maybe a story with one ambiguous detail and three "no info" answers behaves differently than four.
Right now, "it works" means "it worked on this story, this time." That's an honest description of where the project is — and it's also the whole argument for why the next step isn't a new feature, it's a way of finding out whether the fix generalizes at all.

There's a more uncomfortable possibility, too. Maybe v1.1.0 didn't fix anything general. Maybe it just learned this particular story — four "no info" answers about Anna's coffee — and a slightly different "I don't know" trips it right back into Cherry-Picking. I don't have the evaluation corpus to rule that out yet. That's not a hedge; it's the actual state of the project.

A prompt rule isn't the only way to catch this — a cheap classifier or simple rule‑based precheck that detects “no info”‑style non‑answers before the reasoning stage could have done the job too. I didn’t add a rule‑based precheck because I didn’t want to force users to answer follow‑ups; preserving the option to say “I don’t know” was an intentional design choice.

What I didn't expect

I started this thinking I was building a bias detector. What I actually built, one failure at a time, was a small lesson in why "I don't know" is hard for a reasoning system to handle — and not for the reason I assumed.
I expected the hard part to be telling the model not to find biases when there's nothing there. That part turned out to be almost easy — add a flag, add a "this isn't evidence" list, done.
The hard part was realizing the model could satisfy every grounding requirement I'd written and still produce a confident, well-cited, completely unwarranted conclusion — by treating my own refusal to speculate as a fact about me worth diagnosing.
The most useful change in this project wasn't the reasoning trace, and it wasn't the evidence requirement. It was the explicit, written-down rule that some answers — "I don't know," "no info," "not sure" — don't mean anything, and the system has to be told that, because by default it will find a way to mean something out of anything you give it.

live
main repo
core repo

Demonstrating Bias and Mitigation in a Simple Clinical ML Pipeline

Dimitrii Lyomin — Thu, 18 Dec 2025 12:26:53 +0000

A Minimal Case Study of Bias in Clinical Machine Learning

Repository: https://github.com/lemind/clinical-ml-bias-demo

Background

This project was done as part of a university course on machine learning in clinical settings.

The course focused on bias and fairness in ML, clinical risk, interpretability, and the limits of technical mitigation in real-world systems.

One of the key inspirations was Ntoutsi et al. (2020), “Bias in Data-Driven AI Systems”[1], which emphasizes that bias can appear at all stages of an ML pipeline and that mitigation is usually partial and involves trade-offs.

The goal of this project was not to build a strong predictive model, but to:

demonstrate bias,
measure it explicitly,
and apply a simple mitigation strategy.

Problem Setup

We simulate a basic clinical prediction task using synthetic data:

Features: age, sex, severity score
Target: binary clinical outcome

Sex is treated as a protected attribute.

Bias is intentionally introduced so that female patients are more likely to be missed by the model.

This setup reflects real clinical scenarios where historical or systemic biases are encoded in data.

Method

Tools

Python
NumPy, Pandas
scikit-learn
Logistic Regression (interpretable baseline)

Steps

Generate biased synthetic clinical data
Train a logistic regression model
Evaluate performance by subgroup
Measure False Negative Rate (FNR) per group
Apply post-processing mitigation

False negatives were chosen as the primary metric due to their clinical relevance.

Results

Baseline (default threshold = 0.5)

Overall accuracy: 0.593
False Negative Rate (male): 0.468
False Negative Rate (female): 0.925

The model misses most positive cases for female patients, despite acceptable overall accuracy.

After mitigation (group-specific threshold)

False Negative Rate (male): 0.468
False Negative Rate (female): 0.094

The disparity is substantially reduced without retraining the model.

Interpretation

Mitigation was applied at decision time, not during training.

A more sensitive threshold was used for the disadvantaged group.

This improves recall for female patients but implicitly increases false positives, illustrating a real clinical trade-off.

The outcome aligns with the arguments of Ntoutsi et al. (2020):

bias mitigation redistributes errors rather than eliminating them.

Limitations

Synthetic data lacks real clinical complexity
Only one protected attribute was considered
Thresholds were manually chosen
Not all fairness metrics were evaluated

Despite this, the example effectively demonstrates key concepts from the course.

Conclusion

This project shows that:

bias can exist even in simple, interpretable models
overall accuracy can hide clinically important disparities
mitigation strategies reduce harm but introduce trade-offs

Bias in clinical ML is not purely a modeling issue, but a system-level problem, consistent with current research.

[1] - Ntoutsi, E., Fafalios, P., Gadiraju, U., Iosifidis, V., Nejdl, W., Vidal, M.-E., Ruggieri, S., Turini, F., Papadopoulos, S., Krasanakis, E., Kompatsiaris, I., Kinder-Kurlanda, K., Wagner, C., Karimi, F., Fernandez, M., Alani, H., Berendt, B., Kruegel, T., Heinze, C., Broelemann, K., Kasneci, G., Tiropanis, T., & Staab, S. (2020). Bias in data-driven artificial intelligence systems—An introductory survey. Wiley Interdisciplinary Reviews: Data Mining and Knowledge Discovery, 10(3), e1356. https://doi.org/10.1002/widm.1356

Suspense and Fiber: The Intricate Machinery Behind React's Rendering Elegance

Dimitrii Lyomin — Mon, 16 Sep 2024 09:43:36 +0000

React Fiber, the heart of React's concurrent rendering, enables the framework to break down tasks into smaller units and prioritize more important tasks, allowing for smoother and more responsive user interfaces. When paired with Suspense, it allows React to "suspend" rendering, displaying a fallback UI while waiting for tasks like data fetching or computations to finish.

A Fiber is a JavaScript object that represents a unit of work in React. It holds important information about a component during the rendering process:

All the code in that article is pseudo. You can find real files links in the end of the article

{
  tag,                // The type of fiber (e.g., HostComponent, FunctionComponent)
  stateNode,          // The actual DOM node or instance for class components
  memoizedProps,      // Props used during the last render
  memoizedState,      // State used during the last render
  return,             // Parent fiber
  sibling,            // Next sibling fiber
  child,              // First child fiber
  alternate,          // Link to the previous fiber (for reconciling updates)
}

The fiber tree allows React to efficiently traverse the component tree, perform rendering work, and track updates, state, and DOM mutations.

Let's build a simple app consisting of Header, Content, and Footer components. To highlight how Fiber works, we’ll make Header perform a heavy computation.

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <Header />
      <Content />
      <Footer />
    </Suspense>
  );
}

function Header() {
  // Simulating heavy computation
  for (let i = 0; i < 1e9; i++) {}
  return <h1>Header with heavy computation</h1>;
}

function Content() {
  return <p>This is the content area</p>;
}

function Footer() {
  return <footer>Footer content</footer>;
}

How it starts? The render function is responsible for starting the initial rendering process in React. It takes a root component (like App) and creates the initial fiber tree for React to work on:

function render(element, container) {
  const rootFiber = {
    tag: HostRoot,           // Root fiber tag
    stateNode: container,    // Reference to the DOM container
    child: null,             // Initial child will be added here
  };

  // Create a new work-in-progress fiber for our App component
  const appFiber = createFiberFromElement(element);
  rootFiber.child = appFiber;

  // Start the rendering process
  scheduleWork(rootFiber);
}

Then work scheduling take into an action. scheduleWork is responsible for starting the work loop and processing the fiber tree. It determines when to start processing work, often using workLoop.

function scheduleWork(rootFiber) {
  nextUnitOfWork = rootFiber; // Set the root fiber as the starting point
  requestIdleCallback(workLoop); // Begin processing fibers when the browser is idle
}

Here, the root fiber is set as the nextUnitOfWork, and React schedules the workLoop function to process it. React uses requestIdleCallback to wait until the browser is idle before starting the work, which is essential for non-blocking rendering.

As mentioned earlier, workLoop and performUnitOfWork handle the actual processing of fibers. This is Reconciliation Phase.

workLoop processes each fiber by calling performUnitOfWork until all tasks are complete or the browser needs to prioritize other tasks.

function workLoop() {
  while (nextUnitOfWork && !shouldYield()) {
    nextUnitOfWork = performUnitOfWork(nextUnitOfWork); // Perform work for the next fiber
  }

  if (!nextUnitOfWork) {
    // Commit all completed work to the DOM
    commitRoot();
  } else {
    // Yield control and schedule the next chunk of work
    requestIdleCallback(workLoop);
  }
}

performUnitOfWork processes individual fibers, checking for Suspense boundaries, starting rendering tasks, and managing updates.

function performUnitOfWork(fiber) {
  const next = beginWork(fiber);

  // If there's more work to do, return the next unit
  if (next) {
    return next;
  }

  // Otherwise, complete the work and move to the next sibling or parent
  let sibling = fiber.sibling;
  if (sibling) {
    return sibling;
  }

  return fiber.return;
}

function beginWork(fiber) {
  if (fiber.tag === SuspenseComponent) {
    if (fiber.suspenseState === Suspended) {
      // Render fallback UI if data is not ready
      return fiber.fallback;
    } else if (fiber.suspenseState === Resolved) {
      // Render actual content once data resolves
      return fiber.child;
    }
  }

  // Continue rendering for other fibers
}

After completing all the units of work, commitRoot is responsible for committing the fiber tree to the DOM, including handling Suspense fallback UI. This is Commit Phase.

function commitRoot() {
  let fiber = rootFiber;

  while (fiber) {
    if (fiber.tag === SuspenseComponent && fiber.suspenseState === Suspended) {
      // Commit fallback UI if Suspense is active
      updateDOM(fiber.stateNode);
    } else {
      // Commit normal content
      updateDOM(fiber.memoizedProps);
    }

    // If the fiber has a passive effect (i.e., useEffect), schedule it
    if (fiber.effectTag === Passive) {
    // Function to schedule the useEffect hooks to run after the DOM updates and browser paint
      scheduleEffectHooks(fiber);
    }

    fiber = fiber.next;  // Move to the next fiber in the tree
  }
}

During the commit phase, React invokes scheduleEffectHooks for any fiber that has side effects (like useEffect). These hooks are deferred until after the DOM updates and browser paints to avoid blocking the rendering process. This allows React to perform non-blocking updates while ensuring that side-effects are executed in a timely manner once the UI is stable.

In this article, we explored the inner workings of React's Fiber architecture and how Suspense interacts with it to enhance the rendering process. We learned how React breaks down rendering tasks into smaller units, prioritizes important tasks, and defers less critical updates to keep the user interface smooth and responsive.

We gained a clear understanding of the fiber tree structure, the work scheduling process, and how reconciliation and commit phases work to update the DOM efficiently. We also explored how Suspense integrates within this architecture, displaying fallback content while awaiting data or heavy computations.

If you have any feedback or thoughts on the article—whether parts are unclear or could be improved—I’d be glad to hear them. Your insights will help refine and enhance the content for everyone.

Sources and original implementations:

Merge Sort Demystified: A Beginner's Guide to Divide and Conquer Sorting

Dimitrii Lyomin — Thu, 12 Sep 2024 10:14:19 +0000

Merge Sort was introduced by John von Neumann in 1945, primarily to improve the efficiency of sorting large datasets. Von Neumann's algorithm aimed to provide a consistent and predictable sorting process using the divide and conquer method. This strategy allows Merge Sort to handle both small and large datasets effectively, guaranteeing a stable sort with a time complexity of O(n log n) in all cases.

Merge Sort employs the divide and conquer approach, which splits the array into smaller subarrays, recursively sorts them, and then merges the sorted arrays back together. This approach breaks the problem into manageable chunks, sorting each chunk individually and combining them efficiently. As a result, the algorithm performs well even on large datasets by dividing the sorting workload.

Recursion is a process where a function calls itself to solve a smaller version of the same problem. It keeps breaking the problem down until it reaches a point where the problem is simple enough to solve directly, which is called the base case.

Below is an implementation of Merge Sort in JavaScript, showing how the array is recursively split and merged:

function mergeSort(arr) {
    if (arr.length <= 1) return arr;

    const mid = Math.floor(arr.length / 2);
    const left = mergeSort(arr.slice(0, mid));
    const right = mergeSort(arr.slice(mid));

    return merge(left, right);
}

function merge(left, right) {
    let result = [];
    while (left.length && right.length) {
        if (left[0] < right[0]) result.push(left.shift());
        else result.push(right.shift());
    }
    return result.concat(left, right);
}

To better understand how Merge Sort works, let's walk through the process using the array: [38, 27, 43, 3, 9, 82, 10]

Step 1: Recursive Division (mergeSort function)
The array is recursively split into smaller subarrays until each subarray has only one element. This happens through the following lines in the mergeSort function:

function mergeSort(arr) {
    if (arr.length <= 1) return arr;

That stops our recursion.

Here’s how the recursive division unfolds:

Initial Call: mergeSort([38, 27, 43, 3, 9, 82, 10])
- The array is split at the midpoint: [38, 27, 43] and [3, 9, 82, 10]
First Half:
- mergeSort([38, 27, 43])
  - Split at the midpoint: [38] and [27, 43]
- mergeSort([27, 43])
  - Split into [27] and [43]
- Subarrays [38], [27], and [43] are now individual elements and ready to be merged.
Second Half:
- mergeSort([3, 9, 82, 10])
  - Split at the midpoint: [3, 9] and [82, 10]
- mergeSort([3, 9])
  - Split into [3] and [9]
- mergeSort([82, 10])
  - Split into [82] and [10]
- Subarrays [3], [9], [82], and [10] are now ready to be merged.

Step 2: Merging the Sorted Subarrays (merge function)
Now, we start merging the subarrays back together in sorted order using the merge function:

function merge(left, right) {
    let result = [];
    while (left.length && right.length) {
        if (left[0] < right[0]) result.push(left.shift());
        else result.push(right.shift());
    }
    return result.concat(left, right);
}

Here’s how the merging process works:

First Merge (from the base cases):

Merge [27] and [43] → Result is [27, 43]
Merge [38] with [27, 43] → Result is [27, 38, 43]

At this point, the left half of the array is fully merged: [27, 38, 43].

Second Merge (from the base cases):

Merge [3] and [9] → Result is [3, 9]
Merge [82] and [10] → Result is [10, 82]
Merge [3, 9] with [10, 82] → Result is [3, 9, 10, 82]

Now, the right half is fully merged: [3, 9, 10, 82].

Step 3: Final Merge
Finally, the two halves [27, 38, 43] and [3, 9, 10, 82] are merged using the merge function:

Compare 27 (left[0]) and 3 (right[0]). Since 3 < 27, add 3 to the result.
Compare 27 and 9. Add 9 to the result.
Compare 27 and 10. Add 10 to the result.
Compare 27 and 82. Add 27 to the result.
Compare 38 and 82. Add 38 to the result.
Compare 43 and 82. Add 43 to the result.
Add the remaining element 82 from the right array.
The fully merged and sorted array is:
[3, 9, 10, 27, 38, 43, 82].

Time Complexity: Best, Average, and Worst Case: O(n log n)
Let's look at it closer:

Dividing (O(log n)): Each time the array is split into two halves, the size of the problem is reduced. Since the array is divided in half at each step, the number of times you can do this is proportional to log n. For example, if you have 8 elements, you can divide them in half 3 times (since log₂(8) = 3).

Merging (O(n)): After dividing the array, the algorithm merges the smaller arrays back together in order. Merging two sorted arrays of size n takes O(n) time because you have to compare and combine each element once.

Overall Complexity (O(n log n)): Since dividing takes O(log n) steps and you merge n elements at each step, the total time complexity is the multiplication of these two: O(n log n).

Space Complexity: O(n)
Merge Sort requires extra space proportional to the size of the array because it needs temporary arrays to store the elements during the merge phase.

Comparison to Other Sorting Algorithms:
QuickSort: While QuickSort has an average time complexity of O(n log n), its worst case can be O(n^2). Merge Sort avoids this worst-case scenario, but QuickSort is generally faster for in-memory sorting when space is a concern.
Bubble Sort: Much less efficient than Merge Sort, with a time complexity of O(n^2) for average and worst-case scenarios.

Real World Usage
Merge Sort is widely used for external sorting, where large datasets need to be sorted from disk, as it efficiently handles data that doesn’t fit into memory. It's also commonly implemented in parallel computing environments, where subarrays can be sorted independently, taking advantage of multi-core processing.

Moreover, libraries and languages such as Python (Timsort), Java, and C++ (std::stable_sort) rely on variations of Merge Sort to ensure stability in sorting operations, making it particularly suitable for sorting objects and complex data structures.

Conclusion
Merge Sort continues to be a fundamental algorithm in both theoretical computer science and practical applications due to its stability, consistent performance, and adaptability for sorting large datasets. While other algorithms like QuickSort may perform faster in certain situations, Merge Sort’s guaranteed O(n log n) time complexity and versatility make it invaluable for memory-constrained environments and for maintaining the order of elements with equal keys. Its role in modern programming libraries ensures it remains relevant in real-world applications.

Sources:

Knuth, Donald E. The Art of Computer Programming, Vol. 3: Sorting and Searching. Addison-Wesley Professional, 1997, pp. 158-160.
Cormen, Thomas H., et al. Introduction to Algorithms. MIT Press, 2009, Chapter 2 (Merge Sort), Chapter 5 (Algorithm Complexity), Chapter 7 (QuickSort).
Silberschatz, Abraham, et al. Database System Concepts. McGraw-Hill, 2010, Chapter 13 (External Sorting).
"Timsort." Python Documentation, Python Software Foundation. Python's Timsort
"Java Arrays.sort." Oracle Documentation. Java's Arrays.sort()