Gracias a la estructura de clasificación, podemos estimar qué estrategia funciona realmente en nuestro diseño.
Antes de manejar con un wrapper el caso de “se puede entregar, pero no se entrega”, creo que lo correcto es empezar por esos 149 casos. Que haya un ID en la respuesta pero no se esté mapeando probablemente se deba a un problema de convención en el nombre del campo (id / _id / resource_id / document_id) o a una estructura anidada (result.data.id). Estos 149 casos están dentro de lo que se puede resolver corrigiendo solo la capa de mapeo, sin modificar la API.
Para el lado de “no se puede entregar”, creo que habría que abordarlo de forma distinta según la herramienta.
En write_file, con una combinación de ruta + hash del contenido se puede detectar si “se escribió dos veces el mismo contenido”.
En k8s scale, si el número objetivo de réplicas ya es igual al valor actual, en la práctica es idempotente; con una consulta previa del estado se puede evitar directamente la ejecución duplicada.
click es distinto. Ponerle un ID a la acción en sí no tiene mucho sentido; parece más realista comparar snapshots de antes y después para ver si “el cambio de estado que este click buscaba lograr ya ocurrió”.
Lo que estamos evaluando internamente es una forma de convertir las herramientas en una matriz de “si pueden devolver ID × tipo de cambio de estado” y ramificar la estrategia de manejo según eso. Si pudieran compartir con más detalle en qué patrones se concentran esos 149 casos, ayudaría a definir la estrategia de mapeo.
¡Sí! Está modelado tomando como referencia el tamaño estándar más común.
Sin embargo, en el caso de departamentos que no tienen ese tamaño estándar, está implementado para predecir usando varias muestras de otros tamaños.
Probé ingresando el departamento antiguo donde viven mis padres...
pero solo aparece 33 pyeong... ese departamento antiguo tiene unidades de 33 y 26 pyeong.
¿Originalmente solo admite 33 pyeong?
Parece que olvidé incluir la función para compartir apartamentos en el texto, jaja. Les dejo un enlace para probar, de paso, de Helio City, un complejo grande y conocido.
(¡Tomen los resultados de la predicción solo como referencia y, para el modelado detallado, consulten el libro blanco!)
Se abre directamente sin iniciar sesión, así que pueden entrar con confianza para echarle un vistazo a la UI de los gráficos. https://app.apt-insights.com/s/apt/9NPumhVmCv
Uf, recién me enteré por este post de que existía un sitio coreano de cppreference y me puse feliz...
Pero parece que tendré que seguir usando el sitio en inglés, como antes.
Si dividimos los 3,197 casos por motivo, queda así.
La respuesta no incluía ningún campo de ID: 2,011 casos (62.9%)
La llamada falló con error: 1,037 casos (32.4%)
La respuesta tenía un ID, pero nuestro mapeo no lo detectó: 149 casos (4.7%)
Aquí hay algo que debo corregir. Antes dijeron que “la mayoría de los duplicados están en una zona donde ni siquiera se puede rastrear”, pero el 32% son llamadas fallidas. Como no ocurrió nada, no hay nada que rastrear. Los casos que realmente “ocurrieron pero no se pudieron rastrear” son 2,011. Sigue siendo un número grande, pero menor que 3,197.
Había 24 herramientas que solo devuelven éxito/fracaso. Agrupadas por tipo:
Manipulación del navegador (9) — click, type, navigate, etc. Solo click suma 719 casos
Sistema de archivos (3) — write_file, edit_file, move_file
Kubernetes (4) — scale, create, apply, delete
Edición de documentos (3) — add_paragraph, add_heading, format_text
Individuales — emails-send_email, excel-write_data_to_excel, snowflake-write_query, logging_write_log, github-fork_repository, github-create_repository
Estas 24 se dividen en dos tipos. Lo agrego porque creo que puede ser útil para diseñar la especificación.
Las que no pueden dar un ID Un clic en el navegador o la edición de un archivo, para empezar, no tienen una “entidad creada”. No se le puede asignar un ID a un clic. En el caso de un archivo, la ruta es el identificador.
Las que podrían darlo pero no lo hacen github-create_repository es el caso típico. Si se creó un repositorio, obviamente hay un ID, pero no viene en la respuesta. emails-send_email también tiene un message ID a nivel SMTP, pero no lo devuelve. github-fork_repository y excel-write_data_to_excel son iguales.
El segundo grupo es el que se puede corregir. Si en la especificación de herramientas internas incluyeran “las operaciones de creación deben incluir obligatoriamente el ID de la entidad en la respuesta”, creo que esta distinción puede servir como criterio para decidir dónde aplicarlo.
Los últimos 149 casos son un problema de nuestro mapeo. Se concentran en notion database-query con 102 casos y pptx open_presentation con 28, y en ambos casos no los detectamos porque son herramientas que dejamos deliberadamente fuera de alcance. No es un problema de diseño de herramientas, sino de nuestra cobertura.
En el stack que operan actualmente, ¿en cuál de estos grupos se concentran las operaciones de escritura? Lo que vimos nosotros viene de un benchmark, así que probablemente la composición de herramientas sea distinta a la de una operación real.
Si puedes avanzar хотя sea un paso al día, eso es suficiente.
Producir se vuelve más fácil y la validación más sofisticada; al final, la 'elección' se convierte en la clave. Por eso, este es un momento en el que es aún más importante tener el criterio para leer con precisión la dirección del cambio.
Últimamente, como los agentes de codificación pueden compensar las partes en las que uno es débil, creo que la barrera de entrada podría bajar si uno conoce bien sus fortalezas y sabe aprovecharlas.
En mi caso, la documentación siempre fue un problema, pero al delegarle una parte a un agente de codificación, la carga también se redujo, y además, al revisar ese material documentado, siento que también estoy desarrollando mejor criterio sobre la documentación.
Joven... devuélvanme el valor de mi casa...
Ahora estoy pagando suscripciones mensuales :'( Creo que el costo no es menor, así que estoy pensando en la sostenibilidad.
Gracias a la estructura de clasificación, podemos estimar qué estrategia funciona realmente en nuestro diseño.
Antes de manejar con un wrapper el caso de “se puede entregar, pero no se entrega”, creo que lo correcto es empezar por esos 149 casos. Que haya un ID en la respuesta pero no se esté mapeando probablemente se deba a un problema de convención en el nombre del campo (
id/_id/resource_id/document_id) o a una estructura anidada (result.data.id). Estos 149 casos están dentro de lo que se puede resolver corrigiendo solo la capa de mapeo, sin modificar la API.Para el lado de “no se puede entregar”, creo que habría que abordarlo de forma distinta según la herramienta.
write_file, con una combinación de ruta + hash del contenido se puede detectar si “se escribió dos veces el mismo contenido”.k8s scale, si el número objetivo de réplicas ya es igual al valor actual, en la práctica es idempotente; con una consulta previa del estado se puede evitar directamente la ejecución duplicada.clickes distinto. Ponerle un ID a la acción en sí no tiene mucho sentido; parece más realista comparar snapshots de antes y después para ver si “el cambio de estado que este click buscaba lograr ya ocurrió”.Lo que estamos evaluando internamente es una forma de convertir las herramientas en una matriz de “si pueden devolver ID × tipo de cambio de estado” y ramificar la estrategia de manejo según eso. Si pudieran compartir con más detalle en qué patrones se concentran esos 149 casos, ayudaría a definir la estrategia de mapeo.
¡Sí! Está modelado tomando como referencia el tamaño estándar más común.
Sin embargo, en el caso de departamentos que no tienen ese tamaño estándar, está implementado para predecir usando varias muestras de otros tamaños.
Probé ingresando el departamento antiguo donde viven mis padres...
pero solo aparece 33 pyeong... ese departamento antiguo tiene unidades de 33 y 26 pyeong.
¿Originalmente solo admite 33 pyeong?
¡Guau! Es un servicio que yo también quería hacer; ¿podrías decirme más o menos cuánto cuesta Supabase al hacer este tipo de scraping?
¿Tanto los videos como las grabaciones se sirven desde el servidor?
Parece que olvidé incluir la función para compartir apartamentos en el texto, jaja. Les dejo un enlace para probar, de paso, de Helio City, un complejo grande y conocido.
(¡Tomen los resultados de la predicción solo como referencia y, para el modelado detallado, consulten el libro blanco!)
Se abre directamente sin iniciar sesión, así que pueden entrar con confianza para echarle un vistazo a la UI de los gráficos.
https://app.apt-insights.com/s/apt/9NPumhVmCv
Hay muchas apps gratuitas y también es fácil de hacer, así que si es una app de pago, mmm...
Gracias por el aviso. ¡Ya lo corregí!
El enlace al documento técnico está arrojando un error 404.
https://edge.apt-insights.com/v1/public/whitepaper
Uf, recién me enteré por este post de que existía un sitio coreano de cppreference y me puse feliz...
Pero parece que tendré que seguir usando el sitio en inglés, como antes.
Ah, hace mucho que no uso Windows, así que no lo sabía bien; buscando, parece similar.
Si dividimos los 3,197 casos por motivo, queda así.
La respuesta no incluía ningún campo de ID: 2,011 casos (62.9%)
La llamada falló con error: 1,037 casos (32.4%)
La respuesta tenía un ID, pero nuestro mapeo no lo detectó: 149 casos (4.7%)
Aquí hay algo que debo corregir. Antes dijeron que “la mayoría de los duplicados están en una zona donde ni siquiera se puede rastrear”, pero el 32% son llamadas fallidas. Como no ocurrió nada, no hay nada que rastrear. Los casos que realmente “ocurrieron pero no se pudieron rastrear” son 2,011. Sigue siendo un número grande, pero menor que 3,197.
Había 24 herramientas que solo devuelven éxito/fracaso. Agrupadas por tipo:
Manipulación del navegador (9) — click, type, navigate, etc. Solo click suma 719 casos
Sistema de archivos (3) — write_file, edit_file, move_file
Kubernetes (4) — scale, create, apply, delete
Edición de documentos (3) — add_paragraph, add_heading, format_text
Individuales — emails-send_email, excel-write_data_to_excel, snowflake-write_query, logging_write_log, github-fork_repository, github-create_repository
Estas 24 se dividen en dos tipos. Lo agrego porque creo que puede ser útil para diseñar la especificación.
Las que no pueden dar un ID Un clic en el navegador o la edición de un archivo, para empezar, no tienen una “entidad creada”. No se le puede asignar un ID a un clic. En el caso de un archivo, la ruta es el identificador.
Las que podrían darlo pero no lo hacen github-create_repository es el caso típico. Si se creó un repositorio, obviamente hay un ID, pero no viene en la respuesta. emails-send_email también tiene un message ID a nivel SMTP, pero no lo devuelve. github-fork_repository y excel-write_data_to_excel son iguales.
El segundo grupo es el que se puede corregir. Si en la especificación de herramientas internas incluyeran “las operaciones de creación deben incluir obligatoriamente el ID de la entidad en la respuesta”, creo que esta distinción puede servir como criterio para decidir dónde aplicarlo.
Los últimos 149 casos son un problema de nuestro mapeo. Se concentran en notion database-query con 102 casos y pptx open_presentation con 28, y en ambos casos no los detectamos porque son herramientas que dejamos deliberadamente fuera de alcance. No es un problema de diseño de herramientas, sino de nuestra cobertura.
En el stack que operan actualmente, ¿en cuál de estos grupos se concentran las operaciones de escritura? Lo que vimos nosotros viene de un benchmark, así que probablemente la composición de herramientas sea distinta a la de una operación real.
La versión en coreano tuvo su última actualización en 2016, así que parece mejor ver el original.
Si puedes avanzar хотя sea un paso al día, eso es suficiente.
Producir se vuelve más fácil y la validación más sofisticada; al final, la 'elección' se convierte en la clave. Por eso, este es un momento en el que es aún más importante tener el criterio para leer con precisión la dirección del cambio.
¿Se parece a la función integrada de Windows? Windows + V
Vaya, con esto ya no habría que preocuparse por cosas como el roleplay.
Uy, ya lo corregí.
Últimamente, como los agentes de codificación pueden compensar las partes en las que uno es débil, creo que la barrera de entrada podría bajar si uno conoce bien sus fortalezas y sabe aprovecharlas.
En mi caso, la documentación siempre fue un problema, pero al delegarle una parte a un agente de codificación, la carga también se redujo, y además, al revisar ese material documentado, siento que también estoy desarrollando mejor criterio sobre la documentación.