Temas sugeridos - Sugerencias basadas en título y contenido

Sería bastante fantástico si los temas sugeridos tuvieran en cuenta los títulos y el contenido de los temas. Por ejemplo, si estás leyendo un tema sobre el tema de ‘analítica’, los temas que contengan contenido similar podrían mezclarse en los resultados sugeridos actuales.

Si esto se pudiera hacer de manera eficiente, estoy seguro de que sería una victoria segura para aumentar la participación tanto de los nuevos visitantes como de los usuarios activos. Incluso si estas sugerencias solo usaran los títulos de los temas (en lugar de título + contenido).

6 Me gusta

Creé un tema similar, pero está bloqueado.
Actualmente he desactivado esta función y la he reemplazado con la mía.

1 me gusta

Esta es una función muy complicada de construir de manera eficiente y el laberinto es enorme. En algún punto comienzas a considerar el aprendizaje automático, y el laberinto se vuelve más y más profundo.

Veo el atractivo de usar IA para determinar contenido relacionado; esto puede ser muy útil en los temas de #soporte, que casi pueden volverse de “autoatención”. Publicas una pregunta, el aprendizaje automático selecciona 10 candidatos y simplemente los publica como una respuesta que puedes aceptar o eliminar. De manera similar, cuando un usuario anónimo busca ayuda, es útil mostrar contenido relacionado.

Dicho esto… una tarea gigantesca y enorme. No está en nuestra hoja de ruta para el próximo año. Pero @eviltrout está muy interesado en experimentar con IA/aprendizaje automático en algún momento, y este es el tipo de proyecto que podría relacionarse.

@codinghorror sigue siendo un gran fanático de DJ random, porque cree que puede superar a muchos y muchos algoritmos sofisticados (y a menudo lo hace).

7 Me gusta

DJ random es fantástico, aunque lo filtramos por tiempo y categoría/etiqueta; eso es importante.

3 Me gusta

Hola,

Soy nuevo aquí, así que disculpa si estoy insistiendo en algo ya resuelto.

Estoy de acuerdo con @sam en que hay un camino complejo, pero por otro lado, la tecnología de modelado de temas es bastante madura hoy en día y existen herramientas listas para usar muy buenas. Un proyecto reciente mío analizó aproximadamente 5 millones de títulos y resúmenes de patentes; analizar del orden de miles de temas en mi nuevo y brillante sitio de Discourse sitio sería pan comido. Además, mi comunidad podría tener la energía necesaria para hacerlo realidad.

A los expertos: Me gustaría recibir consejos sobre si debería pensar en diseñar un plugin o si debería modificar el código fuente de Discourse (que he descargado de GitHub).

Encontré esto sobre cómo extraer temas de un foro de Discourse con Python, pero aún no he logrado que funcione. Algo similar debería permitirme extraer los datos de forma offline, construir el modelo y cargarlo para consultas posteriores.

Por cierto, la mayoría de las buenas herramientas están en Python.

4 Me gusta

Funcionalmente, encaja mejor en el panel “Tu tema es similar a…” cuando estás redactando un nuevo tema.

1 me gusta

Sin duda, recomendaría un complemento en lugar de modificar el código fuente. Es extremadamente improbable que pudiéramos incluir algo así en el núcleo, ya que requeriría una gran dependencia de Python y una interfaz de usuario extensa para el entrenamiento, entre otros aspectos.

Hay mucho trabajo relacionado con los mecanismos de entrenamiento, etc. ¿Tendrías un resumen de los mecanismos mediante los cuales realizarías el entrenamiento? ¿Qué modelos exactos recomendarías utilizar? ¿Qué sucede cuando un tema tiene 100 publicaciones? ¿1000 publicaciones?

¿Qué utilizarías como señal y qué peso le darías a cada elemento (vistas, categoría, etiqueta, etc.)?

Me encanta mucho este proyecto, pero siento que es una tarea bastante enorme.

3 Me gusta

Hay mucho trabajo en torno a los mecanismos de entrenamiento y demás. ¿Tendría un resumen de los mecanismos mediante los cuales realizaría el entrenamiento? ¿Qué modelos exactos recomendaría usar?

Las herramientas actuales que utiliza mi equipo provienen de gensim. Tiene una interfaz estándar de módulo de Python. Ha sido bastante bien probado durante muchos años.

