feat: virtual knowledge base feature bundle

[xiecheng1978]

Summary

• Introduce the Virtual Knowledge Base feature bundle under [features/virtual-knowledge-base/], delivering tag taxonomy management, VKB construction, and enhanced search capabilities without touching the core WeKnora codebase.
• Provide Go services and PostgreSQL migrations for tags, document-tag associations, VKB filters, and search pre-filter hooks (see [internal/]and [migrations/]).
• Rebuild the frontend sample with the same Vue 3 + Vite + Pinia + TDesign stack as the main console, offering Tag Management, Virtual KB Management, and Enhanced Search views (web/src/views/*), plus integration notes in the updated README.

Context

WeKnora currently manages knowledge bases at the document level and lacks fine-grained tagging as well as dynamic composition driven by business rules. As a result, it struggles to support private, role-based, or scenario-specific retrieval when serving multiple teams and use cases.

Objective & Impact

The features/virtual-knowledge-base/
sub-project introduces a Virtual Knowledge Base (VKB) solution that enables users to:

• Define custom tag dimensions (e.g., permission, weight, business domain) and link them to individual documents.
• Build virtual knowledge bases from tag rules so different teams or scenarios can access “view-like” collections without duplicating source documents.
• Select or combine VKBs during retrieval to pre-filter results and adjust weights, producing more precise answers.

Design Notes

• Backend logic in internal/ defines tag entities, document-tag associations, VKB models, and related services, while
  migrations/ supplies PostgreSQL schemas; these modules stay decoupled from the core application and can be mounted on demand.
• The web/ directory adopts the same Vue 3 + Vite + Pinia + TDesign stack as the main frontend and ships views such as
  TagManagement.vue, VirtualKBManagement.vue, and EnhancedSearch.vue, making it easy to review functionality or embed into the existing console.
• README.md and DESIGN.md
  provide quick-start instructions, architectural context, and integration guidance to help reviewers understand deployment, validation, and adoption steps.

[lyingbug]

为什么会新增一个 feature/virtual-knowledge-base 这样的目录？另外前端是在frontend目录下，我看你是新起了一个web目录？能否整合合并到WeKnora中？

[xiecheng1978]

为什么会新增一个 feature/virtual-knowledge-base 这样的目录？另外前端是在frontend目录下，我看你是新起了一个web目录？能否整合合并到WeKnora中？

我是为了避免对现有主项目改动太多，就新开了一个扩展目录。使用者，可以考虑是否自己进行整合。

[smallxinpilot]

我的理解是现有项目仅支持一个大的知识库，没有提供将知识库中的文档分类给多个团队使用，这个子项目通过对文档进行标签来达到这个效果嘛。---在检索过程中选择或组合 VKB 来预先过滤结果并调整权重，从而产生更精确的答案(这一步例如这个选择和租和VKB可以在前端实现嘛还是需要租户在配置界面实现)

[xiecheng1978]

我的理解是现有项目仅支持一个大的知识库，没有提供将知识库中的文档分类给多个团队使用，这个子项目通过对文档进行标签来达到这个效果嘛。---在检索过程中选择或组合 VKB 来预先过滤结果并调整权重，从而产生更精确的答案(这一步例如这个选择和租和VKB可以在前端实现嘛还是需要租户在配置界面实现)

前端实现。另外，一个文档可以虚拟对应不同知识库，避免不同知识库是下同一文档多次向量存储。

[smallxinpilot]

我的理解是现有项目仅支持一个大的知识库，没有提供将知识库中的文档分类给多个团队使用，这个子项目通过对文档进行标签来达到这个效果嘛。---在检索过程中选择或组合 VKB 来预先过滤结果并调整权重，从而产生更精确的答案(这一步例如这个选择和租和VKB可以在前端实现嘛还是需要租户在配置界面实现)

前端实现。另外，一个文档可以虚拟对应不同知识库，避免不同知识库是下同一文档多次向量存储。

谢谢解答！