I would like to know how session management takes place in Modbus RTU. This is for a machine learning project that I am doing.

I am doing a Machine Learning project on Modbus RTU Frames as my data. I want to split my frames into sessions for sequence alignment and keyword clustering. I would like to know what parameter should I use to split the frame list into sessions or if there is a concept of sessions
You're on step 8 and I'm back on step 1 with your knowledge of programming techniques, of which I am ignorant.

But I can tell you that the Modbus RTU frame over serial needs to be contiguous and it is very timing-sensitive, in contrast to Modbus ASCII over serial.

When license-free wireless became popular 15 years ago, there were many issues with radios using RS-485 serial input/output ports that broke up Modbus message ADU/PDU's or failed to honor the 3.5 character time-out with the result being corrupted Modbus messages and poor or non-existent communication. The lesson learned was that radios needed to be Modbus-compatible, not just capable of de-constructing and re-constructing words coming over RS-485.

I don't know what your keywords, sequence alignment or sessions mean or involve but in the end, a split-up, mistimed Modbus RTU message is no message at all, it's destined to be discarded.
I'm not quite sure what you consider a session, but I'm not sure you're going to find anything like that for Modbus RTU. The closest thing, in my opinion, would be to split frames based on the address of the target device. You could then further split frames by function code.

Be aware, though, that there are several Modbus RTU frames (function codes 5, 6, 8, 21, 22) where the request looks identical to the response. So simply looking at only one packet, without the context of the packets around it, you would not be able to determine whether it is a request or a response.

Although the obsolete specification, PI-MBUS-300, is intended only for legacy applications, I do find it easier to understand (especially for a beginner in Modbus) as it documents complete Modbus RTU request and response packets for each function code (as opposed to all the ADU and PDU abstraction in the modern spec that can be hard to follow). I suggest taking a look at the formats of each function code here: