Да, такой вариант рассматривал. Более того, граф у меня уже является основной структурой данных.
Просто сейчас я не использую специализированную graph db. Граф хранится в нормализованной реляционной модели, stages -> stage_transitions, kg_entities -> kg_relations. То есть не линейный json, который потом превращается в граф, а линейное представление лишь одна из его проекций. Поверх графа строятся graph, path, timeline и blocks.
Что касается RAG здесь полностью согласен, логичное следующее направление. Сейчас pipeline в первую очередь строит и валидирует версионированный knwoledge graph из клинических рекомендаций.
Поэтому graph db я пока рассматриваю как возможный следующий инфраструктурный шаг, а RAG как отдельный слой поверх уже построенного knowledge grahp.
Да, здесь действительно стоило сформулировать точнее.
3,2 млн токенов не размер исходного документа и не означает, что я отправляю модели 1000+ страниц одним запросом. Это суммарный объём обработки по всему pipeline, несколько независимых этапов, разные входы и выходы, повторная работа с фрагментами документа, генерация сущностей, связей, evidence и последующие проверки.
Именно поэтому я и разделил исходную задачу на этапы. В первом варианте большой json упирался в лимиты ответа модели. В текущем pipeline модель не получает задачу прочитай весь документ и верни весь граф одним json.
То есть условно, документ -> несколько этапов обработки -> суммарно 3,2 млн токенов, а не 1000 страниц -> один запрос -> 3,2 млн токенов -> один json.
При этом 3,2 млн - среднее значение для полного построения на моих текущих данных, а не фиксированный размер каждого документа. Тут согласен, в статье эту разницу стоило явно проговорить.
Так как в тик токе видео хранятся без водяных знаков, при запросе они подставляют его. В данной статье показано как найти и достать оригинальное видео.
Да, такой вариант рассматривал. Более того, граф у меня уже является основной структурой данных.
Просто сейчас я не использую специализированную graph db. Граф хранится в нормализованной реляционной модели, stages -> stage_transitions, kg_entities -> kg_relations. То есть не линейный json, который потом превращается в граф, а линейное представление лишь одна из его проекций. Поверх графа строятся graph, path, timeline и blocks.
Что касается RAG здесь полностью согласен, логичное следующее направление. Сейчас pipeline в первую очередь строит и валидирует версионированный knwoledge graph из клинических рекомендаций.
Поэтому graph db я пока рассматриваю как возможный следующий инфраструктурный шаг, а RAG как отдельный слой поверх уже построенного knowledge grahp.
Да, здесь действительно стоило сформулировать точнее.
3,2 млн токенов не размер исходного документа и не означает, что я отправляю модели 1000+ страниц одним запросом. Это суммарный объём обработки по всему pipeline, несколько независимых этапов, разные входы и выходы, повторная работа с фрагментами документа, генерация сущностей, связей, evidence и последующие проверки.
Именно поэтому я и разделил исходную задачу на этапы. В первом варианте большой json упирался в лимиты ответа модели. В текущем pipeline модель не получает задачу прочитай весь документ и верни весь граф одним json.
То есть условно, документ -> несколько этапов обработки -> суммарно 3,2 млн токенов, а не 1000 страниц -> один запрос -> 3,2 млн токенов -> один json.
При этом 3,2 млн - среднее значение для полного построения на моих текущих данных, а не фиксированный размер каждого документа. Тут согласен, в статье эту разницу стоило явно проговорить.
4. Строим запрос.
5. Получаем конечную ссылку после redirect.
6. :)