Without having thought about it further, this might work.

All we would need to do would be to "burn" a certain percentage of the transaction, eg. by sending it to an provably unspendable address (a hash160 of all zeros, for example).

So the transaction from the customer to the vendor, paying for the goods, would be a 2-of-3 multi-signature transaction (of which the customer, the vendor and the escrow agent each hold a copy), with an output (let's call it output1) to the vendor (paying them for the product), and an OP_RETURN output which specifies a review value (for example, 1 to 5). output1 will then have to be redeemed in a new transaction (created by the vendor), and this transaction will include an output that burns x% of the amount redeemed from output1, and an OP_RETURN output that specifies the vendor's public key.

To calculate the aforementioned total review score for a vendor, all you do is check every transaction that contains the vendor's public key in the OP_RETURN output, and take the sum of the review value multiplied by the amount of bitcoins burned for each of these transactions.

Might also help if the burn amount could be denoted as positive or negative. If zero is the worst, it might just mean "didn't care." If someone spends a significant sum on a negative rating, you know he was pissed.

There have been some behavioral economics experiments showing that people are quite willing to make sacrifices to punish offenders.

The burn amount shouldn't be proportional to the rating.

I realize now the system described above is faulty, as the vendor must not be able to hide transactions with a low rating. Also, of course the review value shouldn't be specified by the buyer before he has received the goods. But I'm pretty confident this can be worked around with the right protocol.