Estoy representando una cadena de Markov como una estructura de datos anidados, en Python como un dict de dicts de dicts... Por ejemplo, para entender lo que quiero decir, dada la oración 'this is purely an example, this is not serious.' , genero todos los pares consecutivos y registro el token que les sigue y sus frecuencias:
{',': {'this': {'is': 1}}, 'an': {'example': {',': 1}}, 'example': {',': {'this': 1}}, 'is': {'not': {'serious': 1}, 'purely': {'an': 1}}, 'not': {'serious': {'.': 1}}, 'purely': {'an': {'example': 1}}, 'this': {'is': {'not': 1, 'purely': 1}}} Luego, puedo consultarlo mediante el acceso repetido a elementos. Por ejemplo, puedo ver que después 'this is' hay 'not' o 'purely' , ambos con frecuencia 1.
En este ejemplo artificial, la cadena tiene un tamaño de estado de 2, pero los genero con estados de 3, 4, 5, 6. El corpus de texto también es enorme, y el resultado es que el diccionario que representa la cadena ocupa decenas de GB de RAM.
Estaba investigando formas alternativas de almacenar la cadena de Markov en el disco. He considerado Neo4J, pero no parece muy adecuado para este caso de uso específico. Lo mismo se aplica a la estructura ltree de Postgres. Luego me decidí por una tabla simple en una base de datos relacional, como la siguiente (tamaño de estado 4):
CREATE TABLE chain ( w1 varchar(20), w2 varchar(20), w3 varchar(20), w4 varchar(20), children json, PRIMARY KEY(w1, w2, w3, w4) );Hay una compensación de rendimiento al construir la estructura, pero dado que solo se paga una vez que es aceptable.
¿Existe una mejor manera de almacenar grandes cadenas de Markov en el disco, lo que permite realizar consultas sin necesidad de grandes cantidades de RAM?
Un proceso de Markov es, en cierto sentido, una máquina de estado probabilística, que satisface la propiedad de Markov (que puede iniciar la máquina de estado desde cualquier estado para que los eventos pasados no afecten las probabilidades).
Por lo tanto, debe almacenar un índice de estado, mediante el cual consultará, y un Blob o algo más descriptivo que incluya los estados a los que puede hacer la transición y sus probabilidades.
Al crear el índice de estado, no debe usar solo el índice incremental, sino algún tipo de método similar a la búsqueda binaria, que tiene sentido en el dominio de su aplicación de aprendizaje automático.
Por ejemplo, podría tener los estados 1000 1100 0100 y 0000 para "es", "no", "puramente" y "esto" (estoy omitiendo ",", "un", "ejemplo" por simplicidad). Entonces, el estado "esto es", sería 0001, el primer 00 denotaría "esto" y el segundo 01 denotaría "es". Aquí asumo que "esto es" contendrá el estado completo, por ejemplo, que no habrá otro "esto es" en su conjunto de datos. Si ese fuera el caso, creo que sería una violación de la propiedad de Markov o una falla en su lógica de consulta (en lugar de bigramas, debería consultar otra cosa).
De todos modos, esto debería ser eficiente en RAM y podría permitirle muchos tipos de estrategias de búsqueda.