From Conflicting Answers to Unified Knowledge: Building LLM-Wiki with OpenViking

The article opens with a realistic scenario: a customer asks about compensation for uninsured goods, and three team members provide three different answers, each backed by a different official document. This illustrates the core problem — teams have abundant documents but lack a connected knowledge network that can resolve applicability.

1. The Missing Piece: A Queryable, Updatable Wiki Network

Andrej Karpathy’s April 2026 LLM-Wiki paradigm proposes inserting a persistent, LLM-maintained Markdown layer between raw materials and users. This layer consists of entity pages, concept pages, and comparison pages, with cross-references and contradiction markers. When new evidence arrives, the same knowledge base is updated rather than generating yet another disjointed answer.

For the compensation question, a proper Wiki chain would be:

Check the Customer Wiki to confirm purchased service and business type.

Check the Product Wiki to identify the corresponding product, route, and service scope.

Link to the Billing & Compensation Wiki to find the current effective standard, applicability conditions, and exceptions.

This transforms scattered documents into a traceable, on-demand knowledge network that continues to grow.

2. Building the LLM-Wiki with OpenViking

2.1 Import Scattered Resources into OpenViking

First, gather all relevant sources: product specs and FAQs in Feishu, historical compensation rules on local disks, product-change context in project records, and code in GitHub repositories. OpenViking provides Connectors to ingest these into a unified resource store.

In the OV console, click “+” and choose:

Local files — upload compensation rules, historical regulations, business descriptions.

Web pages, online resources, Git repos — add via URL; e.g., a GitHub repo URL pulls README, code, and config files while preserving directory structure and respecting .gitignore.

Feishu docs — use “Data Source Sync → Feishu Document” with authorization.

For recurring sync or bulk import, the CLI command ov add-resource can be used:

ov add-resource "https://github.com/your-org/product-config" 
  --to viking://resources/xxx 
  --watch-interval 60

--watch-interval 60

syncs every 60 minutes. After import, resources are immediately queryable by Agents via OpenViking’s hierarchical progressive retrieval (summary first, then detail), saving retrieval tokens.

2.2 Compile Resources into Wiki Using Skills

OpenViking’s Compile function runs a Skill that directs an Agent to reorganize raw data into the desired Wiki structure. A Skill defines four things: target audience, organization method, mandatory facts/conditions, and validation checks.

For the compensation case, the Skill must preserve product, region, version, exceptions, and inter-page links. You can write a custom Skill and import it: ov add-skill ./claims-wiki Alternatively, use the official llm-wiki template that generates a sourced, interlinked, navigable knowledge base:

ov add-skill https://github.com/volcengine/OpenViking/tree/skills/llm-wiki

Then launch a compile task in the console terminal ( / → compile ) with three core parameters: --from — source directory URI (e.g., viking://resources/demo/raw) --to — target output directory (e.g., viking://resources/xxx/wiki) --skill — the Skill URI returned from import --instruction — optional focus hint (e.g.,

"面向一线答疑整理，重点关联客户、产品和赔付规则"

)

Example command:

ov compile 
  --from viking://resources/demo/raw 
  --to viking://resources/xxx/wiki 
  --skill <Skill_URI> 
  --instruction "面向一线答疑整理，重点关联客户、产品和赔付规则"

The console returns a task_id for progress tracking.

2.3 Team Members View, Edit, and Evolve the Wiki

Once compilation finishes, the Wiki lives in the target OV directory. Teammates can open, read, and edit pages directly in the console. For example, if a compensation rule misses the applicable region, click “Edit” on that page, add the condition, and save. The correction is instantly visible to everyone.

CLI access is also available:

ov tree viking://resources/xxx/wiki
ov read viking://resources/xxx/wiki/index.md

2.4 Let Agents Retrieve the Wiki Directly

To avoid manual lookup, integrate OpenViking with your Agent (Codex, TRAE, etc.) via MCP, CLI, API, or SDK. For Codex, run the installer:

bash <(curl -fsSL https://ovrelease.tos-cn-beijing.volces.com/memory-plugin-shared/install.sh) --harness codex --dist tos

Provide the API key for api.vikingdb.cn-beijing.volces.com. After restarting Codex, approve the four hooks ( SessionStart, UserPromptSubmit, Stop, PreCompact) via /hooks. Verify with a test prompt; a memory digest at the start confirms success.

Then ask Codex to read the Wiki index:

请使用 OpenViking 读取：
viking://resources/xxx/wiki/index.md
列出其中的主要主题，并保留对应页面的 URI。

Next, encode the team’s lookup methodology into a Retrieval Skill so the Agent knows:

When to use — for customer service, product applicability, billing, or compensation questions.

Where to look — the Wiki directory; navigate or search to locate topics, then read full text.

How to verify — follow “Customer → Service → Product → Rule” to confirm applicability, cross-check region, time, exceptions, and fall back to original sources if needed.

How to answer — give conclusion, conditions, and sources; explicitly state gaps or conflicts instead of guessing.

Shared Retrieval Skills let every team member use their preferred Agent while querying the same continuously maintained Wiki.

2.5 Beyond Wiki: Other Skills for Different Outputs

Compile’s output depends on the Skill. Swapping in Daily Report , Knowledge Distillation , or Knowledge Graph Skills turns the same raw materials into work logs, topical analyses, or entity-relationship maps — all stored in OV for human and Agent reuse.

3. Back to That Phone Call: What Changed

Next time the customer asks, the frontline sees a single, expandable knowledge thread instead of three clashing documents:

Current confirmed stance.

Applicable product, region, period, and exceptions.

Historical versions and change relationships.

Unresolved conflicts flagged for clarification.

Source citation for every statement.

Answerable questions are resolved on the spot; open items know exactly who to ask and what to verify. The verified result feeds back into the same Wiki, so the next colleague doesn’t repeat the search.

This is the value of OpenViking × LLM-Wiki: it turns each search, discussion, and confirmation into a reusable team asset — not just faster search, but compounding collective knowledge.