The ELI5 is that "semantic actions" are bits of code that a parser generator runs, and "production rules" are patterns that tell it when to run them.
For a simple ambiguous arithmetical grammar, the output of a parser fed "1 + 2 * 3" might be something like "[Mul [Add 1 2] 3]", or "AddExpr(1, MulExpr(2, 3))", or "1 2 3 Mul Add", or "1. Start with 1; 2. Add 2; 3. Multiply by 3", or (more likely in practice) in-memory data structures corresponding to one of those. The form of the representation doesn't matter; it's just an indication of the sequence of steps that gets you from 'nothing' to whatever input string was provided.
But there's not really a concept of 'actions' to go with parsing. Parsing tells you how some string was constructed, or how it might have been constructed. What you do with that information is up to you.
In the example above, the parser's interest in a MulExpr is that it can produce a string containing the token '*'. The fact that mathematically two times three equals six doesn't come up.
I'll appeal to authority here and quote from the Dragon Book:
>> Program fragments embedded within production bodies are called semantic actions.
In CS, particularly around compilers, it's an old concept.
A Yacc file contains the grammar of the language to be parsed, but to each grammar rule you can attach a C function that will be invoked by the generated parser when matching that rule.
That C function is the "semantic action" registered for the corresponding grammar production rule.
For instance, by registering appropriate "semantic actions" the generated parser can become a language interpreter, e.g. when matching a multiplication expression a function that does multiplication is invoked, and so on.
If the parser is intended for a compiler, not for an interpreter, the "semantic actions" may generate some intermediate format of the compiled program, like that used by LLVM.
Older compilers with less memory may have compiled each function as it was parsed, but it's pretty typical these days for the parser to output a whole-file AST that you process separately.
"Production rules" are rules in grammar descriptions for tools like yacc. "Semantic actions" correspond to pieces of code/logic executed whenever a given rule is fully parsed from input.
The terminology is baroque, but pretty standard in parsing circles.
Essentially, different parsing algorithms "run side effects" at different stages of the parsing algorithm application, which can make certain things easy or difficult depending on the timing.
E.g.: If parsing runs side effects before it has 100% decided on what rules have been applied, it may need to "back track" and undo side-effects. This can be very painful to code around, so a common solution is to build (only) a temporary abstract syntax tree (AST) in a pure functional manner, and later come back and process that instead of trying to handle every "do and undo" scenario during initial parsing.
Parsers that only run side-effects when a decision is final allow very efficient compilers that directly "do the thing" instead of building temporary structures.
IIRC, Pascal was compiled this way, in a single pass.