La configuración que me viene a la mente sería:

  • Primero: elegir el conjunto de documentos: podrían ser todas las raíces de temas, o todas las publicaciones.

De vez en cuando (por ejemplo, una vez por semana, una vez al mes, dependiendo del tráfico del foro), construir el modelo doc2vec:

  • extraer los temas de Discourse a un archivo (o archivos) de texto en md, con título + cuerpo del tema. Ahora pensando en cada tema como un documento, o “documento” para los algoritmos de gensim.
  • ejecutar herramientas estándar de PLN para procesar los documentos, aplicar lematización a las palabras, etc.
  • usar doc2vec (de la implementación de gensim) para construir un modelo que mapee cada documento en un vector en un espacio de dimensión d. Debe elegir el parámetro meta d mediante experimentación; Google utiliza d=40 para sus modelos de patentes; no estoy seguro de qué valor de d utiliza Google Scholar. Yo normalmente uso d=200. Cada dimensión del espacio puede considerarse como una “característica” relacionada con el contenido semántico.
    • (Nota: el algoritmo doc2vec construye el espacio de características entrenando una red neuronal diseñada para aprender secuencias de palabras; la red neuronal tiene una capa oculta de dimensión d; las salidas de la capa oculta forman el espacio latente de características)
  • Construir el modelo es la tarea más pesada, dependiendo de cuántos documentos tenga. 38 años de patentes = 5 millones de documentos; el modelo doc2vec tarda una noche en una máquina antigua con 8 núcleos.
  • Tarea adicional opcional interesante: agrupar la nube de documentos en el espacio de características de dimensión d.
    • Se pueden usar herramientas listas para usar para la agrupación, por ejemplo, de la biblioteca sklearn de Python.
    • La agrupación proporciona una clasificación emergente; las preguntas de investigación interesantes incluyen cómo estas clasificaciones se superponen con las categorías de palabras clave (o etiquetas de Discourse).

Esto ocurriría de forma offline. Luego, en línea:

  • El modelo se cargaría.
  • Una vez cargado el modelo, una tarea bastante ligera es analizar un nuevo documento y consultar el modelo para obtener su ubicación en el espacio de características de dimensión d.
    • tenga en cuenta que este nuevo documento no desencadenaría una reconstrucción del modelo. El modelo sería estático para las consultas en línea. El nuevo documento se incorporaría en la siguiente construcción (por ejemplo, semanal) del modelo.
  • Luego, la última tarea ligera es preguntar cuáles son los documentos cercanos en el espacio de características. Hay herramientas de gensim para obtener una lista de documentos cercanos, pero también puede usar numpy directamente para cargar todos los vectores de documentos en una estructura como un árbol kd que permite consultas rápidas de puntos cercanos directamente.

¿Qué sucede cuando un tema tiene 100 publicaciones? ¿1000 publicaciones?

La parte offline escala más o menos linealmente con el número de documentos, pero debería ser muy manejable para 10k-100k documentos. Incluso 1 millón de documentos está bien para un lote semanal.

¿Qué usaría para la señal y qué fuerza le daría a cada cosa (vistas/categoría/etiqueta, etc.)?

En este contexto, la “fuerza de la señal” para un nuevo tema se interpreta directamente como la distancia (inversa) entre la incrustación del espacio vectorial del nuevo tema y los vectores de documentos existentes. Se podría embellecer esta señal con otras consideraciones (me gusta, vistas, etc.), pero estos son adornos adicionales al algoritmo básico que estoy describiendo.

Una vez que yo (o alguien) logre que la extracción funcione, la parte offline descrita anteriormente es bastante fácil y mecánica.

La parte difícil (para mí) sería la parte en línea, que requeriría una interfaz entre Rails de Discourse y un puñado de llamadas de Python (por ejemplo, a las herramientas de gensim). Cualquier ejemplo de este tipo de interfaz me sería útil para verlo.

6 Me gusta

@Bcat: Me interesaría mucho ver cómo lo “reemplazaste con el tuyo”. ¿Tienes algún plugin o repositorio que pueda consultar?

La parte complicada en cuanto al rendimiento es el mecanismo de RPC aquí. No quieres lanzar un nuevo proceso de Python para cada vista de tema.

Incluso una llamada HTTP podría ser demasiado lenta.

