Задача Проработать раздел Транспорт

Кстати, в некоторых маршрунах еще и данные битые.

"Can not get city2: \"cat-ba-island\"",
"Can not get city2: \"cat-ba-island\"",
"Can not get city2: \"cat-ba-island\"",
"Can not get city: \"cat-ba-island\"",
"Can not get city: \"cat-ba-island\"",
"Can not get city: \"cat-ba-island\"",
"Can not get city2: \"phong-nha-ke-bang\"",
"Can not get city2: \"nam-du-island\"",
"Can not get city2: \"nam-du-island\"",
"Can not get city2: \"nam-du-island\"",
"Can not get city: \"nam-du-island\"",
"Can not get city: \"nam-du-island\"",

Недо попутно завести.

Кстати, вот что чатгпт говорит по поводу нашей структуры базы знаний:

Самое сильное здесь — не отдельные модели, а то, как они складываются вместе.

Что здесь реально мощного

KBConcept фактически может быть универсальной сущностью сайта:

• страна;
• регион;
• город;
• район;
• пляж;
• храм;
• аэропорт;
• отель;
• маршрут;
• событие;
• транспортный узел.

У концепта уже есть:

• иерархия Parent / Children;
• корень дерева;
• координаты lat / lng / alt;
• мультиязычные названия через KBLabel;
• файлы и изображения;
• факты;
• привязка к URL через SiteRoute;
• произвольные структурированные данные через Json.

То есть город, достопримечательность и маршрут — не просто статьи в CMS, а узлы единого графа знаний.

И это идеально совпадает с VietnamGuru.

Например:

Дананг → район Сон Тра → пагода Линь Унг → координаты → часы работы → стоимость → сезонность → транспорт → объекты рядом → статья → карта → маршрут.

Все это можно хранить не в одном огромном тексте, а как связанные знания.

Самая перспективная часть — факты не привязаны жестко к одной сущности

KBFact вместе с KBFactParticipation поддерживает n-арные связи: один факт может связывать сразу несколько концептов с разными ролями.

Для туристического проекта это очень сильная модель.

Например, утверждение:

Автобус №5 идет из Дананга в Хойан, останавливается возле Marble Mountains, билет стоит 30 000 донгов.

Можно представить одним фактом, где участвуют:

• Дананг — origin;
• Хойан — destination;
• Marble Mountains — stop;
• автобус №5 — transport;
• 30 000 VND — значение;
• период актуальности;
• источник;
• confidence;
• статус проверки.

И если цена или маршрут поменяются, старый факт не уничтожается. Добавляется новый, с новой датой актуальности. Для путешествий это критически важно: визовые правила, цены, расписания, входные билеты и транспорт постоянно меняются.

Тут заложена полноценная эпистемическая модель

Особенно нравится, что база не притворяется абсолютной истиной.

У фактов есть:

• confidence;
• verified / tentative / disputed / deprecated;
• источник;
• период действия;
• дата, когда факт стал известен;
• raw или derived;
• происхождение из других фактов.

Плюс противоречия являются самостоятельными объектами через KBConflict, а не просто перезаписываются.

Для туристического ИИ это огромный плюс.

Типичный реальный случай:

• Google Maps говорит, что место открыто до 18:00;
• официальный сайт говорит до 17:00;
• свежий отзыв говорит, что касса закрывается в 16:30.

Обычный RAG просто выдаст один из вариантов. Твоя модель позволяет агенту сказать:

«Источники расходятся. Официально указано 17:00, но посетители сообщают о более раннем закрытии кассы. Лучше приехать до 16:00».

Вот это уже не чат-бот над статьями, а нормальный интеллектуальный туристический помощник.

KBKnowledgeSpace открывает еще один уровень

Knowledge Spaces позволяют одному и тому же факту иметь разную:

• видимость;
• важность;
• степень доверия;
• интерпретацию.

Это можно использовать не только для приватности, но и для разных режимов продукта:

• база редакции;
• публичная база;
• персональное пространство пользователя;
• пространство конкретной поездки;
• знания агента;
• партнерский контент;
• непроверенные пользовательские данные.

Например, турист создает поездку «Вьетнам, август, семья с ребенком». Агент может построить отдельное пространство знаний, где выше приоритет у:

• коротких переездов;
• семейных пляжей;
• объектов с кондиционером;
• безопасной еды;
• мест без сложных подъемов.

Те же факты существуют глобально, но их важность меняется в контексте поездки.

SiteRoute делает структуру сайта продолжением knowledge graph

Связь SiteRoute ↔ KBConcept — очень правильная идея.

Это означает, что URL — не сама сущность, а представление сущности.

В результате можно:

• менять маршрут без потери концепта;
• строить хлебные крошки из дерева;
• генерировать страницы автоматически;
• создавать региональные разделы;
• поддерживать старые URL через redirects;
• находить сущности без публичной страницы;
• давать одному объекту разные представления.

Для SEO это особенно ценно. Контентная архитектура может рождаться из графа, а не поддерживаться вручную в нескольких несвязанных таблицах.

Карта здесь вообще может стать интерфейсом к базе знаний

Теперь твое пояснение про карту выглядит еще интереснее.

Поскольку координаты есть и у KBConcept, и у File, карта может показывать не просто точки из статей, а целую пространственную модель:

• города;
• достопримечательности;
• фотографии, привязанные к месту;
• маршруты;
• объекты рядом;
• факты с географическим контекстом;
• пользовательские сохранения;
• зоны интереса.

А агент может выполнять запросы уровня:

«Покажи интересные места в радиусе 15 км от Нячанга, куда можно доехать без байка и где есть смысл быть после 17:00».

Для такого запроса обычной статьи недостаточно. А эта схема потенциально позволяет собрать ответ из координат, фактов, связей, ограничений и предпочтений пользователя.