Quizás… poblar una tabla related_topics (topic_id, related_topic_id, rank)? De esta manera, podrías apoyarte en WebHooks para actualizar la tabla rápidamente cuando las personas publican nuevos temas, y Ruby no tendría que llamar a Python.

Por el lado de Discourse, la implementación sería bastante sencilla; solo tendrías que reescribir este método para buscar la información en tu nueva tabla related_topics.

2 Me gusta

El antiguo método no funcionó, así que lo reemplacé con Google Ads. Los temas que sugiere Google son muy inteligentes.
En cuanto al antiguo método, desactivé la sugerencia predeterminada y la reemplacé con un fragmento de JavaScript que llama a /search y luego devuelve una lista de temas.

2 Me gusta

Gracias por la referencia a la implementación de la tabla. Sin embargo, no estoy seguro de que el enfoque de la tabla sea escalable. Para N temas, necesitamos una tabla de tamaño N^2. Así que para 10^4 temas, la tabla tendría 10^8 entradas.

No veo cómo evitar la necesidad de una llamada a Python para analizar un nuevo tema, incrustarlo y encontrar los vecinos más cercanos. En el pasado he construido una interfaz web, pero en este caso probablemente me inclinaría por ejecutar un proceso de Python en segundo plano y comunicarme con Discourse a través de un socket o una tubería, funcionando más o menos como leer y escribir en un archivo en lugar de hacer una llamada a Python real. (Después de todo, todo se ejecuta en mi servidor…)

Lo siento, creo que lo estoy entendiendo completamente mal, ¿no?

Si tienes 100 temas y cada tema muestra 5 temas relacionados, ¿por qué la tabla tendría que ser más grande que 500?

1 me gusta

N temas => N puntos en la representación del espacio vectorial.
La matriz de distancias entre cada punto es de tamaño N^2 (la matriz es simétrica, por lo que hay N*(N-1)/2 valores independientes). Esto es lo N^2 a lo que me refería.

Sin embargo, estructuras de datos inteligentes (por ejemplo, kd-tree) permiten encontrar los vecinos más cercanos sin necesidad de una búsqueda exhaustiva en la tabla de N^2 diferencias.

De todos modos, sé cómo hacer todo esto en Python, devolviendo la pequeña tabla a la que te refieres, de tamaño N x 5 para los 5 temas más cercanos.

1 me gusta

Entonces, si ejecutas eso diariamente en Python, podrías simplemente conectar Python directamente a la base de datos de Discourse y hacer que genere esta tabla de caché.

Luego, la parte del plugin de Discourse es bastante trivial. En lugar de seleccionar desde la ubicación X, selecciona desde la ubicación Y (una tabla diferente).

Ya no necesitas lidiar con pipelines que deben abarcar dos lenguajes de programación para una sola solicitud.

El enfoque de IA que se ha sugerido aquí suena interesante y puede ser la solución ideal.

Me pregunto si valdría la pena explorar un enfoque menos técnico: la sección Temas Sugeridos podría contener un botón “Sugerir Tema”. Hacer clic en el botón permitiría a los usuarios publicar un enlace a otro tema en el sitio y una breve descripción de por qué los dos temas están relacionados.

No es una maqueta adecuada, pero para asegurarnos de que estamos en la misma página, me refiero a algo como esto:

Como contexto, estoy interesado en sugerir temas que apoyen y contrarresten las opiniones expresadas en un tema en particular. Por ejemplo, si alguien crea un tema afirmando que el cambio climático no es un gran problema, me gustaría que los usuarios del sitio pudieran sugerir temas relacionados que refuten o apoyen ese argumento.

También podría ser útil para temas menos controvertidos. Al responder a un tema aquí, a menudo utilizo la funcionalidad de búsqueda del sitio para ver si hay temas relacionados. Los resultados de ese esfuerzo podrían preservarse al permitir a los usuarios sugerir temas relacionados. Como ejemplo, leer este tema me hizo pensar en el uso reciente de IA por parte de Discourse aquí: Discourse Disorder. Me parecería relevante que ese tema apareciera en la lista de temas sugeridos de este tema, con una nota que mencione que Discourse parece estar investigando formas de integrar foros con IA.

3 Me gusta

Actualización, esto ya está implementado en el plugin Discourse AI :confetti_ball:

5 Me gusta